Upstream contract
Authup beta.64 exposes the background worker as a positional role of the single listener command:
The retired spellings authup worker, server/core worker, and authup start --worker exit 1.
authup start worker runs background sweeps only: no HTTP listener, no console, and no migrations.WORKER_ENABLED maps to core.worker.enabled. The role requires it to be true and refuses to boot when false.- A normal
authup start process also runs the worker components while the key is true. When a dedicated worker Deployment is enabled, API pods must therefore set WORKER_ENABLED=false and the worker pod must set WORKER_ENABLED=true.
- The worker opens the normal database/Redis dependencies needed by its components, but never applies migrations. Start it after the migration Job.
Chart changes
- Add
templates/worker/ with the same image and args: ["start", "worker"] (or an equivalent command array that invokes the authup binary). It has no HTTP readiness/liveness probes and exposes no port.
- Default to one replica. More replicas are safe for batch-claimed jobs but unnecessary for the standard deployment.
- When
worker.enabled=true, set WORKER_ENABLED=false on the server Deployment and WORKER_ENABLED=true on the worker Deployment. Keep these as workload-local environment variables, not shared authup.yml values.
- Add the usual worker resources, annotations, security context, scheduling, PDB/HPA choices, and schema entries following the chart's explicit sibling-template convention.
- When the migration hook is enabled, set
MIGRATION_ENABLED=false on the server Deployment. The worker ignores migration enablement and still must start after the Job.
- Update NetworkPolicy for worker egress if the selected policy does not already cover its database/Redis traffic.
No listener means the image's HTTP healthcheck must be disabled or replaced for this workload.
Upstream contract
Authup beta.64 exposes the background worker as a positional role of the single listener command:
The retired spellings
authup worker,server/core worker, andauthup start --workerexit 1.authup start workerruns background sweeps only: no HTTP listener, no console, and no migrations.WORKER_ENABLEDmaps tocore.worker.enabled. The role requires it to be true and refuses to boot when false.authup startprocess also runs the worker components while the key is true. When a dedicated worker Deployment is enabled, API pods must therefore setWORKER_ENABLED=falseand the worker pod must setWORKER_ENABLED=true.Chart changes
templates/worker/with the same image andargs: ["start", "worker"](or an equivalent command array that invokes theauthupbinary). It has no HTTP readiness/liveness probes and exposes no port.worker.enabled=true, setWORKER_ENABLED=falseon the server Deployment andWORKER_ENABLED=trueon the worker Deployment. Keep these as workload-local environment variables, not sharedauthup.ymlvalues.MIGRATION_ENABLED=falseon the server Deployment. The worker ignores migration enablement and still must start after the Job.No listener means the image's HTTP healthcheck must be disabled or replaced for this workload.