storage (resource)

A shared cluster resource declaring the StorageClass definitions every app's PVC references. Sits alongside http-internal as a "shared by many apps, owned by the cluster" primitive — not a per-app component.

If you want to know what storage shapes are available before writing a new app, this is the catalogue.

What it composes

A handful of StorageClass resources, each tuned for a specific shape of workload:

StorageClass	Provisioner	Encryption	Replication	Used for
longhorn-encrypted	Longhorn	yes	yes (×2)	Default for most app PVCs — app config, databases, queues
longhorn-encrypted-1r	Longhorn	yes	no (×1)	Apps where data is regenerable and a replica is overkill
longhorn	Longhorn	no	yes	Rare — only when encryption-at-rest overhead matters
nfs-truenas	NFS CSI	no	n/a	Bulk media libraries on the TrueNAS NAS (read-mostly)

Specific apps' PVCs reference these by name in their kustomization.yaml's PVC patches.

How an app uses it

# In an app's PVC manifest
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <app>-data
  namespace: <app>
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: longhorn-encrypted
  resources:
    requests:
      storage: 20Gi

That's it — the PVC names the class and the provisioner takes over.

Why a separate resource, not per-app StorageClass

• Cluster-wide consistency. Every app sees the same set of options. There's no app inventing a one-off StorageClass with weird parameters.
• Encryption defaults. longhorn-encrypted is the default class for new apps. Choosing not to encrypt is an explicit decision (rare, with a documented reason).
• NFS access lives here. The cluster-side StorageClass (and the NFS CSI provisioner config) shouldn't be in any one app's directory — it's infrastructure, not a workload's concern.

Operational notes

• Encrypted Longhorn PVCs decrypt with keys stored in SOPS-encrypted Secrets — same age-key story as everything else. See Topics → SOPS / age key rotation for what happens when those keys rotate.
• NFS-mounted PVCs are read-mostly. Writes via NFS exist but bandwidth + latency are worse than Longhorn — don't put a database on NFS.
• A new StorageClass shouldn't be added casually. If a new shape is needed (e.g. a different replica count), add the class here and document its niche; don't pollute existing classes with conditionals.
• The matching Longhorn install lives in platform/longhorn; the NFS provisioner is part of the cluster's CSI layer.

Composition source

No partial — there's no README.md in k8s/resources/talos/storage/ yet. See k8s/resources/talos/storage for the actual StorageClass definitions.