Volumes

Persistent storage that survives deploys, restarts and scaling.

By default, every container that Nodion runs is ephemeral, anything written to its filesystem disappears when the container stops. That's the right behavior for stateless web apps, but sometimes you need real persistent storage: user uploads, generated reports, a search index, a SQLite database. That's what volumes are for.

A volume on Nodion is a piece of network-attached storage that lives at the project level. You create it once, then attach it to one or more processes of your applications. Each process picks its own mount path inside the container and decides whether it gets read-write or read-only access.

Creating a volume

Open the Volumes section in the navigation and click + New Volume. You only need to set three things:

• Name — a human-readable label, like uploads or search-index
• Size — capacity in gigabytes (between 5 GB and 100 GB during the beta). You can grow a volume later, but you can't shrink it.
• Region — must match the region of the applications that will use this volume

The volume is provisioned within a few seconds and shows up in your project list. From there it's ready to be attached.

Attaching a volume to a process

Go to your application, open the Processes tab, click the volume button on the process you want to attach to, and pick the volume from the list. You'll be asked for two things:

• Container path — where the volume should appear inside the container, for example /app/uploads or /data
• Read-only — if checked, the process can read from the volume but not write to it

The mount becomes active on the next deploy or container restart of that process.

Sharing a volume across processes

The same volume can be attached to multiple processes at the same time, and each one can use a different mount path and read/write mode. A common pattern is letting a worker generate files into a volume read-write while the web process serves them read-only:

web    →  /app/public/uploads  (read-only)
worker →  /app/public/uploads  (read-write)Mount layout

You can also share a volume between processes of different applications in the same project, useful for data pipelines where one app produces and another consumes.

Resizing a volume

Open the volume's detail page and use the resize panel. The new size has to be larger than the current one. The resize is applied online without unmounting, so your processes keep running.

Detaching and deleting

Detaching a volume from a process removes it from that container on the next deploy. The volume itself and the data on it are not affected.

Deleting a volume permanently removes the storage and the data on it. Make sure no process has it attached before you delete, otherwise the next deploy will fail with a missing-volume error.

Where volumes live

Volumes are network-attached storage, mounted into your containers over a fast in-region network. That's what allows multiple containers (and even multiple processes across applications) to read and write the same data. Latency is in the single-digit millisecond range for typical operations, but volumes are not a substitute for a tuned database, if you need transactional guarantees and complex queries, use one of our managed database services and keep volumes for file-style data.

What goes on a volume vs. into the image

A good rule of thumb:

• Code and dependencies belong in the image. They're rebuilt on every deploy and don't need to persist across versions.
• Generated files at runtime (uploads, reports, caches that need to survive restarts) belong on a volume.
• Sensitive secrets belong in environment variables, not in volume contents.