Short answer: Hologram won’t “leak” data across users, but anything you send to the browser for the current user is visible to that user (e.g., via DevTools). Think of it like a REST response: only send what the current user is allowed to see.

What gets compiled to JavaScript

• Compiled to the page bundle: functions reachable from page/component template/0 and action/3, plus component init/2 (see also: Hologram Elixir → JS compilation)
• Not compiled to JS: server init/3 (page and component), command/3
• Bundles are generic and public; they don’t contain per-user data.

What data reaches the browser

• Per-user state is serialized into the initial HTML mount payload (for client runtime to start). They are visible to the current user in DevTools.
• Passing a whole struct as a prop is acceptable; it just means all its fields are present client-side for that user. If you want to minimize payload and exposure, pass only the fields you need.

About secrets (same rules as frontend JS frameworks)

• Never hardcode or send global/shared secrets (e.g., service API keys, service account creds, DB creds) in any code compiled to the client: action/3, template/0, helpers they call, or component init/2. As with React/Vue/Svelte, anything hardcoded in client-compiled code ships in the bundle and is visible to anyone.
• Don’t place global/shared secrets into state/props either - mount payloads are visible to the current user.
• Sending sensitive data that the current user is authorized to access is fine if it’s intentional and needed for UX (e.g., account balance, email, or a user‑scoped short‑lived token). Just remember it will be visible to that user in the browser.

OK (user-authorized data in server init/3, visible only to that user in the mount payload):

def init(_params, component, _server) do
  put_state(component, :account_balance_cents, 123_45)
end

OK (user-scoped, least‑privilege token if truly needed client-side):

def init(_params, component, _server) do
  put_state(component, :photo_upload_token, issue_user_scoped_token())
end

Not OK (global/shared secret compiled to the public bundle):

def action(:my_action, _params, component) do
  put_state(component, :api_key, "my_global_service_key")
end

TL;DR

• Bundles are public and generic; per-user data isn’t stored there.
• Per-user data is in the HTML mount payload and visible to the current user.
• Only send data the current user should see (same mindset as a REST response).
• Same as frontend JS frameworks: never hardcode or send global/shared secrets to the client; user-authorized sensitive data can be sent intentionally, knowing it will be visible client-side.

Glad to hear the actions/commands model clicks!