Storage Architecture

Satusky currently exposes two main storage primitives:

Primitive	Shape	Best for
Persistent volume	filesystem attached to pods	databases, local durable state
Object storage	S3-compatible API via Ceph RGW	files, media, backups, shared blobs

Persistent volumes

A deploy with volume flags creates and mounts a Kubernetes PVC:

Pod → VolumeMount → PVC → PV / StorageClass

1ctl deploy --volume-size 20Gi --volume-mount /data

Current state

• PVC creation is supported from deploy flows.
• Marketplace templates can request storage through template metadata.
• PVC lifecycle cleanup is still an area where users need explicit, trustworthy reporting.
• Grace-period cleanup can delete associated resources; persistent data preservation must not be assumed after destructive lifecycle events.

Target state

A mature storage surface should expose volume lifecycle as first-class operations: create, list, inspect, attach, detach, snapshot/backup, restore, and destroy.

Object storage

Object storage is backed by Ceph RGW and accessed over S3-compatible APIs. It is not mounted into pods like a PVC.

App → S3 client → Ceph RGW → Ceph object store

It is the better fit for files that should be reachable from multiple workloads or clusters.

Multi-cluster behavior

Primitive	Multi-cluster behavior
PVC	zone-local / cluster-local
Object storage	network-accessible shared service

If a database is deployed across clusters, storage replication is still an application/database concern unless a higher-level managed data product provides it.

Current gaps and target direction

Gap	Target
Volume lifecycle is mostly implicit through deploys.	First-class volume commands and explicit deletion semantics.
Billing, cleanup, and backup semantics can be misunderstood.	One lifecycle contract that says exactly what survives each action.
Marketplace templates may hide storage details.	Templates should reveal storage needs before install and hand resulting storage back to ordinary lifecycle management.