Update to Render

{
  "name": "render-disks",
  "description": "Attaches and manages persistent disks on Render services—mount paths, sizing, snapshots, file transfers, and single-instance constraints. Use when the user needs persistent storage, file uploads, a custom database on disk, CMS media storage, or needs to understand why their service can't scale horizontally or use zero-downtime deploys. Trigger terms: persistent disk, disk, storage, mount path, sizeGB, SSD, file uploads, snapshots, disk restore, ephemeral filesystem.",
  "included_files": [
    {
      "relative_path": "references/sizing-and-snapshots.md",
      "size_in_bytes": 2167
    }
  ],
  "skill_md_contents": "---\nname: render-disks\ndescription: >-\n  Attaches and manages persistent disks on Render services—mount paths, sizing,\n  snapshots, file transfers, and single-instance constraints. Use when the user\n  needs persistent storage, file uploads, a custom database on disk, CMS media\n  storage, or needs to understand why their service can't scale horizontally\n  or use zero-downtime deploys.\n  Trigger terms: persistent disk, disk, storage, mount path, sizeGB, SSD,\n  file uploads, snapshots, disk restore, ephemeral filesystem.\nlicense: MIT\ncompatibility: Render paid web services, private services, and background workers\nmetadata:\n  author: Render\n  version: \"1.0.0\"\n  category: storage\n---\n\n# Render Persistent Disks\n\nPersistent disks are high-performance SSDs you attach to a Render service to preserve filesystem changes across deploys and restarts. Without a disk, services have an **ephemeral filesystem**—all local file changes are lost on every deploy.\n\n## When to Use\n\n- Storing **file uploads**, CMS media, or user-generated content\n- Running a **self-managed database** (MySQL, MongoDB, ClickHouse) on Render\n- Deploying **stateful infrastructure** (Elasticsearch, Kafka, RabbitMQ, Mattermost)\n- Understanding **why scaling is blocked** or **zero-downtime deploys are disabled**\n- **Restoring data** from an automatic disk snapshot\n\nFor managed databases, prefer **Render Postgres** (render-postgres) or **Key Value** (render-keyvalue) over self-managed alternatives on disk.\n\n## Critical Constraints\n\nThese constraints affect architecture decisions. Understand them **before** attaching a disk:\n\n| Constraint | Impact |\n|------------|--------|\n| **Single instance only** | Cannot scale horizontally (`numInstances` must be 1, autoscaling not available) |\n| **No zero-downtime deploys** | Old instance stops before new instance starts (brief downtime on each deploy) |\n| **Runtime access only** | Disk is not available during `buildCommand` or `preDeployCommand` (those run on separate compute) |\n| **Not accessible from other services** | Only the attached service can read/write the disk |\n| **Not available on cron jobs** | Attach to a web service, private service, or background worker instead |\n| **Not available on one-off jobs** | One-off jobs run on separate compute without disk access |\n| **Can increase size, cannot decrease** | Start small and grow as needed |\n\n## Setup\n\n### Dashboard\n\n1. Go to your service's **Disks** page\n2. Set the **mount path** (absolute path where persistent data is stored)\n3. Choose a **size** in GB\n4. Click **Add disk** — triggers a new deploy\n\n### Blueprint\n\n```yaml\nservices:\n  - type: web\n    name: cms\n    runtime: node\n    plan: starter\n    region: oregon\n    buildCommand: npm ci && npm run build\n    startCommand: npm start\n    disk:\n      name: cms-data\n      mountPath: /var/data\n      sizeGB: 10\n```\n\n## Mount Path\n\nOnly files written **under the mount path** are preserved. Everything else remains ephemeral.\n\n| Runtime | Source code path | Example mount path |\n|---------|------------------|--------------------|\n| Node.js, Python, Ruby, Elixir, Rust | `/opt/render/project/src` | `/opt/render/project/src/uploads` |\n| Go | `/opt/render/project/go/src/github.com/<user>/<repo>` | `.../data` |\n| Docker | Dockerfile's `WORKDIR` (commonly `/app`) | `/app/storage` |\n\n### Disallowed mount paths\n\nCannot mount at: `/`, `/opt`, `/opt/render`, `/opt/render/project`, `/opt/render/project/src`, `/home`, `/home/render`, `/etc`, `/etc/secrets`.\n\nSubdirectories of these paths are fine (e.g. `/opt/render/project/src/uploads`).\n\n## Snapshots\n\n- Render creates an **automatic snapshot every 24 hours**\n- Snapshots are available for **at least 7 days**\n- Restore from the service's **Disks** page in the Dashboard\n- **Full restore only** — you cannot restore individual files\n- **Destructive** — all changes after the snapshot are lost\n\n**Do not restore snapshots for custom database recovery.** Use database-native backup tools (mysqldump, mongodump) instead—disk snapshots may capture a corrupted database state.\n\n## File Transfers\n\n### SCP (via SSH)\n\n```bash\n# Download from service\nscp -s YOUR_SERVICE@ssh.YOUR_REGION.render.com:/mount/path/file ./local-file\n\n# Upload to service\nscp -s ./local-file YOUR_SERVICE@ssh.YOUR_REGION.render.com:/mount/path/file\n```\n\nRequires SSH access enabled for the service.\n\n### Magic-Wormhole\n\nAvailable on all native runtimes (install manually on Docker):\n\n```bash\n# On the service shell\nwormhole send /mount/path/file\n\n# On your local machine\nwormhole receive\n```\n\n## Common Patterns\n\n| Pattern | Service type | Mount path | Notes |\n|---------|-------------|------------|-------|\n| WordPress / Ghost / CMS | Web Service | `/var/data` or `/app/content` | Media uploads, SQLite |\n| Self-managed MySQL | Private Service | `/var/lib/mysql` | Use mysqldump for backups, not disk snapshots |\n| File upload API | Web Service | `/opt/render/project/src/uploads` | Single instance constraint |\n| Elasticsearch | Private Service | `/usr/share/elasticsearch/data` | Stateful search infrastructure |\n\n## Common Mistakes\n\n| Mistake | Fix |\n|---------|-----|\n| Expecting horizontal scaling with a disk | Not possible — disk services are single-instance only |\n| Mounting at a disallowed path | Use a subdirectory (e.g. `/opt/render/project/src/uploads` not `/opt/render/project/src`) |\n| Reading disk during build or pre-deploy | These run on separate compute — move logic to the start command |\n| Restoring disk snapshot for a database | Use database-native backups instead |\n| Starting with a large disk size | Start small — you can increase but never decrease |\n\n## References\n\n| Document | Contents |\n|----------|----------|\n| `references/sizing-and-snapshots.md` | Sizing guidance, snapshot lifecycle, restore procedures, cost patterns |\n\n## Related Skills\n\n- **render-web-services** — Deploy lifecycle, health checks (disk disables zero-downtime)\n- **render-private-services** — Internal services with disks (Elasticsearch, MySQL)\n- **render-blueprints** — `disk` field reference in `render.yaml`\n- **render-postgres** — Managed database alternative (no disk management needed)\n"
}