render-background-workers

Configures Render background workers for queue-based job processing with graceful shutdown.

Updated Aug 17, 2026
One-click install
npx skills add https://github.com/DingJun1028/esggo-kv --skill render-background-workers-dingjun1028
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: render-background-workers
Source: https://github.com/DingJun1028/esggo-kv/tree/main/.agents/skills/render-background-workers
Command: npx skills add https://github.com/DingJun1028/esggo-kv --skill render-background-workers-dingjun1028

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Setting up queue-consuming background workers on Render involves choosing the right service type, wiring a Redis-compatible broker correctly, and handling SIGTERM so in-flight jobs are not lost during deploys. This Skill provides the configuration patterns and shutdown guidance to do that reliably. ## Core Features & Use Cases - Worker Blueprint Configuration: Generate render.yaml services of type: worker wired to Render Key Value via fromService connection strings, with the correct noeviction maxmemory policy so queue keys are never dropped. - Framework Setup Guides: Minimal app and YAML examples for Celery (Python), Sidekiq (Ruby), BullMQ (Node.js), Asynq (Go), and Oban (Elixir, backed by PostgreSQL instead of Redis). - Graceful Shutdown Patterns: Per-language SIGTERM handlers and maxShutdownDelaySeconds tuning so workers stop dequeuing, finish in-flight jobs, and exit cleanly before SIGKILL. - Use Case: You need to move image-resizing jobs off your web service. Use this Skill to create a BullMQ worker service in render.yaml, connect it to a Key Value broker, and add a SIGTERM handler that drains active jobs within a 60-second shutdown window. ## Quick Start Ask the assistant to create a Render background worker in render.yaml that consumes jobs from a Key Value queue with graceful SIGTERM shutdown for your chosen framework.

Frequently Asked Questions about render-background-workers

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up a background worker on Render?▼

Define a service with `type: worker` in render.yaml, specifying runtime, buildCommand, and startCommand for your queue framework. Wire the broker connection via envVars using fromService with type keyvalue and property connectionString.

How do I connect Celery or BullMQ to Render Key Value?▼

Pass the Key Value connection string as REDIS_URL to your worker via fromService in the Blueprint. Set the Key Value maxmemory policy to noeviction so queue keys are never evicted like cache entries, which would drop jobs.

Should I use a Render worker, cron job, or workflow for background tasks?▼

Use a background worker for always-on queue consumers that poll continuously. Use a cron job for periodic scheduled tasks that exit within 12 hours, and a workflow for distributed parallel compute or bursty high-volume jobs that scale per run.

How does graceful shutdown work for Render workers?▼

Render sends SIGTERM, waits up to maxShutdownDelaySeconds (1-300, default 30), then sends SIGKILL. Your worker should stop dequeuing new jobs, finish or checkpoint the current job, close connections, and exit with code 0 within that window.

Can Oban use Render Key Value as its queue backend?▼

No, Oban stores its queue in PostgreSQL, not Redis. Provision a Render PostgreSQL database and wire DATABASE_URL via fromDatabase; only point Oban at Key Value if using an experimental custom backend.

Why are jobs lost or duplicated when my Render worker deploys?▼

This happens when the process ignores SIGTERM and gets SIGKILLed mid-job, or when maxShutdownDelaySeconds is shorter than your longest job. Implement a SIGTERM handler that stops dequeuing and drains in-flight work, and make job handlers idempotent.