bex-disks

bex Persistent Disks

Persistent disks preserve files written beneath a service's configured mount path across deploys and restarts.

Before designing, configuring, resizing, transferring data to, snapshotting, restoring, or troubleshooting a disk, read references/persistent-disks.md.

When to Use

• Storing file uploads, CMS media, or user-generated content
• Running a self-managed database (MySQL, MongoDB, ClickHouse) on bex
• Deploying stateful infrastructure (Elasticsearch, Kafka, RabbitMQ, Mattermost)
• Understanding why scaling is blocked or zero-downtime deploys are disabled
• Restoring data from a disk snapshot

For managed databases, prefer bex Postgres (bex-postgres) or Key Value (bex-keyvalue) over self-managed alternatives on disk.

Core Decisions

• bex's default filesystem is ephemeral. Only files written beneath a disk's mount path persist across deploys and restarts.
• A disk-backed service is single-instance: it cannot use horizontal scaling or zero-downtime deploys.
• If file storage must be shared by scaled instances, use external object storage such as S3 or R2. Use bex Postgres for relational data and bex Key Value for managed cache or queue state.
• Choose the smallest current disk size that accommodates observed usage because capacity can increase but cannot decrease. For a small upload service, 1–5 GB is a reasonable starting range when supported by the current limits.

Blueprint Setup

For a native Node.js upload service, mount a subdirectory such as /opt/render/project/src/uploads, not the source root itself, and configure the application to write uploads there:

services:
  - type: web
    name: uploads
    runtime: node
    buildCommand: npm ci
    startCommand: npm start
    disk:
      name: uploads-data
      mountPath: /opt/render/project/src/uploads
      sizeGB: 5

Fetch the current disk documentation and Blueprint specification through references/persistent-disks.md before finalizing the mount path or size.