Separate Workers - Activepieces

Benefits of separating workers from the main application (APP):

Availability: The application remains lightweight, allowing workers to be scaled independently.
Security: Workers lack direct access to Redis and the database, minimizing impact in case of a security breach.

<Steps> <Step title="Create Worker Token"> Generate a worker token with the Activepieces CLI — no repository checkout needed:

```bash
npx @activepieces/cli workers token
```

When prompted, enter the same `AP_JWT_SECRET` used for the app server. The generated token will be displayed in your terminal — copy it and use it in the next step.

</Step> <Step title="Configure Environment Variables"> Copy this into the `.env` file on the worker machine — these are the recommended settings based on the [Production Setup](./production-setup#recommended-config):

```bash
AP_CONTAINER_TYPE=WORKER
# the public URL of your instance — the worker reaches the app at $AP_FRONTEND_URL/api
AP_FRONTEND_URL=https://your-instance-url
AP_WORKER_TOKEN=<token from the first step>
AP_WORKER_CONCURRENCY=1
AP_REUSE_SANDBOX=true
AP_EXECUTION_MODE=SANDBOX_CODE_ONLY
```

<Warning>
On the **APP** machine, set `AP_CONTAINER_TYPE` to `APP`. The default is `WORKER_AND_APP`, so without it the app keeps running an embedded worker.
</Warning>

</Step> <Step title="Launch Worker Machine"> Launch the worker machine and supply it with the generated token. </Step> <Step title="Verify Worker Operation"> Verify that the workers are visible in the Platform Admin Console under Infra -> Workers. ![Workers Infrastructure](../../resources/workers.png) </Step> </Steps>