Permissions & Access Control

Trailer controls access with four building blocks that combine per request: the admin role, resource ownership, host capabilities, and per-resource grants. This page explains each block, how they interact, and the transitive rules that are easy to miss.

The building blocks

Admins

A user with the Admin attribute bypasses every check described on this page: admins see every resource, can edit and delete everything, and are the only ones who can manage users, hosts, domains, settings, and host capabilities. Admin status is managed on the Users page.

Ownership

Every workspace, image, volume, network, file, and domain records its creator. The creator can see, edit, and delete their own resource without any explicit grant (with one exception for volumes, described under transitive rules below). Ownership is fixed at creation and cannot be transferred.

Host capabilities

Hosts are special: only admins manage them, and they carry per-user capability flags that gate what a user may create on that host. Admins grant these in the Permissions section of Host Details:

• View: see the host.
• Workspace creation
• Image creation
• Bind mount creation
• Volume mount creation
• Network creation

A user without the matching capability cannot pick that host in the corresponding create form.

Resource grants

Each workspace, image, volume, network, file, and domain has its own access list. A row grants one user a role; the roles map to three underlying flags:

Role	Base flag	Modify	Delete
Viewer (or User)	yes	no	no
Editor	yes	yes	no
Manager	yes	yes	yes

The base flag differs by resource type, because “using” means something different for each:

Resource	Base flag	What the base flag allows
Workspace	View	See the workspace, stream its logs, open it through the platform
Image	View	See the image and deploy workspaces from it
File	View	See the file and use it in images
Volume	Attach	See the volume and attach it to your workspaces
Network	Attach	See the network and attach it to your workspaces
Domain	Deploy	See the domain and use it in workspace URLs

Modify allows editing (for workspaces this includes the Attach and Exec terminals; for images it includes building, enabling, disabling, and cancelling builds). Delete allows removal. Note that even with Delete, a volume or network still attached to a workspace and a file still used by an image cannot be deleted; detach or remove the dependents first.

Who can create what

• Workspaces: users with Workspace creation on the target host.
• Images: users with Image creation on the build host.
• Volumes: users with Volume mount creation (regular volumes) or Bind mount creation (bind mounts) on the host. The two flags are independent; having one does not imply the other.
• Networks: users with Network creation on the host.
• Files: any signed-in user. Files are not tied to a host.
• Domains and hosts: admins only.
• Users: admins only (creation and invitation).

Transitive visibility

Granting access to a workspace pulls the surrounding resources into view, so the grantee can actually understand and use what they were given:

• View on a workspace also lets the user see the workspace’s image, its host, and the volumes and networks attached to it.
• View on an image also lets the user see the files that image uses.

Domains are deliberately excluded from this: seeing a workspace does not reveal the domains behind its URLs. Using a domain always requires an explicit Deploy grant.

Transitive requirement rules

Some actions require permissions on more than one resource at the same time:

• Editing a volume requires a host capability too. Having Modify on a volume (or even being its creator) is not enough: the user must also hold the matching mount creation capability on the volume’s host, Volume mount creation for regular volumes or Bind mount creation for bind mounts. A user whose host capability was revoked keeps seeing their volumes but can no longer edit them. Admins are exempt. This is unique to volumes; editing a network or an image needs no host capability.

flowchart TD
    A[User edits a volume] --> B{Admin?}
    B -- yes --> OK[Allowed]
    B -- no --> C{Creator, or Modify grant on the volume?}
    C -- no --> DENY[Denied]
    C -- yes --> D{Matching mount creation capability on the volume's host?}
    D -- yes --> OK
    D -- no --> DENY

• Creating a workspace checks the parts, not just the host. Beyond Workspace creation on the host, every volume and network you attach must be visible to you (through an Attach grant, ownership, or transitive visibility) and must live on the same host as the workspace, and every URL’s domain needs a Deploy grant.
• Disabled images deploy only for admins. A workspace cannot be created from a disabled image by a regular user, regardless of grants.
• Workspace terminals need Modify. Streaming logs and opening the workspace through the platform needs View; attaching to the container or executing commands in it is treated as modification.

Managing grants

• The access list of a resource is managed by admins, the resource’s creator, and users holding Modify on that resource. Granting Modify therefore delegates the ability to grant.
• Host capabilities are managed by admins only.
• Every user can always see the grants that concern them, so the platform can show which resources they have access to.
• A domain’s URL is fixed after creation and cannot be edited by anyone, including admins; delete the domain and create a new one instead.

Workspace URL logins

Workspace URLs protected with internal authentication carry their own per-URL login list: the users selected there may log in to that URL, independently of whether they hold any grant on the workspace itself. This list is managed in the External URLs section of the workspace form by the same people who can manage the workspace’s grants. See Workspace URLs and routing.

Users

All signed-in users can see the user list; that is what makes the user pickers in the permission editors work. Beyond that:

• Only admins create, invite, or delete other users, and only admins can grant or revoke the Admin attribute.
• Users can edit their own profile but cannot make themselves admin.
• Disabling a user (admins only) blocks access while keeping their resources and grants intact.

Quick reference

Action	Who can do it
See a resource	Admin, creator, base-flag grantee, or transitively via a workspace/image grant
Edit a workspace, image, network, file	Admin, creator, or Modify grantee
Edit a volume	(Admin) or (creator or Modify grantee) with the matching mount capability on the host
Edit a domain	Admin or Modify grantee, but never the URL itself
Delete a resource	Admin, creator, or Delete grantee, if nothing still uses it
Grant access to a resource	Admin, creator, or Modify grantee
Create on a host	Holder of the matching host capability
Manage hosts, domains, users, settings	Admins only