AWS Parameter Store alternative for config that needs to move at runtime.
Parameter Store is useful for deployment-time values. Nona is for the values operators and apps need to change later: flags, thresholds, copy, kill switches, and server-only runtime configuration.
Runtime layer
Parameter Store is a deployment tool. Nona is an application control plane.
AWS Systems Manager Parameter Store is a strong fit for infrastructure configuration, boot-time settings, and values that are managed alongside cloud resources. The problem starts when every operational adjustment becomes a task-definition update, a deployment, or a request for AWS console access. That is too heavy for values that product and engineering teams expect to change during normal application operation.
Nona gives those runtime values their own home. Applications read from a Nona environment at runtime, while operators change typed parameters in the dashboard or through the CLI/API. You can still keep secrets and low-level infrastructure values in AWS, while moving feature flags, kill switches, limits, text, and JSON settings into a system designed for live application reads.
Where Nona fits
Nona does not replace every AWS Systems Manager use case. It gives application teams a small, self-hosted control plane for values that need versioned, audited runtime reads.
- You need values to change after a service has already been deployed.
- You want feature flags and typed runtime config in one dashboard/API.
- You want project, environment, scope, and API-key boundaries outside your ECS task definition.
- You want an import path from ECS secret mappings that currently reference SSM parameters.
What changes after migration
Moving application runtime values into Nona changes who can safely operate them and how quickly a change can take effect. The goal is not to remove AWS from your stack. The goal is to stop treating every non-secret application toggle as cloud infrastructure.
A dashboard and API for application teams, instead of every change flowing through AWS console access.
Typed remote-config entries, so booleans and JSON do not have to masquerade as deployment secrets.
Environment-specific reads with Nona API keys, separate from IAM permissions used to deploy infrastructure.
Auditability and rollback paths for config changes that happen after the service is live.
What the migrator imports
# Sign in once — the CLI saves the session, no token to copy around nona auth login --base-url https://nona.example.com # The saved session supplies the base URL and credentials from here on nona migrate parameter-store --task-definition ./task-definition.json --environment production --profile my-aws-profile --project backend-service --dry-run
Frequently asked questions
Is Nona a direct replacement for AWS Systems Manager Parameter Store?
No. Parameter Store is still useful for AWS infrastructure, deployment-time settings, and secrets workflows. Nona is a runtime configuration layer for application values that should be read and changed after deployment.
When should I move a value from Parameter Store to Nona?
Move a value when product, operations, or engineering teams need to change it without rebuilding or redeploying the application. Good examples are feature gates, kill switches, copy, numeric limits, JSON settings, and non-secret backend toggles.
Does Nona import SecureString parameters?
No. The AWS Parameter Store migrator imports SSM String parameters referenced by ECS task definition secret mappings. SecureString, StringList, and Secrets Manager references are skipped so secrets do not get pulled into a remote-config system by accident.
Can backend services read Nona config securely?
Yes. Nona supports server-scoped entries and environment-specific API keys. Backend-only values should stay server-scoped, while frontend apps should only receive frontend-scoped config.
Start with a dry run.
Review the target keys and source references before anything writes to Nona. The output does not print secret values.
Validate a migration