Teams and capabilities

Deplo is built for several people sharing one instance. Everything belongs to a team, every change is checked against a capability, and a role is a named set of capabilities.

If you are the only person here, none of this gets in your way: your account has the Owner role of your own team and can do everything.

TeamCopy Anchor Link

An isolated workspace. It owns apps, domains, environment variables, databases, backup destinations, registries, git connections, API tokens, activity, members and notification settings. A person can belong to several teams and switches between them from the top bar. Every list you see is filtered by the active team.

The team's addressCopy Anchor Link

Every page has the team in its address: deplo.example.com/acme/apps/wiki. A link to an app, a database or a setting always opens in the team that owns it, whoever clicks it. This is what makes links in notifications, or links you send to a colleague, open the right page.

The name in the address is set when the team is created and never changes, so old links keep working. An older address with no team in it still works too. A link to a team you are not in shows a "no access" page with your own teams.

Deleting a teamCopy Anchor Link

Settings -> Team -> General -> Danger zone, with the delete_team capability. You cannot delete your only team: create or join another first.

Everything in the team is deleted with it: apps and databases with their data, folders, projects, domains, variables, members and backups. Deplo then sends you to another of your teams.

The primary ownerCopy Anchor Link

The account that created the team is the primary owner. No other owner and no instance admin can remove, demote or edit them.

Only the primary owner can transfer it, from Settings -> Members -> the member -> Advanced, to a member of the same team, with their password and second factor. An API token can never do it.

CapabilityCopy Anchor Link

One capability is one action. create_apps, deploy_apps, delete_apps, open_app_console, restore_backups, manage_tokens, and so on. There are 45 of them, view included.

They are fine-grained on purpose: deleting an app is delete_apps, not deploy_apps. view is the base level everybody has.

One to know by name: reveal_secrets protects the only four values Deplo can show you again: a basic-auth password, a backup recovery key, a managed database's connection string, and an app's deploy hook URL. An environment variable is never one of them.

Three grants are different:

• instanceAdmin is instance-wide, not a team capability. It unlocks Servers, Users and the Deplo instance settings.
• canExposePorts allows publishing a port on the host.
• canMountHostVolumes allows every way out of a container: bind mounts, privileged, added kernel capabilities, devices, host namespaces, foreign networks and foreign volumes. See Host access.

The full list is in Capabilities.

RoleCopy Anchor Link

A role belongs to a team. Every team starts with three roles it can rename, edit and later reset to the defaults: Owner, Member, Viewer. You can create as many more as you like.

• Owner always has full access and cannot be reduced.
• Editing a role changes every member holding it at once.
• A change cannot leave the team with nobody holding manage_members, manage_roles or manage_team.
• A member with no role has a hand-picked Custom set.

Access inside one folderCopy Anchor Link

A set of capabilities can also be given on a folder or a single app instead of the whole team. Inside that folder or app it replaces the team role, and it can be larger. The most specific grant wins.

This is how someone with a read-only team role can deploy everything in one folder, without gaining that power anywhere else.

API tokensCopy Anchor Link

A token has its own capabilities. It does not act as the person who created it. You choose what it can do when you create it, and you can edit that later.

A token can never do more than its creator can do right now, so removing capabilities from a person also limits every token they created. A token can be limited to whole teams, projects, folders or single apps, and it can have an expiry. It is shown once, at creation.

Two-factor is a policy, not a capabilityCopy Anchor Link

A team, or a role inside it, can require two-factor authentication. A member who has not enabled it can do nothing in that team: not in the dashboard, not over the API, and not with their tokens. They see a lock screen with the option to enable it, switch team or sign out.

A passkey counts. Signing in with one satisfies the requirement for that session.

The two checksCopy Anchor Link

Every change is checked twice, and only the second one matters:

• In the interface, capabilities hide or disable buttons. This is cosmetic.
• In the data layer, the capability is checked before the write. This is the real check, and the API and the MCP server pass through it too.

A resource inside a folder is also checked against that folder's grant. For security reasons, an id belonging to another team behaves as if it did not exist.

Instance admin and instance ownerCopy Anchor Link

Instance admin unlocks the system-wide pages: Servers, Users, and the instance settings. It is not a team capability and grants no team capabilities.

Instance owner is the level above it, held by the account created at first setup. No other admin can demote, suspend or reset the owner, and the owner cannot drop their own admin flag. Only the owner can transfer it, to an active instance admin, with their password. A locked-out owner can only be recovered with a command run on the host.

Next stepsCopy Anchor Link