Storage on Zerops

Runtime containers on Zerops are volatile. Anything your application needs to keep must live outside the container — in a managed database, or in one of the storage services described on this page.

Container filesystem is volatile

The filesystem of a runtime container survives a restart, a reload, and a stop and start, but that is all:

Every deploy replaces the containers. The new containers contain only the deployFiles of the new build; whatever the previous containers wrote to disk is gone.
Containers are replaced when the service scales. Scaling horizontally creates and removes containers, each with its own disk.
Containers do not share a filesystem. A file written in one container is not visible in the others of the same service.

Use the container disk for temporary and scratch files only. Everything else — uploads, generated files, application state, anything shared between containers — belongs in a storage service or a database.

Storage services

Zerops offers three storage services. The first word of each name tells you the access model:

Service	Access model	Semantics	HA
Object Storage	S3 API over the network	Object semantics; best price and durability for uploads, media, and backups	Yes
Local Storage	Locally attached disk, single machine	Full single-kernel POSIX: locking, mmap, inotify across all connected containers	Not yet
SeaweedFS	Network filesystem, mounted or accessed over HTTP by your services	POSIX-like with network filesystem caveats (per-mount locks, write amplification)	Yes

Which one to use

Uploads, media, backups, logs, exports — Object Storage. Highly available, cheapest per GB, and independent of any runtime service; the default for most application data.
Anything that needs a real filesystem — Local Storage. SQLite and other embedded databases, single-node stateful apps such as Prometheus or Gitea, and filesystem state shared between services (certificates, caches). It is the only storage type where lock-dependent workloads are safe; see its trade-offs.
Files shared between containers over the network, with high availability — SeaweedFS. Zerops runs the managed cluster, your services mount it with weed mount from their start commands or talk to its filer HTTP API. Not for databases, see its storage engine behavior.
Existing Shared Storage setups — the service is already a SeaweedFS service. Take over the mount with the SeaweedFS migration guide, or move the data to Local Storage with its guide.