Data, durability, and recovery

Nano's engine runs in memory but is event-sourced and crash-durable. When a data directory is configured, every durable command is written to an append-only journal and flushed to disk before the response returns — so a 200/204 means "persisted and will survive a crash". On restart the journal replays to reconstruct state exactly.

• What persists: deployments, instances, element progress, jobs, incidents, variables, completed history, and armed timers.
• What doesn't: job activation locks are deliberately volatile. A restart forfeits every lock, returning in-progress jobs to the activatable pool, so a worker simply re-activates after recovery. (Worker handlers should be idempotent — the standard at-least-once BPMN contract.)
• Where it lives: set NANOBPMN_DATA_DIR to a stable path. With neither a data dir nor a journal configured, Nano runs fully in-memory and persists nothing.
• Your authoring assets are separate: models and workers live in the NANOBPMN_WORKSPACE_DIR workspace, which survives deleting the engine data dir.