# Storage on Zerops


Runtime containers on Zerops are **volatile**. Anything your application needs to keep must live outside the container — in a [managed database](/postgresql/overview), 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`](/zerops-yaml/specification#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 |
| **Shared Storage** (deprecated) | Network filesystem | POSIX-like with network filesystem caveats (per-mount locks, write amplification) | Yes |

## Which one to use

- **Uploads, media, backups, logs, exports** — [Object Storage](/object-storage/overview). 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](/local-storage/overview). 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](/local-storage/overview#key-trade-offs).
- **Existing `mount:`-based setups** — [Shared Storage](/shared-storage/overview) keeps working but is deprecated. Move to Local Storage with the [migration guide](/local-storage/how-to/migrate-from-shared-storage), or to Object Storage if the data fits the S3 model.

For structured data, use a [managed database](/postgresql/overview) rather than files on any storage.

- [Object Storage](/object-storage/overview) — S3 compatible storage for uploads, media, and backups.
- [Local Storage](/local-storage/overview) — Persistent local disk volume with full POSIX semantics.
- [Shared Storage](/shared-storage/overview) — Deprecated network filesystem. See the migration guide.

## Need help?

Stuck, or want to share what you built? Our core team and community are on Discord.

- [Discord](https://discord.com/invite/WDvCZ54) — Join the Zerops community on Discord. Ask questions and share your tips.
- [zCLI](/references/cli) — Get more out of Zerops with the command-line tool.