# Separate Workers

Sydekyks user and operator guide. Check feature availability and release-specific installation requirements.

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.

1

Create Worker Token

From the supported source checkout, use its pinned worker-token script and the procedure approved for the matching fork release:

```
npm run 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.

2

Configure Environment Variables

Copy this into the .env file on the worker machine - these are the recommended settings based on the Production Setup (https://docs.sydekyks.com/install/configure-operate/production-setup#recommended-config):

```
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

```

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.

3

Launch Worker Machine

Launch the worker machine and supply it with the generated token.

4

Verify Worker Operation

Verify worker registration and a harmless execution using the monitoring interface supplied by your release. A native paid worker-management screen is not assumed for Community.