Create your first project
A Nona project groups related config for one app or service.
Inside a project, you create environments such as:
developmentstagingproduction
Think of the project as the boundary for:
- your app’s config entries
- the API keys that can read them
- the environments that separate test and production values
- the audit and rollback history for that app
Suggested first setup
Section titled “Suggested first setup”Start with one project for your app, one production environment, and one non-production environment such as staging. For many teams, storefront with staging and production is enough to get real separation without adding unnecessary complexity.
In admin
Section titled “In admin”- sign in to the admin UI
- open
Projects - create a project if it does not exist yet
- open the project
- click
Add Environment - create
staging - click
Add Environmentagain - create
production
Once an environment exists, it appears as a selectable environment tab on the project page.
With the CLI
Section titled “With the CLI”For a fresh setup, create the first project and production environment with init:
nona init --yes --base-url https://nona.example.com --email admin@example.com --password <password> --project storefrontFor later project-only administration, create the project from a terminal:
nona projects create --name storefrontnona projects listThen open the admin UI and add any extra environments there.
How to think about environments
Section titled “How to think about environments”Use different environments when:
- the same key should have different values in staging and production
- you want to test a feature flag before enabling it in production
- you need a safe place to validate migrated config
Avoid creating lots of environments until you actually need them. A small, clear environment model is easier to operate.
Why this matters
Section titled “Why this matters”Projects and environments are the base for config entry reads, API key scoping, migration targets, rollback, audit history, feature flags, and broader remote config values.
A concrete example
Section titled “A concrete example”You might start with:
- project:
storefront - environment:
production - key:
Features:Checkout
Later, that same project might also hold:
Checkout:BannerTextCheckout:MaxItemsCheckout:Settings
That is why the project/environment layer comes first. Everything else builds on it.
Validate the setup
Section titled “Validate the setup”Confirm the project appears in Projects, staging and production show up as environment tabs, and the project is available as a later CLI target for commands such as nona entries set and nona keys create.
First project FAQ
Section titled “First project FAQ”How many environments should I create first?
Section titled “How many environments should I create first?”Start with two in most cases:
- one non-production environment such as
staging - one
productionenvironment
That is enough to test changes safely without creating an overly complex environment model.
Should I create environments in the CLI or admin?
Section titled “Should I create environments in the CLI or admin?”Use nona init for the first automated project and environment. For additional environments, use the admin UI.
That matches the current repo workflow most directly.
Should one app get one project?
Section titled “Should one app get one project?”Usually yes.
A Nona project is a good boundary for one application or service and the keys, environments, API keys, and history that belong to it.
What should I do right after the project exists?
Section titled “What should I do right after the project exists?”Add your first parameter.
That is the next step that proves the project is not only created, but also ready to hold real config or feature flags.
Next: Add your first parameter