For applications that share files across several layers — application servers reading uploads, balancers serving static assets, build pipelines fetching artefacts — it makes sense to centralize that data in a single container instead of duplicating it on every node. The platform exposes this pattern as the Shared Storage Container: a system container optimized for data storage, with the disk space, exports surface, and permission model needed to act as the single source of truth for shared files.
When to use a dedicated storage container
A Shared Storage Container fits when you need any of the following:
- The same dataset served read-only to a multi-node application layer and read-write to a build or admin layer.
- Common configuration files used by nodes on different layers or different environments under the same account.
- Database dumps written by a scheduled backup job, kept on a host separate from the database container.
- A staging area for assets shipped to multiple environments (dev, staging, production) under the same account.
What you get
Putting shared data in a dedicated container, instead of letting one of your application nodes carry both roles, has several practical benefits.
- Load isolation. If something on the storage container — a heavy export, a sync job — spikes I/O, it does not show up in your application’s response time. The two workloads are scheduled on separate containers.
- Lifecycle isolation. You can redeploy, scale, or rebuild your application layer without touching the data. The storage container keeps its disk, its exports, and its mount permissions across redeploys of the layers it serves.
- Environment hygiene. Several environments — dev, test, prod — can mount the same dataset under their own permission rules. Domain naming, mount paths, and access control stay consistent.
- Backup off-host. Mounting the database backup folder onto the Shared Storage Container moves backups off the database host. Scheduled dumps land on a separate disk on a separate container, which makes them survive a database redeploy.
External NFS exports
A Shared Storage Container can also act as an external NFS server. If you attach a public IP, configure /etc/exports, and open the NFS ports in the firewall, the container becomes reachable from clients outside the account. This is the building block for sharing data across PaaS installations or with external services that already speak NFS.
The external case requires explicit configuration on both sides — you configure the export on the storage container, and you mount it on each external client. The platform does not auto-link those because the client side is, by definition, outside its control.
For internal sharing — clients and server in the same account — the platform handles the second half automatically. Configure the export on the storage container and the corresponding mount appears on the target node without manual setup.
Where to go from here
- Storage exports — sharing a directory from your storage container to other nodes on the account.
- Mount points — mounting a remote directory onto a client container.
- External NFS server configuration — turning the storage container into an externally-reachable NFS server.
- Configure external NFS storage — connecting an off-platform NFS server.