Workers
A worker is a long-running Node.js process that belongs to a project. It sits behind the scenes: it consumes messages from the project’s RabbitMQ broker, does work, and reads or writes data through DaaS. Nothing about it is user-facing.
Use a worker when the job does not belong in a request/response cycle:
- Generating reports or exports that take longer than a browser will wait
- Resizing images, transcoding files, running OCR
- Sending scheduled or batched email and notifications
- Syncing with a third-party API on a timer
- Any retry-heavy job you want isolated from your app’s traffic
How the Pieces Fit
Workers come in two layers. First you enable the worker feature for the project, which provisions the shared infrastructure: a RabbitMQ broker and one EC2 instance that hosts every worker in that project. Then you create individual workers, each of which gets its own git repository, build pipeline, and process.
Every worker in a project shares the broker, the DaaS backend, and the EC2 host. They do not share code, repositories, pipelines, or environment files. Deploying one worker never touches its siblings.
Enabling Workers for a Project
Open a project and click Workers in the sidebar. The top panel shows the project-level enablement state.
Click Enable
Requires the create_workers permission. Provisioning starts immediately and the panel
switches to Provisioning.
Wait for provisioning
The page polls every 5 seconds and updates itself, so you can leave it open. This step provisions the RabbitMQ broker and the shared worker host, and it usually takes several minutes.
Confirm Active
Once the badge reads Active, a RabbitMQ panel appears with the broker’s connection details, and the worker list below it accepts new workers.
The enablement badge has four states:
| Badge | Meaning |
|---|---|
| Not enabled | The feature has never been enabled for this project. An Enable button shows. |
| Provisioning | Infrastructure is being created. The page polls until this resolves. |
| Active | Ready. You can create workers. |
| Failed | Provisioning failed. The reason is shown, along with a Retry button. |
Enablement has a 15-minute deadline. If provisioning has not finished by then, the project is marked Failed with a timeout reason. Retry is safe — it starts a fresh provisioning run from either the failed or not-enabled state.
The RabbitMQ Panel
Once the project is active, this panel gives you what you need to connect to the broker or inspect it by hand:
- Open management console — opens the RabbitMQ web UI in a new tab
- Management console and AMQP endpoint (
host:port) — always visible, both copyable - Credentials — username, password, and the full AMQP URL, hidden behind a Reveal credentials button
Revealing credentials requires the create_workers permission. Without it the panel says
so and the values stay hidden. You rarely need to copy these by hand: the platform can
write them straight into a worker’s environment file for you. See
Configuration & Messaging.
Creating a Worker
Below the RabbitMQ panel, the worker list has a create form.
Enter a name
1 to 100 characters. Names must be unique within the project, compared
case-insensitively and ignoring surrounding whitespace, so Reports collides with
reports.
Add a description (optional)
Shown under the name in the list. Useful once you have more than a couple of workers.
Click Create
The worker appears in the list as provisioning. The list polls every 5 seconds while any worker is in that state.
Creating a worker provisions, behind the scenes:
- A CodeCommit repository for the worker’s source
- A 3-stage CodePipeline (source, build, deploy) that fires on every push to
main - A pm2 process on the project’s shared worker host
- A CloudWatch log stream that collects the process’s stdout and stderr
When all of that is in place the row flips to active, and the worker’s detail page unlocks its runtime controls and starter download.
If creation fails, the row shows failed with the reason. Delete the row and try again.
Unlike project enablement, worker creation has no automatic timeout. A row that sits at provisioning far longer than a few minutes is stuck rather than slow — delete it and create a new one, and contact support if it keeps happening.
The Worker Detail Page
Click View details on any row. The detail page is the hub for one worker:
- Process status — whether pm2 reports the process as running, with a Refresh button and a Restart action
- AI IDE Setup — download a starter project wired to this worker’s git repository, pre-configured for VS Code, Kiro, Google Antigravity, or Claude Code
- Builds, Application logs, and Environment — three sub-pages covering deployment history, runtime output, and configuration
Runtime controls stay disabled until the worker is active, since there is no process to talk to before then.