How jobs can run inline or on a separate worker

The current queue abstraction does not write jobs into Supabase. That keeps background dispatch out of the main relational workload.

For local development or simple deployments, jobs can still run inline inside the app request.

For heavier production workloads, the same queue can dispatch jobs over HTTP to a separate worker deployment.

Set JOB_QUEUE_MODE to inline to keep the current request-bound behavior.

Set JOB_QUEUE_MODE to worker and provide WORKER_SECRET plus WORKER_QUEUE_URL to send jobs to a separate worker endpoint.

If you run a dedicated worker app, set WORKER_APP_URL and let the app resolve /api/jobs/run automatically.

If both WORKER_QUEUE_URL and WORKER_APP_URL are omitted in worker mode, the app falls back to NEXT_PUBLIC_APP_URL plus /api/jobs/run.

The queue is worker-ready, but it is still intentionally simple. There is no durable retry store yet.

Use it for background cleanup and similar operational tasks first, then add durable queueing only when actual workload requires it.