Skip to main content

Storage backends for parameter values

By default, parameter values live in nullplatform's database. Storage backends let you keep those values in a system you control instead. Each backend is configured as a provider, so it inherits the standard NRN and dimensions model.

Why pick a storage backend​

You'll typically reach for one of these when:

  • A compliance requirement says secrets must stay inside a system you operate.
  • You already have a secret manager and don't want to mirror values across systems.
  • You want full control over how values are stored, retrieved, and audited, without nullplatform sitting in the data path.
For everything else, the built-in storage is the right default.

Nothing about the developer experience changes when you flip a backend on: parameter values still appear in the same place in the UI, and the CLI and API contract stay the same.

How both backends work​

Both variants share the same machinery: nullplatform never touches the value, and instead emits the parameter lifecycle events (parameter:store, parameter:retrieve, parameter:delete, parameter:notify) to a notification channel you configure. Your handler is what actually reads and writes the value. The only thing that changes between the two variants is what payload the events carry.

All backends are configured under Platform settings > Parameters & Secrets > Storage.

HashiCorp Vault Self-Hosted​

A typed variant for Vault. You register the Vault connection metadata (address, mount, base path) in nullplatform, and nullplatform forwards it to your handler inside each notification under context.provider.attributes.setup.*. The Vault token never leaves your side; your handler sources it from its own environment.

💡 Use this when you run Vault and want nullplatform to forward the connection metadata to your handler, while keeping the token inside your infrastructure.

Other agent-backed Storage​

A generic marker with no provider attributes. Same notification flow as the Self-Hosted variant, minus the typed Vault metadata in the event payload. Your handler decides where the value lives and how to reach it, using whatever configuration you wire on your side.

💡 Use this when your backend isn't Vault — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, an internal store, or anything else reachable from your infrastructure.

Comparing the two​

HashiCorp Vault Self-HostedOther agent-backed Storage
Setup effortMedium (provider + channel + handler)Medium (provider + channel + handler)
Storage locationHashiCorp Vault, addressed by your tokenAnywhere your handler writes to
Token / credentials managed byYouYou
Vault connection metadata forwardedYes, in context.provider.attributes.setup.*N/A (no provider attributes)
Best forTeams already running Vault on their sideTeams using a non-Vault backend

How values flow​

These backends sit between the parameter API and where the value finally lives. Both variants share the same agent transport; the difference is whether nullplatform forwards typed Vault connection metadata or just a bare marker.

The provider tells nullplatform which backend applies to a given {NRN, dimensions} tuple. NRN inheritance picks the most specific match: a backend configured at organization=1:account=2 covers every namespace, application, and scope underneath unless a deeper provider overrides it.

Next steps​