bex-background-workers

bex Background Workers

This skill explains worker services on bex: processes that consume jobs from a queue instead of serving HTTP. Pair with bex-blueprints, bex-env-vars, and bex-networking when wiring render.yaml and private connectivity.

When to Use

• Designing or debugging queue-backed workers (Celery, Sidekiq, BullMQ, Asynq, etc.)
• Choosing between a worker, Cron Job, or Workflow for background work
• Configuring bex Key Value as a broker (not a cache) with correct eviction policy
• Implementing graceful shutdown so in-flight jobs are not lost on deploy

Per-framework setup and signal-handling detail: references/queue-framework-setup.md, references/graceful-shutdown.md.

Before deploying, restarting, or changing shutdown behavior, read references/deployments.md. Before configuring or troubleshooting a worker's outbound private-network connection, read references/private-networking.md. When choosing between a worker, cron job, and Workflow, read references/service-types.md.

How Workers Work

• Long-running services with no inbound (HTTP) traffic. bex does not expose a public URL or internal hostname for workers the way it does for web or private services—workers cannot receive private network traffic directed at them.
• The typical pattern is a poll loop: the process connects to a queue backend (often bex Key Value, Redis-compatible Valkey 8) and pulls jobs.
• Workers can initiate outbound connections on the private network—to PostgreSQL, Key Value, private services, web services (internal URLs), and the public internet—subject to your plan and firewall rules.

Queue Framework Overview