Skip to main content
Nasiko ships no backup command, snapshot job, or disaster-recovery runbook today. This page tells you what state exists and where, so you can back it up the way you’d back up any stateful service.

​
Where state lives

The control plane holds no durable in-process state. Everything survives a restart because it lives in one of three external stores. The server applies its own migrations at startup, so a Postgres instance restored at an older schema version is brought up to date automatically. No manual migration replay.
Redis isn’t purely disposable. Flow-guard and MCP permission state genuinely are — short TTLs, recomputed from Postgres on demand. But the MAF worker queues executions on a Redis stream, and a queued-but-unclaimed execution has no second copy anywhere. If you run MAF workflows in production, size Redis durability accordingly.

​
What to do

  • Postgres — pg_dump / point-in-time recovery, or your provider’s managed snapshots
  • S3 / MinIO — your object storage’s replication or versioning, or cross-region replication for self-hosted MinIO
  • Redis — if you rely on MAF, treat it as a job queue (AOF persistence or managed Redis with replication), not a cache
If you provisioned Postgres and MinIO through the self-hosted Helm chart, both run as single-replica StatefulSets on a PersistentVolumeClaim with no backup CronJob or snapshot policy. Durability is whatever your storage class provides. For production, prefer a managed database service — it gives you backups, replication, and failover without building them on a self-managed PVC.

MAF

Workflow executions are the one thing in Redis that isn’t safe to lose.

Agent runtime and deployment

The two runtimes and what each expects from storage.