Got a Docker Compose file? Your project goes live in seconds — one command on cdn.com.tr. See how

CDN.com.tr Help

Persistent storage for a managed app

Give a container app a persistent volume so its data survives restarts and redeploys: enable storage, set the in-container mount path and size. One volume per app, mounted at one path, on CephFS.

Platforms and managed add-ons

Persistent storage for a managed app

Give a container app a persistent volume so its data survives restarts and redeploys: enable storage, set the in-container mount path and size. One volume per app, mounted at one path, on CephFS.

Panel path

  1. Management Panel
  2. CDN Hosting
  3. Open the app
  4. Persistent storage: on
  5. Mount path + size
  6. Save
  7. Deploy

Use cases

An app needs to keep files between deploys — uploads, a SQLite file, Prometheus data, a cache directory — instead of losing them every restart.

Workflow

  1. In the panel: open the app in CDN Hosting, turn on persistent storage, set the mount path (default `/app/data`) and size in GB, save, then deploy.
  2. Or with cdnctl on create: `cdnctl container apps create … --persistent-mount-path /app/data --persistent-storage-gb 5` (giving a mount path enables the volume).
  3. Or enable/grow later: `cdnctl container apps update --account <uuid> --app <app_uuid> --persistent-mount-path /app/data --persistent-storage-gb 10`, then deploy.
  4. Seed initial data if needed: `cdnctl container imports files --account <uuid> --app <app_uuid> --file data.tar.gz --target-path /app/data`.

Checks

  • One volume per app at one mount path; point it at the directory your app actually writes to (default `/app/data`).
  • Size only grows — a CephFS volume can be expanded (up to 100 GB) but not shrunk; pick a sensible starting size.
  • Storage changes take effect on the next deploy.
  • Persistent apps deploy with a Recreate strategy: the old instance stops before the new one starts, so each deploy has a short downtime (this prevents single-writer file-lock deadlocks).
  • Non-root images can write to the volume (the platform sets the pod fsGroup automatically).

Frequently asked questions

When should I use a persistent volume vs a managed add-on?

Use a managed add-on (Redis, PostgreSQL, MySQL/MariaDB, NATS) for databases, caches and queues — they are provisioned and tuned for you. Use a persistent volume for your app's own files: uploads, generated assets, a small SQLite file, Prometheus TSDB, etc. Rule of thumb: structured data store → add-on; app files → volume.

Is the volume good for a high-traffic database?

It is CephFS — a replicated network filesystem, great for durability and shared access but not for very high-IO or single-writer hot data. For heavy databases use the managed add-on; for very hot data prefer RAM. A "hot store" on a network volume becomes a bottleneck.

Can I mount more than one volume, or change the mount path later?

One persistent volume per app at a single mount path. You can change the path or grow the size, but each change needs a deploy and moving the path does not copy old data — plan the mount path up front.

Does my data survive a redeploy or a new image version?

Yes. The volume is independent of the container image, so deploys and image upgrades keep the data. It is removed only when you disable storage or delete the app.

Related pages

Object Storage and AWS CLI

Create buckets, rotate access keys, bind buckets to apps, and verify with the S3-compatible endpoint.

What you can run — capabilities and limits

A managed container platform (Kubernetes underneath), not a VM or shell server: you bring container images or a docker-compose.yml and the platform runs them, with managed Redis/PostgreSQL/MySQL/NATS add-ons, persistent volumes, internal service DNS, and HTTP(S) exposure through the CDN edge.