Skip to main content
A support ticket arrived: a customer’s 40 MB export was rejected. The culprit was a single number — an upload limit — baked into a configuration file inside Tidepool’s container image. Changing that number required editing the file, rebuilding the image, pushing it, and rolling out every API instance: twenty minutes of CI/CD just to update one value. So why was that number inside the image? When Maya first containerized the app, putting configuration in the image was straightforward. That works until values need to change more often than code.
A presentation slide showing a deployment workflow with icons for "edit," "rebuild," "push," and "twenty minutes" and the text "A 40 MB export, rejected." Below are Docker whale icons and server boxes labeled box-1 through box-4 with check marks.
Maya could have stored the limit in Vault — Tidepool already integrated Vault — and fetched it from the template at runtime. But Vault is designed to manage credentials: issuing ephemeral secrets, rotating them, leasing them, and auditing access. That’s powerful but heavyweight for a non-secret numeric limit, and it creates an additional operational dependency.
A presentation slide titled "Vault Is Too Much for This" showing a yellow inverted triangle labeled "expiry, rotation, audit" and the text "A 40 MB export, rejected." Along the bottom are four server illustrations with Docker whale icons labeled box-1 through box-4.
Nomad provides a simpler, built-in option: Nomad Variables. They are encrypted configuration values stored in Nomad’s state store, replicated across Nomad servers, and governed by the same ACL rules — no separate cluster required.
A presentation slide titled "Nomad Variables" showing icons for a built-in database and an encrypted-at-rest padlock with the caption "Nothing extra to install." Below are Docker whale icons and four labeled server boxes (box-1 to box-4) illustrating deployment.
Example — create the variable at a path that reflects job/group/task:
Why that path? Reading it backwards — server (task), api (group), tidepool-api (job) — makes the variable’s scope and ownership obvious. Nomad grants a task read and list access to variables under its own path automatically; you don’t need an extra ACL rule for that. The API can read its own configuration, cannot read the CSV worker’s, and cannot read another team’s. The path is the permission boundary. To inject the variable into the running app, use a Nomad template block. The template mechanism is the same one used for secrets and other dynamic values: the nomadVar function fetches the variable by path and key. Nomad renders the file before the task starts and re-renders it when the variable changes, writing a plain file that the application reads.
A presentation slide titled "nomadVar in a Template" showing a folder and shield icon with the caption "the path is the rule its own prefix" and the bold text "Its own prefix, and nothing else." Below are four server/container illustrations with Docker whale icons labeled box-1 through box-4.
A typical template snippet that writes the variable into a config file and uses signaling to reload the app (instead of restarting it) looks like this:
Because change_mode is set to "signal", when the variable updates Nomad rewrites the file and sends the configured signal to the running process. For configuration-only changes, signaling avoids unnecessary restarts: there’s no need to restart three API instances just to update a single numeric limit.
A presentation slide titled "signal, Not Restart" that shows icons for a template and an ordinary config file with the caption "The app reads an ordinary file." Below are four Docker whale icons above server illustrations labeled box-1 through box-4, each marked with a green check.
The application must support reloading its configuration on the chosen signal (many do). The workflow is simple:
  • Maya updates the variable with nomad var put.
  • Nomad re-renders the template and writes the updated config file.
  • Nomad sends the configured signal (e.g., SIGHUP) to the process.
  • The process reloads the new upload_limit and the next upload succeeds — no rebuild, no pipeline, no redeploy.
You can inspect the current value and see when it last changed with nomad var get. When to use Nomad Variables vs Vault
  • Use Nomad Variables for non-secret configuration you want to change without shipping code: limits, feature flags, timeouts, or endpoints.
  • Use Vault when you require credential lifecycle management: rotation, expiry, leases, and detailed audit trails.
Comparison at a glance: See Nomad’s docs for details:
A presentation slide titled "Variables or Vault" showing three icons with captions — a document ("the file re-renders"), a radio tower ("the signal lands"), and a traffic light with large text "Nothing restarts." Below are four Docker whale and server icons labeled box-1 through box-4 with check marks.
Use Nomad Variables for non-secret configuration that you want to update without redeploying. Use Vault when you need rotation, expiry, or detailed audit trails for secrets.

Watch Video