Define your config once, override it per environment
One source of truth for your application config and secrets. The right values land in every container at runtime, decrypted, with nothing baked into the image.
Consistent across every environment
Hard-coded config drifts between dev, staging and production, and secrets end up baked into images or copied between environments. Application Configuration keeps one set of values in Parameter Store and hands each environment exactly what it should have.
One hierarchy, sensible overrides
Lay your config out as a path: shared defaults near the top, environment specifics deeper down, up to five levels. The deepest value for a key wins, so you set a default once and override only what actually changes.
- Define a value once, override it per environment
- Up to five levels of hierarchy
- No per-environment copy-paste, no drift
Secrets stay out of your images
Secrets live as encrypted SecureString parameters and are decrypted only at runtime, inside your container, in your AWS accounts. Nothing sensitive is baked into an image or committed to a repo.
- SecureString parameters, decrypted at runtime
- Resolved in your account, not at build time
- Read-only filesystems supported by evaluating straight from stdout
Drops into how you already deploy
Run it as a sidecar container or copy the binary into your image. It writes export, shell, JSON or nested JSON, and runs on Linux and Windows. One small step in your entrypoint and the config is there.
- Sidecar container or copied binary
- export, shell, JSON or nested JSON output
- Linux and Windows, published as the base2/awsenv image
Built by base2Services
The configuration layer we run in production across our customers' AWS accounts.
base2Services is an AWS Advanced Consulting Partner specialising in platform engineering and managed AWS operations. This is part of how we run AWS for people. Once it is in place, teams stop thinking about config injection, which is exactly the point.
