Storage

Satusky uses Rook-Ceph for Kubernetes storage and CloudNativePG for Postgres on the primary cluster.

Current state

Area	Current state
Kubernetes block storage	Rook-Ceph-backed storage classes provide persistent volume claims where enabled.
Postgres	Managed Postgres uses CloudNativePG where the selected cluster supports it.
Managed Valkey	Valkey 9.1.1 rendered from the platform-pinned official chart, with private endpoints and persisted machine placement.
App persistent volumes	Created by deploy volume flags or [volume]; managed with 1ctl volumes.
Object storage	Ceph RGW exists at the platform layer, but current public CLI storage lifecycle is 1ctl volumes for app PVCs.

Do not make blanket claims that all data is replicated three times. Some pools and workloads intentionally use different durability tradeoffs.

User-facing volume lifecycle

1ctl deploy --volume-size 20Gi --volume-mount /data
1ctl volumes list my-app
1ctl volumes inspect VOLUME_ID

volumes inspect also accepts get as an alias. Resolve a volume through --app, --deployment-id, or --volume-id when a positional value is inconvenient.

Detaching is the currently supported direct-app volume transition:

# Stop attaching the claim to its deployment, but keep the PVC and data.
1ctl volumes detach VOLUME_ID

The CLI exposes volumes delete with destroy and rm aliases, but direct PVC destruction currently fails closed until the platform has a durable destroy-intent workflow. Do not bypass that protection with kubectl, finalizer removal, or a direct database edit. A normal direct-app deletion retains detached PVC data.

Marketplace packages have a separate lifecycle and can explicitly support --purge-retained; do not assume that option applies to ordinary app volumes.

Managed Valkey placement

1ctl valkey create uses automatic placement unless --machine-id is provided. Automatic placement intersects current Kubernetes Node state with commercial machine eligibility. The chosen machine ID is stored with the Valkey configuration and becomes required node affinity for every rendered Deployment or StatefulSet.

The workload also requires the node to advertise:

node.satusky.com/capacity-mode=rentable
node.satusky.com/marketplace-admission=open

Update and redeploy operations validate the persisted placement again. They fail closed when the machine is no longer eligible rather than silently moving a stateful workload. Persistent standalone Valkey Deployments use Recreate strategy so their ReadWriteOnce volume detaches before the replacement starts. Automated cross-machine Valkey migration is not currently available.