Nomad dev agent behavior limits regarding environment repeatability

Ephemeral State and Configuration Drift

The nomad agent -dev command provides a single-process server and client bound to the loopback interface. While this simplifies local evaluation, the agent operates with an in-memory state. All jobs, allocations, and cluster configurations are discarded upon process restart, requiring full resubmission of workloads to restore the environment.

Furthermore, the dev agent applies permissive defaults that diverge from production-ready configurations. Specifically, the raw_exec driver is enabled by default and ACLs are disabled, which can mask permission errors or driver unavailability when moving jobs from a local development cycle to a secured cluster.

Repeatability Constraints

These behaviors create a gap between a convenient local sandbox and a repeatable development environment that mirrors staging or production. It remains unclear if the dev agent's ephemeral nature is sufficient for iterative testing or if parity requires a persisted, multi-node configuration using containers or VMs.

• Does the lack of state persistence in dev mode preclude its use as a baseline for repeatable local workflows?
• How can the gap between dev-mode driver defaults (like raw_exec) and production restrictions be reconciled without abandoning the -dev flag?