Environments & deploy

App keys are per-deployment, so staging and production need their own keys and URLs. The clean way to manage this is a committed env file per environment, loaded at build time by your bundler or framework.

Per-environment config

Create committed env files (publishable keys + URLs are public):

.env.staging

MUHKOO_BASE_URL=https://api.staging.muhkoo.dev
MUHKOO_KEY=mk_test_pk_…   # minted against STAGING

.env.production

MUHKOO_KEY=mk_live_pk_…   # minted against PRODUCTION
# MUHKOO_BASE_URL is optional — it defaults to the hosted accelerator
# (https://api.muhkoo.dev), so production usually doesn't need to set it.

MUHKOO_BASE_URL is only required to point the client at a non-default accelerator — staging above, or a self-hosted deployment. When it’s unset, the client uses the hosted accelerator.

Caution

Only ever put publishable (pk) keys and URLs in client-bundled env vars — they’re inlined into the browser bundle. A secret (sk) key here would ship to every visitor. Keep local-only overrides in .env.local (gitignored).

Build each deployment against its matching env file — most bundlers and frameworks support per-environment env files. Wire one build script per environment so the right file is loaded:

package.json

{
  "scripts": {
    "build:staging": "<your build command, loading .env.staging>",
    "build:production": "<your build command, loading .env.production>"
  }
}

const client = new Client({
  apiKey: process.env.MUHKOO_KEY,
  baseUrl: process.env.MUHKOO_BASE_URL,
});

Deploying

Deploy each build to its own target so staging and production never overwrite each other — give them separate site names (and hostnames). Wire a deploy script per environment that builds with the matching env file, then ships:

package.json

{
  "scripts": {
    "deploy:staging": "npm run build:staging && <your deploy command for staging>",
    "deploy:production": "npm run build:production && <your deploy command for production>"
  }
}

If your app is a single-page app, configure your host to fall back to index.html for unknown routes so client-side routing keeps working.

Custom domains

Point each environment at its own hostname — e.g. app.example.com for production and app-staging.example.com for staging — through your host’s domain settings, and make sure TLS is provisioned for each before going live.

Tip

Wildcard TLS certificates often cover only a single subdomain level (*.example.com), so a multi-level host like app.staging.example.com can need its own certificate that takes a few minutes to validate. A single-level subdomain such as app-staging.example.com avoids that.

Minting per-environment keys

Issue a key from the developer portal pointed at the target environment, then drop the pk into that env file. Because keys are per-deployment, a staging key returns API key required against production and vice-versa — if auth/messaging 401s, check you’re using the key for the right environment.