Kubernetes
Deploy Savvy on Kubernetes as a single-replica Deployment with a PersistentVolumeClaim and liveness/readiness probes wired to the health endpoints.
Savvy runs on Kubernetes as a single-replica Deployment backed by a
PersistentVolumeClaim mounted at /data.
SQLite is single-writer
Do not scale beyond one replica, and use strategy: { type: Recreate } so the
old pod releases the database before the new one starts. Two pods writing the
same SQLite file will corrupt it.
Key requirements
- Storage: one
PersistentVolumeClaimmounted at/data(the SQLite database and uploads). Use a real block/file volume, not a shared network mount. - Update strategy:
strategy: { type: Recreate }— neverRollingUpdate. - Security context: the container runs as non-root (
www-data, uid82). Grant theNET_BIND_SERVICEcapability so it can bind port80.
Probes
Wire the Kubernetes probes to the health endpoints. The startup probe gives the app time to run migrations before liveness kicks in:
startupProbe:
httpGet: { path: /livez, port: 80 }
periodSeconds: 3
failureThreshold: 30
livenessProbe:
httpGet: { path: /livez, port: 80 }
periodSeconds: 10
readinessProbe:
httpGet: { path: /readyz, port: 80 }
periodSeconds: 10Remember to set APP_URL (and TZ) in the pod's env, matching the public URL
your Ingress/Gateway serves Savvy on — see Installation.
Helm
An official Helm chart is planned. Until then, deploy with the Deployment + PVC
- Service manifests described above.
Reverse proxy
Put Savvy behind HTTPS with Traefik or Nginx Proxy Manager. Forwarded-header handling means HTTPS links and real client IPs work with no extra config.
Backups
Back up and restore Savvy's SQLite database safely. The database runs in WAL mode, so checkpoint the WAL before copying the file — or use the built-in backups.