# Access Control

Access control on Salus covers two separate questions: **who on the internet can reach your running application**, and **who in your organization can act on your resources**.

## Deployment exposure

Each deployment is either public or private, set by the **public network** toggle on its [release configuration](https://salus.cloud/docs/deployments/environment-configurations/configuring/#public-network):

-   **Public** — the service is reachable from the internet on a public URL. Use this for anything users or external systems need to call.
-   **Private** — the service is only reachable internally, within its workspace. Nothing on the public internet can connect to it.

Leave a deployment private unless it genuinely needs to be exposed. See [Deployments](https://salus.cloud/docs/deployments/deployments/) for the domains a public deployment is served on.

## Database network access

Managed databases have their own network control, separate from your app’s exposure — a public-access toggle that enables the database’s external endpoint. See [Connect a Database](https://salus.cloud/docs/deployments/databases/connect/).

## Team roles

Access to your organization’s resources is governed by **roles**. Each member holds a role, and roles range from full control to read-only. A fifth role, **Guest**, is assigned automatically rather than chosen — see [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/).

### What each organization role can do

| Permission | Owner | Maintainer | Developer | Viewer |
| --- | --- | --- | --- | --- |
| View projects, pipelines, deployments, logs, metrics, and vulnerability findings | ✓ | ✓ | ✓ | ✓ |
| Run, re-run, and cancel pipelines; deploy | ✓ | ✓ | ✓ | — |
| Edit projects and release configurations | ✓ | ✓ | ✓ | — |
| Create and manage workspaces, projects, environments, and databases | ✓ | ✓ | — | — |
| Edit environment variables | ✓ | ✓ | — | — |
| Invite, edit, and remove members | ✓ | — | — | — |
| Connect Git providers | ✓ | — | — | — |
| Billing, subscription changes, and organization settings | ✓ | — | — | — |

Every role can _view_ environment variables, members, and the subscription; the table above is about acting on them.

### Workspace and project roles

Roles are **scoped**: a member can hold one role across the organization and a different one in a specific workspace or project — broad access in one workspace, none in another. Scoped roles come in the same flavors, narrowed to their scope:

-   **Maintainer** (workspace or project) — manages everything inside that scope: projects, environments, release configurations, pipelines, deployments, and the scope’s environment variables and members.
-   **Developer** (workspace or project) — works on what already exists: edits projects, runs pipelines, creates and edits release configurations. Can’t create projects or environments. A _project_\-scoped Developer can run pipelines but not trigger deployments — that stays with workspace-level roles and Maintainers.
-   **Viewer** (workspace or project) — read-only across the scope, including logs, metrics, and vulnerability findings.

Managing members and their roles is covered under [Organizations & Teams](https://salus.cloud/docs/getting-started/organizations-and-teams/).

Note

The tables reflect the platform’s current permission configuration. When in doubt, what the UI offers a member is authoritative — actions a role doesn’t hold simply don’t appear.