Persistence and operations

FitGuard has two kinds of state. Treat them differently when you move from development to production.

What is stored where?

In plain terms: FitGuard keeps a notebook (fitguard.db) of every request it handles: who asked, what it cost, whether it was cached. That notebook lives on the same drive as the app. Some hosting platforms hand the app a brand-new, empty drive on every restart or redeploy, so the notebook gets thrown out with it. The fix is to give FitGuard a permanent drive instead of a temporary one (most platforms call this a "disk" or "volume") and point it there, so the notebook survives restarts. A permanent drive alone doesn't protect against the drive itself failing, so back the file up separately too. The table below is the technical version of the same thing.

State	Default location	How to keep it
Request log and dashboard history	SQLite `fitguard.db` under `data_dir`	Persistent disk plus backups
Budget reservations and shared spend	Process memory with `budget.backend: local`	Redis with `budget.backend: redis`
Response cache	Process memory by default	Optional Redis cache for sharing between instances

Important: Redis does not replace fitguard.db. Redis protects shared budget/cache behavior; the SQLite file is what powers request history and dashboard reporting.

Recommended production config

port: ${PORT}
data_dir: /var/data
budget:
  backend: redis
  redis_url: ${REDIS_URL}
cache:
  enabled: true
  backend: redis
  redis_url: ${REDIS_URL}

Use this when the host provides a persistent disk mounted at /var/data and a managed Redis URL. On a VPS, use a path such as /var/lib/fitguard instead.

Move local data to production

Stop local FitGuard before copying SQLite so the file is consistent. Back up the original file, copy it to the production data directory, set matching ownership, then start FitGuard and check the dashboard. Do not copy a database into an active multi-instance deployment. For a host without persistent storage, start fresh and keep history locally or export it before migrating.

cp ./fitguard.db ./fitguard.db.backup
scp ./fitguard.db ubuntu@<server>:/tmp/
ssh ubuntu@<server> 'sudo install -o fitguard -g fitguard -m 600 /tmp/fitguard.db /var/lib/fitguard/fitguard.db'
# verify after restart:
curl -fsS https://<domain>/healthz

Backups

A persistent disk prevents ordinary redeploy loss; it is not a backup. Schedule copies of fitguard.db to storage outside the host and test restoring one. Take the copy while FitGuard is stopped, or use a SQLite-consistent backup procedure. Never commit the database: it contains operational request metadata.

Proxy, TLS, and scaling

FitGuard serves HTTP. Terminate HTTPS at Caddy, nginx, or the platform load balancer. For nginx, disable buffering for the dashboard SSE stream. Set trusted_proxies only to addresses you control. One SQLite file must not be concurrently written by multiple instances; use one instance with persistent storage, or accept per-instance dashboards and use Redis for shared budgets/cache.

Launch check: verify /healthz, log in to /dashboard, send one test request through /v1, confirm it appears in Requests, then redeploy and confirm it remains.

PreviousVPS NextTroubleshooting