Shared Storage on Zerops

Zerops Shared Storage is a managed disk volume that mounts as a POSIX-compatible filesystem into your runtime services. Files written by one container are immediately visible to every other container that mounts the same storage, whether they belong to the same service or to different services in the project.

Under the hood it runs SeaweedFS ↗, a distributed filesystem optimized for high-volume storage. See Technical details for the architecture.

Quick start

Add a shared storage to your project and mount it into a runtime service with a zerops-import.yaml:

zerops-import.yaml

services:
  - hostname: teststorage
    # type is shared-storage:{mode}
    type: shared-storage:ha

  - hostname: app
    type: nodejs@22
    buildFromGit: https://github.com/myorg/myapp
    # mount the storage into /mnt/teststorage
    mount:
      - teststorage

The storage appears in the runtime containers at /mnt/teststorage. See Create shared storage for the GUI flow and configuration details, and Connect & mount for how the mount behaves.

Use cases

Shared Storage is a good fit for:

Configuration sharing: deploy configuration once and share it across services (e.g. Apache Airflow configuration and DAG files shared with all worker nodes)
Application data: user uploads, images, documents, and other assets shared between containers (avoid huge trees of tiny files, see performance considerations)
Fallback to object storage: applications that strictly require filesystem semantics and cannot work with object storage

Not suitable for databases

Do not run databases on Shared Storage. This includes SQLite, Prometheus TSDB, and other filesystem-based databases.

File locks are enforced per mount only: a lock held in one container does not prevent another container from writing to the same file, which leads to data corruption.
The underlying storage engine is an append-only chunk store: every modification writes new chunks, so the frequent small writes typical for databases cause heavy write amplification.

Use managed databases instead. For storing database backups, prefer object storage: it is cheaper and better suited for write-once files.

Deployment modes

Choose the reliability model when you create the service. It is set through the service type and is fixed for the life of the service.

Mode	type	What it is
Highly Available	`shared-storage:ha`	Two containers with data and metadata replicated 1:1 across both, with automatic repair when a node fails. Recommended for production.
Single container	`shared-storage:single`	One container, so lower cost but no redundancy. All data is lost if the container fails. Good for development and non-critical data.

Key limits

The storage holds at most 60GB of data, regardless of the disk resource in autoscaling. See storage capacity.
File locks work only within a single container's mount, not across containers. See filesystem capabilities.
The mount is available only in runtime containers, not during build and prepare phases.