Persistent disk

• SQLite databases (small apps, single-instance).
• File uploads stored to disk before being moved to object storage.
• Cache or state that’s expensive to rebuild on cold start.
• Self-hosted tools that need a data directory (Plausible, Umami, n8n, WordPress content, and similar).

​

Prerequisites

• A project on a paid plan that includes persistent disks.
• The project should be a single-container service. Persistent disks aren’t shared across containers; if you scale beyond one, only one container holds the data.

​

Enable a persistent disk

1. Open the project.
2. Go to Configuration.
3. Scroll to Persistent disk and toggle it on.
4. Set:
   • Mount path, the path inside the container to mount the disk at, for example /data.
   • Size, picked from the dropdown.
5. Save.

​

Choose the mount path carefully

​

How persistent disks are stored

• Your data survives host failure. If the host running your project goes down, the platform reschedules onto another host in the region and the volume reattaches. The disk follows the workload.
• I/O is networked. Expect durable cloud-storage latency, not bare-metal disk speeds. SQLite, uploads, and modest caches are fine. Write-heavy databases belong on a managed database. Apps that load thousands of tiny files per request should keep those files on the image and only put mutable data on the disk.

​

Disk sizes and pricing

​

Use the disk

// Node, writing to the mounted disk
import fs from "fs/promises";

const DATA_DIR = "/data";
await fs.writeFile(`${DATA_DIR}/state.json`, JSON.stringify(state));

# Python
import os, json

DATA_DIR = "/data"
with open(os.path.join(DATA_DIR, "state.json"), "w") as f:
    json.dump(state, f)

​

Resize a disk

1. Open Configuration → Persistent disk.
2. Pick a larger size.
3. Save.

​

Limits and constraints

• Size caps at 150 GB per project on standard plans. For larger volumes, contact support.
• One disk per project. You can’t mount multiple persistent disks at different paths.
• One container per disk. A persistent disk is a local volume, not a network share. Don’t enable autoscaling on a project that depends on a persistent disk for state; only one container will see the data.
• Region-bound. A persistent disk lives in the project’s region. Moving the project to a different region requires a fresh disk.
• Backups are your responsibility. Brimble persists the disk across deployments and host moves but doesn’t snapshot it. For data that must survive disaster, copy critical files to object storage on a schedule.

​

When not to use a persistent disk

• You need scale-out. Multiple containers reading and writing the same dataset want a managed database or object storage, not a local volume.
• Your data must be backed up automatically. Use a managed database (PostgreSQL, MongoDB, etc.); Brimble snapshots those.
• Your data is large. Beyond a hundred-ish GB, object storage with a small metadata DB scales better.

​

Troubleshooting

​

Next steps

• Files, small config and secret files mounted at a path (not writable app data).
• Volumes, lifecycle, types, and what belongs on a volume.
• Deploy a database, for state that needs scale-out, backups, and queryability.
• Deploy from a Docker image, when the image has its own data directory conventions.
• Builds, for how the runtime container is built and started.