Permissions & Quotas
Permissions
Worker access is governed by two organization permissions, assigned through roles. See Organizations for role management.
| Permission | Grants |
|---|---|
create_workers | Enable and retry the worker feature, create workers, restart a worker, edit its environment file, download the starter, reveal RabbitMQ credentials |
delete_workers | Delete a worker |
Organization membership alone — with neither permission — is read-only access:
- View the enablement status and the worker list
- View a worker’s process status
- Read application logs and build history
- View the environment file, without editing it
- See the RabbitMQ management URL and AMQP endpoint, but not the credentials
create_workers currently covers both creating and operating workers. There is no
separate operator permission, so anyone who can create a worker can also restart it and
edit its configuration.
This split works well in practice: give create_workers to the engineers who build and run
workers, and hold delete_workers more narrowly, since deletion destroys the worker’s
source repository.
Everything that changes state is recorded in the audit trail with the actor, the worker, the action, and a timestamp: enabling the feature, creating, deleting, restarting, updating the environment, downloading a starter, and workflow failures.
Quotas
Workers are capped per organization, not per project. The cap counts every worker across all of the organization’s projects, so five projects with two workers each is ten against the cap.
- Unset cap means unlimited
- Reaching the cap rejects new workers with “The organization has reached its worker quota”
- Deleting a worker frees a slot immediately
Contact your administrator to raise the cap.
Other Limits
| Limit | Value |
|---|---|
| Worker name | 1 to 100 characters, unique per project, case-insensitive |
| Log page size | 500 lines by default |
| Build history | 25 most recent pipeline runs |
| Build log per run | 1000 lines in-page, with a deep link for the rest |
| Enablement deadline | 15 minutes, after which the project is marked failed |
There is no per-worker memory or CPU cap. Workers in a project share one host, which is worth remembering: a worker that pins the CPU or exhausts memory degrades its siblings. Keep per-message work bounded and cap your own concurrency.
How Secrets Are Handled
The platform masks secret values by default at every boundary that returns them. RabbitMQ credentials and DaaS tokens are replaced with a fixed mask that shares no characters with the real value, so nothing leaks by inference.
Two places show real values, both deliberately:
- RabbitMQ credentials, after you click Reveal credentials. Fetched on demand and
only for holders of
create_workers. - The environment file, which is always shown in full. Masking it would mean saving an unchanged entry could overwrite a real secret with the mask, so the page shows real values and warns you instead.
Both surfaces put live credentials on screen. Be deliberate about screen sharing and screenshots when you’re on the Environment page or have credentials revealed.
Never commit secrets to a worker repository. Configuration belongs in the managed environment file, which deploys preserve — see Configuration & Messaging.