Storage and backups

Anything that has to keep its data across restarts, a database, an upload directory, a queue, gets a persistent volume. On top sits a backup and restore engine that snapshots a whole app on demand and rolls it back in three modes. Stateless apps need nothing from this page.

Persistent volumes

A container’s own filesystem is scratch space: restart or reschedule the pod and anything not on a volume is gone. Durable storage is a PersistentVolumeClaim mounted at the app’s real data directory. Your agent adds it to the Deployment and nyxory provisions it from your project’s storage pool.

The default shape is a single-replica Deployment plus one PVC. When you need stable per-pod identity and DNS for replication or clustering, use a StatefulSet with a headless Service (clusterIP: None) and per-pod storage via volumeClaimTemplates.

Getting it right on first init:

• Size from 10 GB up. Each PVC needs at least 10 Gi, and a PVC can be grown later but never shrunk.
• Point databases at a subdirectory. A fresh PVC already contains lost+found, and the official Postgres, MariaDB, MySQL, MongoDB, and Elasticsearch images refuse to initialize into a non-empty directory. Use a subfolder, e.g. PGDATA=/var/lib/postgresql/data/pgdata, or a subPath on the mount.
• One node per volume. App PVCs are ReadWriteOnce, so a PVC-backed pod stays at one replica. See Scaling and RAM.

Volume or bucket, and what happens on delete

Deleting an app deletes the volumes and buckets it owns. To keep a volume, deploy it with the label nyxory.com/retain-on-delete: "true" and without an ownerReference to the App; it then stays when the app goes and keeps counting against your storage pool until you delete it (kubectl get pvc -l app.kubernetes.io/instance=<app>). To keep a bucket, set deletionPolicy: Retain. A database or bucket declared in the repo’s deploy/ folder is different: it belongs to the project and stays when the app goes (see Configure your app from the repo). Take a backup before deleting anything you might want back: a full restore works even after the app is gone.

Backups and restore

Every app can be backed up on demand: a point-in-time, crash-consistent capture of its volumes (CSI snapshots), plus its manifests and the exact image it was running. Take one before a risky migration or a release. Backups fill your plan’s keep-N slots (three on the free tier, more on paid plans), each with trigger, size, phase, and image on the record.

Use the console (Backups page, or the backups on an app’s page) or your agent over MCP: nyx_backup with action: create takes one, nyx_backup_list lists them.

Restore runs through nyx_backup with action: restore or the console in one of three modes:

• data: roll the volumes back in place, app definition untouched.
• app: roll the image and definition back, data left as-is.
• full: the whole app, also after the app was deleted.

Every restore first takes a safety backup. app and full restores switch auto-deploy off so a push can’t race the rollback; switch it back on in the app’s Auto-deploy panel when you’re ready.

Scheduled backups. On the shared nyxory platform, backups are on demand today; for a nightly copy, run your own CronJob (a nightly dump to your bucket, see Jobs and CronJobs). On a dedicated instance, nightly backups can already be switched on for your instance; the app’s backup list shows each run with its trigger.

Object storage

On the shared nyxory platform, bring your own bucket. Store the credentials of any S3-compatible endpoint (AWS S3, Cloudflare R2, GCS, Backblaze B2) as a project or app secret and consume it with envFrom. Never bake keys into an image or ConfigMap. A Bucket resource is not provisioned there: nyx_deploy_manifests reports it as unsupported, so remove it from the manifest and wire your own bucket instead.

On a dedicated instance with object storage, declare a Bucket next to the app’s volumes and Deployment. If the app repo has a deploy/ folder, the bucket goes there as deploy/bucket.yaml and is kept on every push, see Configure your app from the repo.

apiVersion: nyxory.com/v1alpha1
kind: Bucket
metadata:
  name: uploads
spec:
  deletionPolicy: Delete   # default; Retain keeps the bucket and its data when the resource goes
  versioning: false        # default; true keeps overwritten objects

nyxory creates the bucket and sets up access in the strongest mode the instance offers (spec.credentials, default auto). On AWS the app reaches the bucket through the identity of its pod, with no key anywhere; the pod runs under serviceAccountName: <app>, and every app of the project reaches the project’s buckets, no app of another project does. On other providers the bucket gets its own access key and a bucket policy that refuses every other key, including the keys of other projects. The connection values land in a Secret named <bucket>-s3 in the same project; the app takes the whole Secret with envFrom:

Key	Value
S3_ENDPOINT, S3_REGION, S3_BUCKET	Where the bucket lives
AWS_REGION, AWS_ENDPOINT_URL_S3	The same, under the names AWS SDKs read by themselves
S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY	This bucket’s own key pair, only in key mode
S3_FORCE_PATH_STYLE	true where the endpoint is path-style, so set your S3 client to path-style or requests fail with DNS errors. false on AWS.

Build the client with the SDK’s default credential chain and the same code works in both modes.

• Five buckets per project by default. Capacity is not capped; object count and size are measured about every 15 minutes and shown on the resource.
• Versioning is a bucket’s only backup. App backups never see object storage.

Self-hosting MinIO as an app also works: it’s a stateful pod with its own PVC from your storage pool, and its backups are yours to run.

Export your data

From an app’s page in the console, Export snapshots the volume, moves it to object storage, and hands back a time-limited download link. No ticket needed. The export covers the app’s volume data; your manifests live with your agent and your repo. Export is available from the Starter plan up.

Secret values are not shown again once saved, in the console or by nyx_set_secret. Workloads and your agent inside the same project can read them; no other project can. Keep your own copy of anything you’ll need outside nyxory.