Projects, Environments, and Promotion

AirStrings organizes everything in a three-level hierarchy:

• Organization: the account that owns everything else. Your company or team.
• Project: one app or product. Locales and string keys are defined per project.
• Environment: an isolated copy of the project's strings, such as development, staging, and production.

Every SDK configuration names all three (an organization ID, a project ID, and an environment ID) plus the environment's public signing keys. You can copy all of them from the dashboard under Project Settings → SDK Configuration, or from the setup snippet shown after your first publish.

Environments are isolated

Each environment has its own API keys, its own signing keys, and its own published bundles. Editing or publishing in one environment never touches another.

An SDK instance binds to exactly one environment: the environmentId in its configuration decides which bundles it fetches, and the public keys in its configuration decide which signatures it trusts. A staging build pointed at the staging environment can never accidentally render production strings, or vice versa.

Promotion

Maintaining the same strings by hand in three environments invites drift and typos. Promotion copies string changes from one environment into another, so a string you perfected in development lands in staging and production character-for-character, no retyping.

Promotion works from the target environment's point of view. On the target environment's Promote page:

1. Select a source environment.
2. Review the preview, a per-key diff of what the promotion would change.
3. Promote everything, or cherry-pick individual keys.

Promoted changes are published to the target environment, so they reach devices like any other publish.

Sealed environments

An environment can be sealed, which prevents all direct string edits in it. The only way to change a sealed environment is to promote changes from another environment. Sealing production is the recommended setup: every string that ships has, by construction, existed and been reviewed somewhere else first.

A typical flow

1. Develop: create and edit strings in development using the dashboard or the CLI, publish, and check them in a dev build.
2. Stage: promote the finished keys to staging and run QA against a staging build.
3. Ship: promote from staging to a sealed production. Production apps pick up the change within minutes, no app release required.