The Stack Harbor PaaS lets any container in an environment double as a storage server — alongside whatever the container’s primary role is. This pattern is called a compound container: an application server, a build node, or any other tier that already exists in your topology takes on a secondary role of exposing a directory over the platform’s internal storage protocol so other containers can mount it.
Used appropriately, a compound container avoids the operational and footprint overhead of standing up a dedicated shared-storage tier. Used inappropriately, it stacks I/O contention on a container that was sized for compute. This page covers when it makes sense and what to watch for.
When a compound container is the right choice
Small, low-traffic environments are the sweet spot:
- A single application server that needs to share assets with a worker.
- An environment where one container produces static content (build artifacts, generated images) and another distributes it.
- A development environment that wants the simplicity of a single mount without the cost of a separate storage node.
Two factors that make the compound pattern attractive:
- Latency. Local disk on a container is faster than reaching across the internal network to a separate storage node. If one of the containers is going to be the heaviest reader of the data anyway, putting the data on that container removes a network hop.
- Footprint. A separate storage tier is a real container with real cost. A compound container reuses what’s already in the topology.
When to use a dedicated storage tier instead
The compound pattern starts to hurt when:
- Multiple containers compete for the same disk and the I/O profile of one of them changes (a sudden traffic spike on the application tier slows the build node, or vice versa).
- The storage role outgrows the host container’s resource envelope — a compound that started as “share a small assets folder” becomes “primary asset store for the whole environment”.
- You need explicit HA or backup policy for the data, separate from the host container’s policy.
In those cases, switch to a dedicated NFS / shared-storage container. The topology change is non-destructive: you can stand up the new node, mount it from existing consumers, copy data across, and retire the compound role.
How the compound role is exposed
Inside the dashboard, the compound role is configured through the same mechanism that drives any storage container — the Add-Ons panel on the host layer offers a storage role that can be enabled, and the Mount points section on consumer layers points at the resulting export.
The platform handles the protocol details. From a consumer container’s perspective, a mount point onto a compound is indistinguishable from a mount point onto a dedicated storage tier.