Publishing & Bundles

Publish

airstrings publish
airstrings publish en es

Publishing takes the current strings for the active environment, signs each locale's bundle with Ed25519, and makes the bundles available on the CDN where SDKs fetch them. With no arguments it publishes all locales; pass locale codes to publish a subset. See Bundles, signing & CDN for how delivery works.

Bundles have product limits: up to 5 MB and 10,000 keys per bundle.

Listing bundles

airstrings bundles

Lists the published bundles for the active environment.

Offline-safe builds: bundles pull

Ship published bundles inside your app so SDKs can serve strings with no network (cold offline starts, SSG/SSR builds, CI):

airstrings bundles pull

This downloads the published, signed bundles for the active environment into airstrings/bundles/ at the workspace root, plus a manifest.json provenance record. Commit the folder:

git add airstrings/bundles
git commit -m "chore: update bundled fallback strings"

SDKs seed from the folder on startup, re-verifying every bundle before use. Getting the folder into your app is a one-time step per platform (Xcode folder reference, Android assets, Metro require, Go embed; on the web the folder is picked up automatically): each SDK page has the exact step. See Offline & fallback.

Guarantees

• Verified before written. Every bundle's Ed25519 signature is checked before anything lands on disk.
• Atomic. Files are staged and moved into place only after every bundle is fetched and verified. A failed pull leaves the previous state intact.
• Idempotent. The directory is mirrored against the manifest: re-running with no upstream changes produces zero diff, and locales that are no longer published are cleaned up.

Options

airstrings bundles pull dist/seed
airstrings bundles pull --locale en-US

A directory argument overrides the default output location and is persisted to the workspace config, so the bare command keeps working afterwards. --locale restricts the pull to one locale. On the first pull into a fresh directory, the CLI prints a short per-platform integration note; later pulls stay quiet.

CI tip: run airstrings bundles pull in CI or as a pre-release step to keep the committed snapshot fresh. It is non-interactive, output ordering is deterministic, and any failure exits non-zero, safe to gate a release on.

Drafts vs. published artifacts: see pull is not bundles pull.

Rotating and revoking API keys

airstrings apikey ls
airstrings apikey rotate
airstrings apikey revoke

apikey ls lists the project's keys with scope, permission and prefix; the IN WORKSPACE column (in_workspace in --json) marks the keys stored in this folder. apikey revoke revokes every key stored in .airstrings/config.json (environment keys, a project key and the shared-bucket key) and removes them from it; keys the API already rejects are just removed. The folder then uses your login. It never touches the login key (that is airstrings logout) or keys in environment variables. --json returns {revoked_key_ids, removed_dead_keys}. A key can only revoke itself: other keys are revoked by an owner on the project's API Keys page in the dashboard. apikey rotate revokes the workspace's project key and stores its replacement in one call. Keys cannot create keys: for CI, create a project key on the dashboard's API Keys page and set it as AIRSTRINGS_API_KEY. For CI across several projects, use AIRSTRINGS_ORG_API_KEY with a gated (non-full-power) org key created in the dashboard.

If a key leaks

If a stored key leaks (for example config.json was committed), run airstrings apikey revoke in that folder, then airstrings login. Keep config.json out of git: see Gitignore the credentials.

Promoting from the CLI

airstrings promote preview --to production
airstrings promote --to production

promote preview shows the pending diff and the dashboard link where a human applies it. promote --to applies it directly; only a full-power org key may, other keys exit 7 with the dashboard link.