Update to Render

{
  "name": "render-background-workers",
  "description": "Sets up and configures background workers on Render for queue-based job processing. Use when the user needs to process async jobs, consume from a queue, run Celery/Sidekiq/BullMQ/Asynq/Oban workers, handle graceful shutdown with SIGTERM, wire a worker to Key Value (Redis), or choose between workers and cron jobs for background work. Trigger terms: background worker, async jobs, queue consumer, Celery, Sidekiq, BullMQ, Asynq, Oban, job processing, SIGTERM, graceful shutdown.",
  "included_files": [
    {
      "relative_path": "references/graceful-shutdown.md",
      "size_in_bytes": 3515
    },
    {
      "relative_path": "references/queue-framework-setup.md",
      "size_in_bytes": 4893
    }
  ],
  "skill_md_contents": "---\nname: render-background-workers\ndescription: >-\n  Sets up and configures background workers on Render for queue-based job\n  processing. Use when the user needs to process async jobs, consume from a\n  queue, run Celery/Sidekiq/BullMQ/Asynq/Oban workers, handle graceful\n  shutdown with SIGTERM, wire a worker to Key Value (Redis), or choose between\n  workers and cron jobs for background work.\n  Trigger terms: background worker, async jobs, queue consumer, Celery,\n  Sidekiq, BullMQ, Asynq, Oban, job processing, SIGTERM, graceful shutdown.\nlicense: MIT\ncompatibility: Render background worker services\nmetadata:\n  author: Render\n  version: \"1.0.0\"\n  category: compute\n---\n\n# Render Background Workers\n\nThis skill explains **worker** services on Render: processes that **consume jobs from a queue** instead of serving HTTP. Pair with **render-blueprints**, **render-env-vars**, and **render-networking** when wiring `render.yaml` and private connectivity.\n\n## When to Use\n\n- Designing or debugging **queue-backed workers** (Celery, Sidekiq, BullMQ, Asynq, etc.)\n- Choosing between a **worker**, **Cron Job**, or **Workflow** for background work\n- Configuring **Render Key Value** as a **broker** (not a cache) with correct **eviction policy**\n- Implementing **graceful shutdown** so in-flight jobs are not lost on deploy\n\nPer-framework setup and signal-handling detail: `references/queue-framework-setup.md`, `references/graceful-shutdown.md`.\n\n## How Workers Work\n\n- **Long-running services** with **no inbound (HTTP) traffic**. Render 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**.\n- The typical pattern is a **poll loop**: the process connects to a **queue backend** (often **Render Key Value**, Redis-compatible **Valkey 8**) and **pulls jobs**.\n- 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.\n\n## Queue Framework Overview\n\n| Framework | Language | Queue backend | Notes |\n|-----------|----------|---------------|--------|\n| Celery | Python | Redis / Key Value | Most common Python task queue |\n| Sidekiq | Ruby | Redis / Key Value | Standard for Rails |\n| BullMQ | Node.js | Redis / Key Value | Modern Node queue (Redis-based) |\n| Asynq | Go | Redis / Key Value | Go async task processing |\n| Oban | Elixir | **Postgres** (not Redis) | Queue stored in the database |\n\n## Pairing with Key Value\n\n- Use **Render Key Value** as the **job broker** when your framework expects Redis.\n- Set **maxmemory policy** to **`noeviction`**. **`allkeys-lru`** and similar policies are for **caches**; evicting queue keys **drops jobs**.\n- Wire **`REDIS_URL`** (or your framework’s equivalent) via **`fromService`** with `type: keyvalue` and `property: connectionString` in the Blueprint.\n- **Blueprints require `ipAllowList`** on Key Value—include the CIDRs that should reach the instance (often `[]` for private-network-only access; see **render-blueprints** / Key Value field reference).\n\nSee `references/queue-framework-setup.md` for minimal app + YAML examples.\n\n## Worker vs Cron vs Workflow\n\n| Need | Use | Why |\n|------|-----|-----|\n| Always-on queue consumer | **Background Worker** | Polls continuously; long-lived process |\n| Periodic scheduled task | **Cron Job** | Runs on a schedule, **exits**; **12h max** per run |\n| Distributed parallel compute | **Workflow** | Each run gets its own instance; fan-out patterns |\n| High-volume or bursty jobs | **Workflow** | Scales per run; **no idle instance cost** between runs |\n\n## Graceful Shutdown\n\n- Before stopping an instance, Render sends **`SIGTERM`**, then waits up to **`maxShutdownDelaySeconds`** (**1–300**, **default 30**) before **`SIGKILL`**.\n- Workers should: **(1)** stop accepting new jobs, **(2)** finish the current job or **checkpoint** progress, **(3)** close connections, **(4)** exit **0**.\n- Set **`maxShutdownDelaySeconds`** to at least your **longest safe job duration** (see Dashboard or Blueprint).\n\nLanguage- and framework-specific handlers: `references/graceful-shutdown.md`.\n\n## Blueprint Configuration\n\nMinimal pattern: **`type: worker`**, **`runtime`**, **`buildCommand`**, **`startCommand`**, and **`envVars`** wired from Key Value.\n\n```yaml\nservices:\n  - type: keyvalue\n    name: jobs\n    plan: starter\n    region: oregon\n    ipAllowList: []\n\n  - type: worker\n    name: task-worker\n    runtime: python\n    region: oregon\n    plan: starter\n    buildCommand: pip install -r requirements.txt\n    startCommand: celery -A tasks worker --loglevel=info\n    envVars:\n      - key: REDIS_URL\n        fromService:\n          name: jobs\n          type: keyvalue\n          property: connectionString\n```\n\nOptional: **`maxShutdownDelaySeconds`** on the worker service for longer draining jobs.\n\n## References\n\n| Topic | File |\n|--------|------|\n| Celery, Sidekiq, BullMQ, Asynq, Oban setup + YAML | `references/queue-framework-setup.md` |\n| SIGTERM, `maxShutdownDelaySeconds`, per-language patterns | `references/graceful-shutdown.md` |\n\n## Related Skills\n\n- **render-deploy** — First deploy, CLI, service creation\n- **render-blueprints** — Full `render.yaml` schema, `fromService`, projects\n- **render-networking** — Private URLs, what can call what\n- **render-scaling** — Worker plans, instance counts, limits\n"
}