Environments

Every axonpush app comes with two environments out of the box — Production and Development — and you can add more (staging, preview, per-PR, etc.) from the dashboard. Every event belongs to exactly one environment, and every API key is scoped to one environment by default.

Why

Before you hit production you want dev traffic isolated from real users. After you hit production you want incidents scoped to the environment where they happened, not filed against a global timeline. Environments are the axis axonpush uses to keep those two concerns apart — without making you operate two separate apps.

Defaults

When an app is created, two environments are seeded automatically:

Slug	Name	Production flag	Color
`production`	Production	✅	`#EF4444`
`development`	Development	—	`#3B82F6`

production is marked as the default environment on the app. Any API key created without an explicit environment choice inherits this default.

How API keys are scoped

Every API key (ak_*) is bound to exactly one environment via the environmentId column. The allowEnvironmentOverride flag controls whether that key is allowed to target a different environment on a per-request basis — it defaults to false for newly created keys.

# Key bound to production. Events go to production.
curl -X POST https://api.axonpush.xyz/v1/logs \
  -H "X-API-Key: ak_prod_..." \
  -H "X-Axonpush-Channel: 1" \
  -H "Content-Type: application/json" \
  -d '{ "resourceLogs": [ ... ] }'

# Different key for dev — events go to development.
curl -X POST https://api.axonpush.xyz/v1/logs \
  -H "X-API-Key: ak_dev_..." \
  -H "X-Axonpush-Channel: 1" \
  ...

Common pattern: rotate the API key per deploy environment (via secret manager / .env.production / .env.development) and leave everything else identical.

Override header

When a key has allowEnvironmentOverride=true, the caller can pin a specific environment per request:

X-Axonpush-Environment: staging

Works for OTLP (/v1/logs, /v1/traces) and Sentry-compatible ingest (/api/:channelId/envelope etc.). The resolved environment is echoed back in the response headers so you can verify where your events landed:

x-axonpush-resolved-environment: staging
x-axonpush-resolved-via: header-override

If the header is missing or override isn’t allowed, the key’s default environment is used.

Public ingest tokens

Browser-side code shouldn’t carry an ak_* key. Mint a public token (pt_*) scoped to a single channel + single environment via the dashboard or the /public-tokens API; the token cannot be used to target any other environment, regardless of override headers.

Environment attributes

Each environment stores a few flags that power dashboard UX:

Field	Purpose
`isProduction`	Dashboard renders these differently (red badge, stricter confirms).
`isEphemeral` / `expiresAt`	Temporary preview environments that auto-disappear.
`requireConfirmationForDestructive`	Typing-gate before wiping events, deleting channels, etc.

Audit log — every environment / key change is logged
OTLP ingest — supports X-Axonpush-Environment override
Sentry DSN ingest — same override semantics