Opfield 2.11 defines 231 permission scopes. The tables below list their exact names and the actions they authorize. Assign permissions through groups or a user’s additional permissions; see users and groups, Restrict access to a folder, and API tokens, OAuth, and MCP for setup. Scopes renamed or removed in 2.11 are listed under Retired scope names.
- Restrictions: Resource means the scope supports a resource qualifier; Folder means it also supports a folder qualifier. — means the base scope has no resource qualifier. For Git integration scopes, the resource is a connector, a GitLab group or project, or a GitHub owner or repository; see Git integration restrictions.
- Tokens: API means the scope can be delegated to an API token or OAuth for the Opfield API; MCP means it can be delegated to OAuth for the Opfield MCP resource. — means neither regular token family accepts it. User permissions and token permissions are not interchangeable.
- A permission does not enable an unavailable product feature, bypass license requirements, or grant credentials or privileges at the external provider.
- Delegated access is limited by the owning user’s current effective permissions. MCP scope eligibility does not mean a corresponding tool exists.
- API tokens and OAuth grants for the Opfield API or MCP can carry every scope except the user-only AI Workspace and AI sandbox scopes (
ai:workspace:use, feat:ai:configure, ai:skills:manage, and ai:sandbox:*), mcp:use, inference:setup, admin:users:impersonate, and integrations:gitlab:sandbox:clone. API tokens and OAuth authorizations themselves can be created only from an interactive session.
inference:setup is a special OAuth scope for Inference setup, not an ordinary user or group permission.
A base permission such as proxy:view covers all routes. A qualified permission such as proxy:view:<routeId> covers one route; proxy:view:folder/<folderId> covers the routes in the selected folder and its subfolders. Routes, Pages, storage, databases, and Docker scopes, and every creation scope, also accept node/<nodeId> for the resources on one Node.
The qualifier depends on the resource type. Docker container scopes use <nodeId> for a node or <nodeId>/<stableResourceId> for a specific container or deployment. Qualified Pages permissions use the project ID, including operations on its deployments, tags, and deployment tokens. Internal PKI scopes use the CA ID. Select the target in the permissions editor rather than using an ID from another resource type.
Opfield resolves a folder grant on every request: it covers the resources in the folder now, resources created in or moved into it later, and nothing that has been moved out. For creation permissions, a folder restriction selects the destination folder, not a resource that has not been created yet. Folder management and resource operations are separate permissions: managing a folder does not itself grant access to every item in it, and moving an item still needs the item’s own edit or manage scope.
API tokens and OAuth grants are resolved in two steps: their own folder and Node restrictions are expanded first, and the result is then limited by the owner’s current access. A token therefore never reaches a resource its owner cannot, and a creation grant never counts as a view grant when it is delegated. When a token requests a broad scope that the owner holds only for some resources, Opfield narrows the token to those resources.
Every scope belongs to a family named by its longest prefix that has a view scope: proxy:* belongs to proxy:view, docker:containers:* to docker:containers:view, nodes:* to nodes:details, and docker:tasks:manage to docker:tasks. Any action scope implies its family’s view scope with the same qualifier, including delete scopes. For example, proxy:edit:<routeId> lets the holder see that route, docker:containers:manage:<nodeId> lets the holder see every container on that Node, and databases:query:read:<databaseId> shows that database in the database list without granting global databases:view.
Creation scopes imply no view at all: every scope with a create part, such as proxy:create, docker:containers:create, or pki:templates:create, plus docker:images:pull, ssl:cert:issue and pki:cert:issue. This holds whatever the qualifier—broad, a folder, or a Node—so a user with only proxy:create:folder/<folderId> can create routes in that folder but does not see the routes already in it. Create dialogs still show the destination folders and Nodes such a user may choose. With Auto-assign permissions for created resources on, which is the default, the creator keeps view of each resource they create; see Restrict access to a folder. The one exception is hosting:snapshots:create:<vmId>, which keeps view of that VM’s snapshots.
A few explicit rules complete the picture:
- Access tiers:
storage:objects:admin includes write, which includes read; databases:query:admin includes write, which includes read; storage:credentials:reveal includes storage:credentials:use.
logs:read and logs:tokens:view (and therefore logs:tokens:delete) imply logs:environments:view; nodes:manage implies nodes:config:view, which implies nodes:details; inference:models:manage implies inference:providers:view; docker:availability:manage implies docker:containers:view.- Folder-tree scopes (
*:folders:manage), nodes:backups:execute, proxy:maintenance:bypass, and the internal registry credentials docker:registries:internal:pull and :push imply no view.
- A view scope never implies another family’s view;
proxy:templates:view does not grant proxy:view.
Each resource type has its own folder tree. A folder in Routes does not cover containers, even when a Docker folder has the same name.
| Resources |
Folder restriction |
Folder tree managed with |
| Routes |
Yes |
proxy:folders:manage |
| Domains |
Yes |
domains:folders:manage |
| SSL certificates |
Yes |
ssl:cert:folders:manage |
| Pages Projects |
Yes |
pages:folders:manage |
| Nodes |
Yes |
nodes:folders:manage |
| Docker containers and Deployments |
Yes |
docker:folders:manage |
| Compose Projects, Docker networks, Docker volumes, Docker images |
Yes; each type has a separate tree |
docker:folders:manage |
| Databases: external connections and managed databases |
Yes |
databases:folders:manage |
| Storage: storage connections and managed storage |
Yes |
storage:folders:manage |
| Logging environments; logging schemas |
Yes |
logs:environments:folders:manage; logs:schemas:folders:manage |
| Users; permission groups |
Yes |
admin:users:folders:manage; admin:groups:folders:manage |
| Internal PKI certificate authorities |
Yes; a folder holds whole CA hierarchies, and a grant covers each root CA in the folder and its intermediates |
pki:ca:folders:manage |
| Internal PKI certificates |
Yes |
pki:cert:folders:manage |
| nginx templates |
Yes |
proxy:templates:folders:manage |
| Certificate templates |
Folders only organize the list; certificate template scopes are not restricted to resources |
pki:templates:folders:manage |
| Database backups |
Through the database’s folder |
— |
| Logging ingest tokens and log search |
Through the logging environment’s folder |
— |
| Workload Availability |
Through the container or Compose folder |
— |
Backup executors (nodes:backups:execute) |
Through the Node’s folder |
— |
| Access lists, Docker registries, Docker tasks, notifications, status page, SIEM, integrations, hosting accounts and VMs, inference, Opfield diagnostics, housekeeping, license, and settings |
No |
— |
Scopes without folder support are global or, where the catalogue shows Resource, restricted to one resource. Hosting snapshot folders only organize snapshots; they are not an access boundary.
Git integration scopes can be limited to one connector and, for GitLab and GitHub, to groups, projects, owners, or repositories inside it. Qualifiers are stable provider IDs, never names or paths, so renaming or moving a group or repository never changes a grant.
| Qualifier |
Covers |
<scope>:<connectorId> |
Every repository of that connector |
<scope>:<connectorId>/group/<groupId> |
GitLab: the group, its subgroups, and every project under them. Opfield reads a project’s parent groups from GitLab and caches them for a few minutes, so a moved project follows its new group |
<scope>:<connectorId>/project/<projectId> |
GitLab: that project |
<scope>:<connectorId>/owner/<ownerId> |
GitHub: every repository of that organization or user |
<scope>:<connectorId>/repo/<repoId> |
GitHub: that repository |
- Which scopes:
view, use, repo:read, and repo:write of GitLab and GitHub, and integrations:gitlab:sandbox:clone, accept every qualifier of their provider. Generic Git scopes accept the connector only. integrations:<provider>:manage is broad or limited to a connector: managing a connection—its settings, tokens, repository allowlist, sync, test, and deletion—needs it on that connector, and creating a connector needs it broad. A group, owner, project, or repository grant never allows connector management.
- Matching: an operation on a repository is allowed by the broad scope, the connector qualifier, any group or owner that contains the repository, or the exact project or repository. Implied view works per qualifier:
integrations:gitlab:repo:write:<connectorId>/project/42 also shows project 42. Folder qualifiers do not apply to integrations.
- What is checked: every repository operation checks the repository—files, trees, branches, commits, CI pipelines, job logs and variables, webhooks, deploy tokens, registry settings, sandbox clones, and Docker and Pages build sources—in the REST API, the AI Workspace, and MCP alike.
- Credentials: Opfield uses the connector’s own credential when
integrations:<provider>:use covers the repository in the same way, and the caller’s personal credential otherwise. Without either, AI Workspace users are asked to authorize a personal credential, and other callers receive 403 naming integrations:<provider>:use and the repository.
- Hidden projects: a GitLab project outside the caller’s grant answers exactly like a project that is not synchronized (
404, no path). Writes, secrets, sandbox clones, and the credential decision read group ancestry and repository ownership fresh from the provider; reads may use a cached value for up to five minutes, and GitHub ownership is cached by repository ID, never by path. Connector change events over the WebSocket reach only callers who may see that connector.
- Lists: connector lists contain the connectors the caller holds any Git scope on; a connector seen only through narrower grants is returned without its allowlist. Project and repository lists contain only what the grants cover.
- Build sources: configuring a Docker or Pages build source needs
integrations:<provider>:use on the repository, with any qualifier that covers it, next to the workload’s own permissions. repo:read, broad view, and a personal credential are not needed, because builds use the connector credential. The source picker lists the connectors and repositories that the caller’s Git scopes cover, since use implies view. A manual build checks the caller’s use on the saved repository again. Sources saved before 2.11 keep building automatically as before; a source created or saved again after the update builds from polling and webhooks only while the account that saved it still holds use on the repository, and otherwise records a cancelled build Build paused: <user> no longer has use on <repo> until that access returns or someone with use saves the source again.
- Tokens and OAuth grants: a delegated Git scope is bounded by the owner per qualifier. A broader token scope is narrowed to the owner’s qualifiers, and a token scope limited to a group, owner, project, or repository is kept when the owner holds the same scope, or one that implies it, anywhere on that connector. Because containment is provider data, every repository operation of a token or OAuth caller needs both the token and the owner’s current scopes to cover the repository: a token limited to project P works while its owner holds the group that contains P, and a token limited to group G whose owner holds only project P reaches P alone. Such narrow token scopes never count when the token grants permissions to users or groups.
The group editor, users’ additional permissions, the API token form, and OAuth and MCP consent offer these restrictions under each connector, with a search picker for groups and projects or owners and repositories. The picker reads GET /api/integrations/{provider}/{connectorId}/scope-targets?search=&limit=50, where provider is gitlab or github, and shows the labels of stored qualifiers through GET /api/integrations/{provider}/{connectorId}/scope-targets/resolve?ids=group/123,project/456. Both endpoints need integrations:<provider>:view on the connector or on anything inside it, and return only the targets the caller may view and the connector’s allowlist includes. They share a limit of 60 requests a minute per account, after which they return 429 SCOPE_TARGET_RATE_LIMITED with Retry-After, and one request makes at most 60 uncached lookups at the provider; further targets keep their raw IDs. A target that no longer exists is marked missing and shown as Unavailable; a stored qualifier that the caller cannot view keeps its raw ID as its label.
Opfield 2.11 renamed, merged, or removed the scopes below. The update rewrote every stored grant—groups, users’ additional permissions, API tokens, and OAuth grants—and kept each qualifier, so nodes:config:edit:<nodeId> became nodes:manage:<nodeId>. So that nobody lost access, holders of pki:ca:create:root also received pki:ca:edit and pki:ca:export; holders of integrations:github:view or integrations:git:view received :repo:read; holders of integrations:github:manage or integrations:git:manage received :repo:read and :repo:write; and holders of broad or Node-level docker:volumes:create (for example docker:volumes:create:<nodeId>) received docker:volumes:edit with the same qualifier; folder-level create grants and delete-only grants did not.
For two releases, Opfield still accepts the old names on input and rewrites them the same way: the OAuth scope parameter, API token creation and updates, permission group creation and updates, users’ additional permissions, and OAuth authorization edits. A request whose scopes were all removed is rejected. New API tokens and OAuth requests also receive the additions above when the requester holds them—for example, a token requested with integrations:github:manage also gets repo:read—and the consent screen shows them so they can be unticked. Scopes that need manual approval, such as repo:write or pki:ca:export, are never added on input. Permission checks use only the current names, so update scripts, OAuth clients, and infrastructure-as-code definitions before the aliases are removed.
| Retired |
Replacement |
ssl:cert:revoke, ssl:cert:export |
Removed; they were never enforced |
notifications:view |
notifications:alerts:view and notifications:webhooks:view |
notifications:manage |
notifications:alerts:manage and notifications:webhooks:manage |
notifications:alerts:create, :edit, :delete |
notifications:alerts:manage |
notifications:webhooks:create, :edit, :delete |
notifications:webhooks:manage |
notifications:deliveries:view |
notifications:webhooks:view |
logs:manage |
Every logs:* scope |
docker:containers:config |
Removed. Duplicate and recreate need docker:containers:environment and docker:containers:secrets; a Docker Node’s service address needs nodes:manage |
nodes:config:edit |
nodes:manage |
pki:ca:view:root, pki:ca:view:intermediate |
pki:ca:view |
integrations:gitlab:sync, integrations:github:sync, integrations:git:sync |
integrations:<provider>:manage |
integrations:gitlab:system, integrations:github:system, integrations:git:system |
integrations:<provider>:use |
integrations:gitlab:projects:view |
integrations:gitlab:view |
integrations:gitlab:ci:view, :variables:view |
integrations:gitlab:repo:read |
integrations:gitlab:ci:edit, :variables:edit, :variables:delete, :webhooks:manage, :registry:manage |
integrations:gitlab:repo:write |
proxy:raw:toggle |
Removed; switching raw mode needs proxy:raw:write |
proxy:advanced:bypass, proxy:raw:bypass |
proxy:unrestricted |
proxy:templates:create, :edit, :delete |
proxy:templates:manage |
docker:containers:folders:manage |
docker:folders:manage |
Some replacements are broader than the scope they replace, so review groups, user permissions, API tokens, and OAuth grants that held them: integrations:gitlab:repo:write also commits repository files and changes CI configuration, variables, webhooks, and registry settings; integrations:gitlab:repo:read also reads repository files; a connector’s manage permission covers its settings, tokens, allowlist, test, and deletion; nodes:manage also installs the Secure Runtime, changes service addresses, and controls hosted VMs; proxy:unrestricted lifts both the advanced and the raw configuration restrictions; and notifications:webhooks:manage also reveals webhook URLs, headers, and delivery payloads. integrations:gitlab:variables:view became integrations:gitlab:repo:read, which reads variable keys but not their values. See Updating from 2.10.
Other permission changes in 2.11:
- New scopes:
pki:ca:edit (CA URLs, maximum validity, and the OCSP responder) and pki:ca:export (CA private-key export), both restrictable to one CA; docker:volumes:edit (rename, relabel, resize, and adopt volumes); integrations:github:repo:read, :repo:write, integrations:git:repo:read, and :repo:write.
- Git providers share the same verbs:
view lists connectors, manage configures, tests, and synchronizes them, use uses the connector’s own credential, and repo:read and repo:write read or change repository content. Each can be limited to a connector and, for GitLab and GitHub, to groups, projects, owners, or repositories; see Git integration restrictions. Listing and reading GitLab’s synced projects needs integrations:gitlab:view. GitLab repo:read covers repository files, CI pipelines and job logs, and CI/CD variable keys, never values; changing variables needs repo:write. Reading GitHub Actions variable values needs integrations:github:repo:write. The built-in viewer and operator groups get integrations:gitlab:view only.
- Templates: writing nginx template content needs
proxy:templates:manage and no longer proxy:raw:write. The built-in operator group keeps only proxy:templates:view, because template content is raw nginx configuration.
- Folder grants now resolve for
logs:tokens:* (through the logging environment’s folder) and docker:availability:manage (through the container or Compose folder). Certificate authorities, Internal PKI certificates, and nginx templates can be organised in folders and granted per folder; see Folder support by resource type.
- Implied view: every action permission except create implies its family’s view permission with the same qualifier, so a delete-only grant now also lists and views those resources; see Implied view access.
- New permissions for new features:
diagnostics:view and diagnostics:logs, databases:backups:*, nodes:backups:execute, and the storage:* scopes. Built-in groups received them; custom permission groups did not, so grant them where needed.
| Scope |
Description |
Restrictions |
Tokens |
pki:ca:view |
View root and intermediate certificate authorities |
Resource, Folder |
API, MCP |
pki:ca:create:root |
Create new root certificate authorities |
— |
API, MCP |
pki:ca:create:intermediate |
Create intermediate CAs under a root |
Resource |
API, MCP |
pki:ca:edit |
Edit CA URLs, maximum validity, and the OCSP responder |
Resource, Folder |
API, MCP |
pki:ca:export |
Export a certificate authority with its private key |
Resource, Folder |
API, MCP |
pki:ca:folders:manage |
Manage CA folders. Only root CAs move, and their intermediates follow; moving a root CA also needs pki:ca:edit on it and on the destination |
— |
API, MCP |
pki:ca:revoke:root |
Revoke root certificate authorities |
— |
API, MCP |
pki:ca:revoke:intermediate |
Revoke intermediate certificate authorities |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
pki:cert:view |
View issued certificates |
Resource, Folder |
API, MCP |
pki:cert:issue |
Issue new certificates |
Resource |
API, MCP |
pki:cert:revoke |
Revoke issued certificates |
Resource, Folder |
API, MCP |
pki:cert:export |
Export certificates and keys |
Resource, Folder |
API, MCP |
pki:cert:folders:manage |
Manage PKI certificate folders; moving a certificate also needs pki:cert:issue on its issuing CA |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
pki:templates:view |
View certificate templates |
— |
API, MCP |
pki:templates:create |
Create certificate templates |
— |
API, MCP |
pki:templates:edit |
Edit certificate templates |
— |
API, MCP |
pki:templates:delete |
Delete certificate templates |
— |
API, MCP |
pki:templates:folders:manage |
Manage certificate template folders; moving a custom template also needs pki:templates:edit, and built-in templates never move |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
domains:view |
View managed domains |
Resource, Folder |
API, MCP |
domains:create |
Create managed domains |
Resource, Folder |
API, MCP |
domains:edit |
Edit managed domains |
Resource, Folder |
API, MCP |
domains:delete |
Delete managed domains |
Resource, Folder |
API, MCP |
domains:folders:manage |
Organize managed domains into folders |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
proxy:view |
View and search ingress routes |
Resource, Folder |
API, MCP |
proxy:create |
Create new ingress routes |
Resource, Folder |
API, MCP |
proxy:edit |
Edit ingress route configuration |
Resource, Folder |
API, MCP |
proxy:delete |
Delete ingress routes |
Resource, Folder |
API, MCP |
proxy:raw:read |
View raw nginx configuration |
Resource, Folder |
API, MCP |
proxy:raw:write |
Edit raw nginx configuration and switch routes between managed and raw mode |
Resource, Folder |
API, MCP |
proxy:advanced |
Use advanced proxy configuration |
Resource, Folder |
API, MCP |
proxy:unrestricted |
Save advanced snippets and raw nginx config without dangerous directive restrictions |
Resource, Folder |
API, MCP |
proxy:maintenance:bypass |
Create temporary access codes for maintained routes |
Resource, Folder |
API, MCP |
proxy:folders:manage |
Create, reorder, and remove route folders |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
pages:view |
View Page Projects, Deployments, Tags, previews, and usage |
Resource, Folder |
API, MCP |
pages:create |
Create static Page Projects |
Resource, Folder |
API, MCP |
pages:edit |
Rename Page Projects and edit their retention and quota settings |
Resource, Folder |
API, MCP |
pages:delete |
Delete eligible Page Projects |
Resource, Folder |
API, MCP |
pages:deploy |
Create and upload static Deployments |
Resource, Folder |
API, MCP |
pages:deployments:manage |
Pin, unpin, clean up, and delete eligible Deployments |
Resource, Folder |
API, MCP |
pages:tags:manage |
Create, move, and delete Page Project Tags |
Resource, Folder |
API, MCP |
pages:tokens:manage |
Create, restrict, and revoke Project deploy credentials |
Resource, Folder |
API, MCP |
pages:folders:manage |
Create, reorder, and remove Page Project folders |
— |
API, MCP |
pages:settings:view |
View wildcard profile and storage defaults |
— |
API, MCP |
pages:settings:edit |
Configure and migrate the wildcard Pages profile and storage defaults |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
proxy:templates:view |
View nginx templates |
Resource, Folder |
API, MCP |
proxy:templates:manage |
Create, edit, and delete nginx templates, including template content; with a folder qualifier, also create templates in that folder |
Resource, Folder |
API, MCP |
proxy:templates:folders:manage |
Manage nginx template folders; moving a custom template also needs proxy:templates:manage on it and on the destination, and built-in templates never move |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
ssl:cert:view |
View SSL certificates |
Resource, Folder |
API, MCP |
ssl:cert:issue |
Provision ACME or upload SSL certificates |
Resource, Folder |
API, MCP |
ssl:cert:folders:manage |
Organize SSL certificates into folders |
— |
API, MCP |
ssl:cert:delete |
Delete SSL certificates |
Resource, Folder |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
acl:view |
View access control lists |
Resource |
API, MCP |
acl:create |
Create access control lists |
— |
API, MCP |
acl:edit |
Edit access control lists |
Resource |
API, MCP |
acl:delete |
Delete access control lists |
Resource |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
nodes:details |
View managed nodes |
Resource, Folder |
API, MCP |
nodes:create |
Enroll new nodes |
Resource, Folder |
API, MCP |
nodes:rename |
Rename nodes |
Resource, Folder |
API, MCP |
nodes:delete |
Remove nodes |
Resource, Folder |
API, MCP |
nodes:config:view |
View node nginx configuration |
Resource, Folder |
API, MCP |
nodes:manage |
Edit node nginx config, install the Docker secure runtime, change service addresses, and control hosted VMs |
Resource, Folder |
API, MCP |
nodes:logs |
View node daemon and nginx logs |
Resource, Folder |
API, MCP |
nodes:console |
Open interactive shell on nodes |
Resource, Folder |
API, MCP |
nodes:files:read |
Browse, open, copy, and download node files |
Resource, Folder |
API, MCP |
nodes:files:write |
Create, edit, upload, move, and delete node files |
Resource, Folder |
API, MCP |
nodes:lock |
Prevent new proxy hosts or containers on selected nodes |
Resource, Folder |
API, MCP |
nodes:folders:manage |
Create, reorder, and remove node folders |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
admin:users |
Create, edit, and delete users |
Resource, Folder |
API, MCP |
admin:users:impersonate |
Temporarily act as another active user |
Resource, Folder |
— |
admin:users:folders:manage |
Create, reorder, and remove user folders |
— |
API, MCP |
admin:groups |
Create, edit, and delete permission groups |
Resource, Folder |
API, MCP |
admin:groups:folders:manage |
Create, reorder, and remove permission group folders |
— |
API, MCP |
admin:audit |
View the audit log |
— |
API, MCP |
audit:siem:view |
View SIEM destinations and audit delivery history |
— |
API, MCP |
audit:siem:manage |
Configure SIEM destinations and control audit deliveries |
— |
API, MCP |
admin:system |
System-level administration (protected) |
— |
API, MCP |
admin:details:certificates |
View internal system PKI and SSL certificates in read-only mode |
— |
API, MCP |
admin:update |
Check for and apply updates |
— |
API, MCP |
admin:alerts |
View and manage alerts |
— |
API, MCP |
diagnostics:view |
Read Opfield’s own state and its 48-hour minute history: host CPU, memory, and disk, the backend process, its PostgreSQL and Redis, the stack containers, background jobs, and API latency. Held by the built-in admin groups |
— |
API, MCP |
diagnostics:logs |
Read the logs of Opfield’s own containers (app, PostgreSQL, Redis, Relay, registry) and of the last update run; implies diagnostics:view. Held by the built-in admin groups |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
settings:gateway:view |
View sign-in provisioning and external control-plane settings |
— |
API, MCP |
settings:gateway:edit |
Edit sign-in provisioning and external control-plane settings |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
integrations:gitlab:view |
View configured GitLab connectors, sync status, and synced projects |
Resource |
API, MCP |
integrations:gitlab:manage |
Create, edit, rotate, sync, and delete GitLab connectors |
Resource |
API, MCP |
integrations:gitlab:use |
Use the connector credential for otherwise permitted GitLab operations, and configure Docker and Pages build sources from a project |
Resource |
API, MCP |
integrations:gitlab:repo:read |
Read repository files, CI pipelines and job logs, and CI/CD variable keys (never values) through GitLab connectors |
Resource |
API, MCP |
integrations:gitlab:repo:write |
Change repository files, CI configuration, CI/CD variables, webhooks, and registry records through GitLab connectors |
Resource |
API, MCP |
integrations:gitlab:sandbox:clone |
Clone allowed GitLab repositories into AI sandboxes |
Resource |
— |
| Scope |
Description |
Restrictions |
Tokens |
integrations:github:view |
View configured GitHub token connectors |
Resource |
API, MCP |
integrations:github:manage |
Create, edit, rotate, sync, and delete GitHub token connectors |
Resource |
API, MCP |
integrations:github:use |
Use the connector credential instead of a personal GitHub authorization, and configure Docker and Pages build sources from a repository |
Resource |
API, MCP |
integrations:github:repo:read |
List repositories and read files through GitHub connectors (no Actions variable values) |
Resource |
API, MCP |
integrations:github:repo:write |
Change repository files and secrets, and read or change Actions variables, through GitHub connectors |
Resource |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
integrations:git:view |
View configured generic Git connectors |
Resource |
API, MCP |
integrations:git:manage |
Create, edit, rotate, sync, and delete generic Git connectors |
Resource |
API, MCP |
integrations:git:use |
Use the connector credential instead of a personal Git authorization, and configure Docker and Pages build sources from a repository |
Resource |
API, MCP |
integrations:git:repo:read |
List repositories and read files through generic Git connectors |
Resource |
API, MCP |
integrations:git:repo:write |
Change repository files through generic Git connectors |
Resource |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
integrations:ssh:view |
View configured external SSH servers |
— |
API, MCP |
integrations:ssh:manage |
Add and configure external SSH servers and jump hosts |
— |
API, MCP |
integrations:ssh:use |
Execute approved commands on configured external SSH servers |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
integrations:cloudflare:view |
View configured Cloudflare connectors and synchronization status |
— |
API, MCP |
integrations:cloudflare:sync |
Refresh Cloudflare zones and token capabilities using the connector credential |
— |
API, MCP |
integrations:cloudflare:manage |
Create, edit, test, synchronize, rotate, and delete Cloudflare connectors |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
integrations:hosting:view |
View hosting accounts and connection status |
Resource |
API, MCP |
integrations:hosting:manage |
Connect, configure and synchronize hosting accounts |
Resource |
API, MCP |
hosting:resources:view |
View provider inventory and associated Opfield nodes |
Resource |
API, MCP |
hosting:resources:create |
Order provider VMs and install Opfield roles; may incur charges |
Resource |
API, MCP |
hosting:resources:power |
Start, shut down and reboot VMs; all hosted roles are affected |
Resource |
API, MCP |
hosting:resources:resize |
Change VM resources; may change provider charges |
Resource |
API, MCP |
hosting:snapshots:view |
View provider snapshots and snapshot folders without changing the VM |
Resource |
API, MCP |
hosting:snapshots:create |
Create provider snapshots; storage may incur charges |
Resource |
API, MCP |
hosting:snapshots:delete |
Permanently delete provider snapshots |
Resource |
API, MCP |
hosting:snapshots:restore |
Replace current VM data with a snapshot |
Resource |
API, MCP |
hosting:snapshots:folders:manage |
Create snapshot folders and move snapshots between folders |
Resource |
API, MCP |
hosting:resources:delete |
Destroy provider VM data or cancel HOSTKEY rental |
Resource |
API, MCP |
hosting:resources:recover |
Restart Opfield daemons or explicitly retry a failed installation |
Resource |
API, MCP |
hosting:billing:view |
View account balance, charges, invoices and transactions |
Resource |
API, MCP |
hosting:billing:topup |
Create HOSTKEY deposit invoices; payment remains provider-hosted |
Resource |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
housekeeping:view |
View housekeeping configuration, stats, and run history |
— |
API, MCP |
housekeeping:run |
Manually run housekeeping tasks |
— |
API, MCP |
housekeeping:configure |
Edit housekeeping configuration and schedule |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
license:view |
View Opfield license status and entitlement details |
— |
API, MCP |
license:manage |
Activate, update, or remove the Opfield license |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
ai:workspace:use |
Use the AI Workspace interface and embedded assistant |
— |
— |
feat:ai:use |
Use Opfield Inference and view personal inference usage |
— |
API, MCP |
feat:ai:configure |
Configure AI settings and providers |
— |
— |
ai:skills:manage |
Create, edit, enable, disable, and delete AI Workspace skills |
— |
— |
ai:sandbox:use |
Run bounded AI sandbox jobs |
— |
— |
ai:sandbox:tier:medium |
Run AI sandbox jobs with medium resource limits |
— |
— |
ai:sandbox:tier:high |
Run AI sandbox jobs with high resource limits |
— |
— |
ai:sandbox:manage |
View and kill AI sandbox jobs |
— |
— |
mcp:use |
Allow this user account to access the remote MCP server with OAuth |
— |
— |
| Scope |
Description |
Restrictions |
Tokens |
inference:setup |
OAuth-only authorization for the companion CLI Inference setup resource; not assignable to users or custom groups |
— |
— |
inference:providers:view |
View inference providers, connections, discovery, and quota |
— |
API, MCP |
inference:providers:manage |
Connect, update, synchronize, route, and disconnect inference providers |
— |
API, MCP |
inference:models:manage |
Create, publish, replace, and delete inference models |
— |
API, MCP |
inference:limits:manage |
Configure default and per-user inference budgets |
— |
API, MCP |
inference:usage:view |
View system-wide and per-user inference usage |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
docker:containers:view |
View Docker containers |
Resource, Folder |
API, MCP |
docker:containers:create |
Create and duplicate containers |
Resource, Folder |
API, MCP |
docker:containers:edit |
Edit container settings and configuration |
Resource, Folder |
API, MCP |
docker:containers:manage |
Start, stop, restart, kill, and recreate containers |
Resource, Folder |
API, MCP |
docker:containers:environment |
Modify container environment variables |
Resource, Folder |
API, MCP |
docker:containers:link |
Let other workloads reach one port of a container or deployment through a container link |
Resource, Folder |
API, MCP |
docker:containers:delete |
Remove containers |
Resource, Folder |
API, MCP |
docker:containers:console |
Open interactive console in containers |
Resource, Folder |
API, MCP |
docker:containers:files:read |
Browse and read files in containers |
Resource, Folder |
API, MCP |
docker:containers:files:write |
Create, edit, move, and delete files in containers |
Resource, Folder |
API, MCP |
docker:containers:export |
Export portable container archives |
Resource, Folder |
API, MCP |
docker:containers:secrets |
View and manage encrypted secrets |
Resource, Folder |
API, MCP |
docker:containers:webhooks |
View and manage container webhook update triggers |
Resource, Folder |
API, MCP |
docker:containers:mounts |
Add, remove, or change container and deployment mounts |
Resource, Folder |
API, MCP |
docker:containers:migrate |
Migrate containers and deployments between Docker nodes |
Resource, Folder |
API, MCP |
docker:availability:manage |
Enable, scale, heal, and disable multi-node workload Availability |
Resource, Folder |
API, MCP |
docker:folders:manage |
Organize containers, deployments, Compose projects, networks, volumes, and images into folders |
— |
API, MCP |
Container logs, statistics, processes, and inspection are covered by docker:containers:view; there is no separate logs scope. Duplicating a container, and recreating it with changed settings, need docker:containers:environment and docker:containers:secrets in addition to create or manage access. Pulling the image while creating a container or Deployment is covered by docker:containers:create at the destination; docker:images:pull is needed only to pull images on their own. A database or storage link on a Deployment also needs docker:containers:manage on it, because every link change rolls it out, plus docker:containers:edit when the link changes its environment. docker:containers:manage authorizes start, stop, restart, kill, and recreate together; there is no restart-only scope. These scopes also apply to standalone containers that Opfield discovered but did not create. See Operate workloads without adopting them.
| Scope |
Description |
Restrictions |
Tokens |
docker:compose:view |
Discover and inspect Compose projects, services, monitoring, logs, revisions, and activity |
Resource, Folder |
API, MCP |
docker:compose:create |
Validate and deploy managed Compose projects; adoption also requires Manage Compose Projects |
Resource, Folder |
API, MCP |
docker:compose:manage |
Adopt projects and manage lifecycle, revisions, secrets, and bindings |
Resource, Folder |
API, MCP |
docker:compose:delete |
Delete Compose projects or run destructive down/delete-volume actions |
Resource, Folder |
API, MCP |
External Compose projects are read-only: docker:compose:view covers their inventory, monitoring, and aggregated logs, while lifecycle actions become available only after adoption. Individual containers that belong to any Compose project cannot be started, stopped, restarted, edited, or deleted through container scopes.
| Scope |
Description |
Restrictions |
Tokens |
docker:images:view |
View Docker images |
Resource, Folder |
API, MCP |
docker:images:pull |
Pull Docker images |
Resource, Folder |
API, MCP |
docker:images:delete |
Remove and prune Docker images |
Resource, Folder |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
docker:volumes:view |
View Docker volumes |
Resource, Folder |
API, MCP |
docker:volumes:create |
Create Docker volumes |
Resource, Folder |
API, MCP |
docker:volumes:edit |
Rename, relabel, resize, and adopt Docker volumes |
Resource, Folder |
API, MCP |
docker:volumes:delete |
Remove Docker volumes |
Resource, Folder |
API, MCP |
docker:volumes:export |
Export portable Docker volume archives |
Resource, Folder |
API, MCP |
docker:volumes:files:read |
Browse, open, and download Docker volume files |
Resource, Folder |
API, MCP |
docker:volumes:files:write |
Create, edit, upload, move, and delete Docker volume files |
Resource, Folder |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
docker:networks:view |
View Docker networks |
Resource, Folder |
API, MCP |
docker:networks:create |
Create Docker networks |
Resource, Folder |
API, MCP |
docker:networks:edit |
Connect and disconnect containers |
Resource, Folder |
API, MCP |
docker:networks:delete |
Remove Docker networks |
Resource, Folder |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
docker:registries:view |
View Docker registries |
— |
API, MCP |
docker:registries:create |
Add Docker registries |
— |
API, MCP |
docker:registries:edit |
Edit Docker registry settings |
— |
API, MCP |
docker:registries:delete |
Remove Docker registries |
— |
API, MCP |
docker:registries:internal:pull |
Pull from all internal registry repositories or selected repository scopes |
Resource |
API, MCP |
docker:registries:internal:push |
Push to all internal registry repositories or selected repository scopes |
Resource |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
docker:tasks |
View Docker task progress |
Resource |
API, MCP |
docker:tasks:manage |
Force-cancel active Docker tasks |
Resource |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
databases:view |
View saved database connections |
Resource, Folder |
API, MCP |
databases:create |
Create saved database connections |
Resource, Folder |
API, MCP |
databases:edit |
Edit saved database connections |
Resource, Folder |
API, MCP |
databases:delete |
Delete saved database connections |
Resource, Folder |
API, MCP |
databases:query:read |
Browse tables, keys, and run read-only database queries |
Resource, Folder |
API, MCP |
databases:query:write |
Insert, update, delete, and run write queries against databases |
Resource, Folder |
API, MCP |
databases:query:admin |
Run administrative or DDL database commands |
Resource, Folder |
API, MCP |
databases:credentials:reveal |
Reveal saved database credentials and connection strings |
Resource, Folder |
API, MCP |
databases:folders:manage |
Create, reorder, and remove database folders |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
databases:backups:view |
View database backup policies and run history |
Resource, Folder |
API, MCP |
databases:backups:manage |
Create, edit, and delete backup policies and delete run history |
Resource, Folder |
API, MCP |
databases:backups:run |
Start and cancel backup runs |
Resource, Folder |
API, MCP |
databases:backups:restore |
Restore a backup into a new or empty target database |
Resource, Folder |
API, MCP |
nodes:backups:execute |
Use a Storage Node as the executor for backup and restore jobs |
Resource, Folder |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
storage:view |
View storage connections, managed storage, and their status |
Resource, Folder |
API, MCP |
storage:create |
Create storage connections and managed storage |
Resource, Folder |
API, MCP |
storage:edit |
Edit storage connections and managed storage, restart or retry provisioning |
Resource, Folder |
API, MCP |
storage:delete |
Delete storage connections and managed storage |
Resource, Folder |
API, MCP |
storage:credentials:reveal |
Reveal saved storage credentials |
Resource, Folder |
API, MCP |
storage:credentials:use |
Let backups and storage copy jobs use saved storage credentials without revealing them |
Resource, Folder |
API, MCP |
storage:iam |
Create, revoke, import, and freeze managed storage access keys, and create and move workload bindings |
Resource, Folder |
API, MCP |
storage:objects:read |
List buckets and objects, read metadata, download objects, and create download links |
Resource, Folder |
API, MCP |
storage:objects:write |
Upload objects, create prefixes, and delete objects |
Resource, Folder |
API, MCP |
storage:objects:admin |
Create and delete buckets |
Resource, Folder |
API, MCP |
storage:folders:manage |
Create, reorder, and remove storage folders |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
notifications:alerts:view |
View notification alert rules |
— |
API, MCP |
notifications:alerts:manage |
Create, edit, and delete notification alert rules |
— |
API, MCP |
notifications:webhooks:view |
View notification webhooks and their delivery attempts |
— |
API, MCP |
notifications:webhooks:manage |
Create, edit, test, and delete notification webhooks |
— |
API, MCP |
| Scope |
Description |
Restrictions |
Tokens |
logs:environments:view |
View external logging environments |
Resource, Folder |
API, MCP |
logs:environments:create |
Create logging environments |
Resource, Folder |
API, MCP |
logs:environments:edit |
Edit logging environments and schemas |
Resource, Folder |
API, MCP |
logs:environments:delete |
Delete logging environments |
Resource, Folder |
API, MCP |
logs:environments:folders:manage |
Create, reorder, and remove logging environment folders |
— |
API, MCP |
logs:tokens:view |
View logging ingest tokens |
Resource, Folder |
API, MCP |
logs:tokens:create |
Create logging ingest tokens |
Resource, Folder |
API, MCP |
logs:tokens:delete |
Revoke logging ingest tokens |
Resource, Folder |
API, MCP |
logs:schemas:view |
View reusable logging schemas |
Resource, Folder |
API, MCP |
logs:schemas:create |
Create reusable logging schemas |
Resource, Folder |
API, MCP |
logs:schemas:edit |
Edit reusable logging schemas |
Resource, Folder |
API, MCP |
logs:schemas:delete |
Delete reusable logging schemas |
Resource, Folder |
API, MCP |
logs:schemas:folders:manage |
Create, reorder, and remove logging schema folders |
— |
API, MCP |
logs:read |
Search and inspect external logs |
Resource, Folder |
API, MCP |
Logging token and log-search scopes are qualified by the logging environment ID; their folder grants resolve through logging environment folders.
| Scope |
Description |
Restrictions |
Tokens |
status-page:view |
View status page configuration, exposed services, incidents, and preview |
— |
API, MCP |
status-page:manage |
Edit status page settings and exposed services |
— |
API, MCP |
status-page:incidents:create |
Create manual incidents and promote automatic incidents |
— |
API, MCP |
status-page:incidents:update |
Edit incident details and post incident timeline updates |
— |
API, MCP |
status-page:incidents:resolve |
Resolve active status page incidents |
— |
API, MCP |
status-page:incidents:delete |
Delete resolved status page incidents |
— |
API, MCP |
