Skip to content

Environments

An environment is where a run happens: production for real work, staging to try things first. Each environment has its own value for every secret and its own approval rules. The script is the same in each; only the keys and the rules change.

Every workspace starts with one environment, production. While it has only one, there is nothing to choose: runs happen in production, and the app, the API, the command line and agents never ask.

Settings, Environments: production, marked Default, and staging, each with no approval and agents allowed, with Edit and Delete buttons and Make default for staging.Settings, Environments: production, marked Default, and staging, each with no approval and agents allowed, with Edit and Delete buttons and Make default for staging.Settings, Environments: production, marked Default, and staging, each with no approval and agents allowed, with Edit and Delete buttons and Make default for staging.Settings, Environments: production, marked Default, and staging, each with no approval and agents allowed, with Edit and Delete buttons and Make default for staging.

Owners and admins add environments in Settings → Environments → Add environment. A name is lowercase letters, digits and hyphens, such as staging or eu-test, up to 32 characters.

How many a workspace may have depends on its plan: Free includes production only, and Team and Business include more (see Plan allowances). At the limit, Reminix refuses a new environment with 402 plan_limit_reached. If a workspace moves to a smaller plan, its environments keep working; it just can’t add more.

With two or more environments, every way of running a script can name one. Leave it out and the run uses the workspace’s default, production unless you change it with Make default.

  • In the app: the Environment field on the run form, and on schedules and triggers.
  • From the API: the X-Environment header, on any call.
  • From the command line: --environment staging on any command, or reminix environment use staging to make it the default for later commands. Every answer says which environment it used, on stderr.
  • From an agent: each script’s tool takes an optional environment argument. See MCP server.
Terminal window
curl -X POST https://api.reminix.com/v1/scripts/refund-customer/runs \
-H "Authorization: Bearer $REMINIX_API_KEY" \
-H "X-Environment: staging" \
-H "Content-Type: application/json" \
-d '{ "inputs": { "orderId": "o_123" } }'

The run records its environment, and the Runs page shows it. A script’s code reads the name from the environment variable REMINIX_ENVIRONMENT, for example to pick an API’s test or live base URL.

A secret has one value per environment: a Stripe test key in staging, the live key in production. A run uses only its own environment’s value. If the value is missing, the run fails before it starts, and Reminix never borrows another environment’s value:

STRIPE_KEY has no value in staging — add it in Settings → Secrets

Each value lists its own hosts, so a staging value can go to a sandbox host that production never calls. See Secrets.

On Edit, an owner or admin sets two rules:

  • Approval: no approval, agents’ runs need approval, or every run needs approval (Business; owners and admins don’t wait). A run follows the stricter of its environment’s rule and its script’s own policy, so production can require approval for runs that staging lets through.
  • Agents: whether AI agents may run scripts there at all. An agent that tries anyway gets 403. People can still run scripts there.

Under Access → Can act in, an owner or admin can limit an API key or a connected agent to some environments, for example a CI key that only reaches staging. A limited key that names another environment gets 403. A key that can’t reach the default environment must send X-Environment on every call.

Delete removes the environment and its secret values; the dialog says how many values go with it. Reminix refuses to delete the workspace’s only environment, its default, or one that a schedule or trigger uses. Move those first. Past runs keep the environment’s name.

GET /v1/environments lists them, and GET /v1/environments/{name} reads one, with how many secret values, schedules and triggers use it. Adding, changing and deleting them (POST, PATCH and DELETE on the same paths) need environments:write, on a workspace API key or an owner’s or admin’s token. Agents connected through MCP can only list and read them.

The run.completed and run.failed webhook events carry the run’s environment, so a trigger can react only to production failures: "filter": { "environment": "production" }.