Environments
An environment is a place a Decision is served from, with its own runtime keys. Every organisation starts with two:
- Test, for trying a release with your own software
- Production, which is marked as production; a deploy an agent asks for waits there for a person to approve it
Open Environments in the sidebar to see what each one serves and to change them. They are listed in the order a release is promoted through them; you can add more (such as a staging environment), reorder them, and choose for each:
- How callers reach TypeSafe: BYOK, where each call brings the caller's own TypeSafe key; Relay, where the caller's app sends the request to TypeSafe itself so its key never reaches TypeFuse; or Managed, where TypeFuse's key answers (see Calling a Decision for the trade-offs)
- Production: whether it serves your live traffic
- Approval: which deploys wait for a person to approve them (see Approvals)
- Who approves: with approval on, named approvers, and whether a second person must always approve (see Who approves)
An environment can be deleted only if it has never been used. On the Free plan you can deploy to Test; production needs Founder, Scale or Enterprise. See Plans and usage.
Deploying a release
Open Deployments in a Decision. Each environment has a card showing the release it serves. Choose Deploy and pick:
- Release: the version to serve
- Canary (optional): a second release that answers a share of calls, from 1% to 99%
- Shadow (optional): a release that answers alongside the live one and is recorded, but whose answers are never returned to callers (shadows don't run for relayed calls)
- Goes live: now, or at a set time
- Note (optional)
When a release has been live in an earlier environment, the card offers to Promote it to the next one. A scheduled deployment can be cancelled before it goes live.
A deployment to a production environment warns you when the release has no Evaluation, or hasn't been
live in the environment before it in the promotion path. The warnings never block you: confirm to go
ahead, or cancel. typefuse deploy --check shows them without deploying.
Approvals
Each environment has one approval setting:
- Agent deploys only (where a new Production starts): a deploy you click in the app goes live at once, and so does one from a CI deploy token. A deploy an agent asks for (through MCP, an app you connected, a personal access token, or the CLI signed in with one) waits for one click from a person, and the person it acts for can give it.
- Every deploy: every deploy waits for a person to approve it, your own and CI's included.
- Off: every deploy goes live at once.
Where a deploy waits, it becomes a request, and the current release keeps serving until an approver puts the new one live. Removing a release works the same way.
Owners and admins approve. Under Every deploy, the person who made the request can't approve it, unless they are the organisation's only owner or admin. Under Agent deploys only, the person an agent acted for approves its request themselves. Either way the record notes that it was self-approved. Approvers see the request in their notifications and choose Approve or Reject on the Decision's Deployments page.
Approving is always done by a person in the app. Deploy tokens, personal access tokens and agents can request a deployment but can never approve one. A request an agent made says so: "Requested by Claude Code, acting for Tom". The request also says whether you can approve it, and why.
Who approves
An owner or admin chooses who approves in the environment's Edit dialog (under Environments). Both choices are off by default, so a solo founder is never blocked.
- Named approvers. Without names, any owner or admin (or a maintainer of a team that owns the Decision) approves. Choose people and only they approve there, whatever their role; viewers can be chosen too, for a compliance sign-off. Owners and admins can always change the list.
- Require a second person to approve. Nobody approves their own request, not even the organisation's only owner or admin. A request made by your agent (a personal access token or an app you connected) counts as yours, and so does one made by a deploy token you created. You won't be able to approve your own deployments there, including ones your agents request.
Without a second person, the only owner or admin still approves their own request (if they are among the named approvers, where there are any).
If a choice would leave fewer than two people able to approve, the dialog says so and asks you to confirm; invite someone or choose a second approver first if you can. A request that nobody can approve says so on the Deployments page and in notifications. To unblock it, an owner or admin changes who approves or turns the second person off, which is always allowed; the requester can also withdraw it.
Turning the second person on or off and changing the approvers is recorded in the audit trail, and every approved deployment records who approved it and, where an agent asked, which one.
Live major lines
An environment serves one release by default, but it can have more than one live release. When you
deploy a new major, the release it replaces keeps serving callers whose accepts names its major
line. The deploy dialog says so before you confirm: "1.4.2 keeps serving callers who accept ^1 until
you retire it." Tick Retire … with this deploy to stop those lines at the same time; the dialog
then names the lines that will stop and how many calls they answered in the last 7 days.
Each environment card lists every live release, one row each, with its calls in the last 24 hours:
- 2.0.0 · default: what callers get unless they ask for an older line
- 1.4.2 · for callers accepting ^1: an older major line
- a canary with its share, and a shadow, which never answers
To retire an older line on its own, choose Retire this line under it. The dialog warns you if
the line answered calls in the last 7 days. Retiring needs the same approval as removing the
Decision: at once for someone who could approve it, otherwise a request that waits for an approver,
with the line still serving. Callers that accept only a retired line get 409 INCOMPATIBLE_VERSION. See Versions and releases.
Rolling back
Rolling back is deploying: deploy the earlier release you want to serve. If you roll back from 2.x to
1.x, 2.x stays live as a line for callers that accept ^2. See
Versions and releases.
Deploying from CI
A deploy token (tf_deploy_…, under API keys → Deploy tokens) lets a pipeline deploy, schedule
and cancel. Owners and admins create them; each is shown once. In an environment that requires
approval, a deploy token's deployment waits for an approver like anyone else's.