Helix has two separate layers of access, and conflating them is the most common mistake. Building and deploying a project is governed by workspace membership and your organization role; opening the published app is governed by that project’s Access Control tab. Published apps are always behind login and are never public, so every visitor has to be a Tray user in your organization who has been granted access.
The two layers
| Layer | Question it answers | Where you set it |
|---|---|---|
| Workspace membership and org role | Who can create, edit, and deploy this project? | Workspace and organization administration |
| Project Access Control | Who can open the published app at {project-id}.helix-app.ai? | The project’s Access Control tab in the dashboard |
Someone can hold one without the other. A colleague can be granted access to use your app without ever being able to change it, and a workspace member who can deploy the project is also, by default, someone who can open it.
Who can build and deploy
Access to build comes from workspace membership plus your role in the organization. There are two org roles:
| Role | What it covers |
|---|---|
| Contributor | Creates and works on projects in the workspaces they belong to. |
| Admin | Everything a Contributor does, plus the Admin console and the option to share an app with the whole organization. |
Admins count as members of every workspace even when they are not listed in one. That is deliberate, and it has a consequence worth reading twice: an admin can open any app whose access is left on the Workspace default.
Who can use the published app
Every deployed project has an Access Control tab in the Helix dashboard. It offers three settings:
| Setting | Who gets in |
|---|---|
| Workspace (default) | Everyone in the workspace the project belongs to, including org admins, who count as hidden workspace members. |
| Only people invited | Only the people you invite individually. Invitees can be anyone in the organization, not only workspace members. |
| Organization | Everyone in the organization. Available to admins only. |
Two things hold no matter which setting you pick:
- The app is behind login. There is no anonymous access, no public URL, and no way to publish an app to the open internet. A visitor without a Tray account in your organization cannot reach it at all.
- You keep access to your own project’s app. Narrowing the setting never locks you out of something you built.
To change the setting, open the project in the dashboard, go to Access Control, and pick the option you want. Invitations under “Only people invited” are issued per person from the same tab.
What is not in your code
Nothing on this page is configured in helix.config.ts or exported from a function. There is no code construct for app access in the shipped product: access is a dashboard setting on the project, and the platform enforces login at the edge before your function runs. A project that deploys is reachable by exactly the people the Access Control tab names.
For the trust boundaries behind this, see the security model. For what the platform enforces today, see limits and roadmap.