> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gorules.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments

> Set up deploy targets like staging and production, with approval rules for each.

An environment is a deploy target that serves exactly one release at a time - for example staging and production. Your applications evaluate decisions against an environment, so the rules they run change only when you deploy a new release to it. That separation lets you keep editing and testing freely while production stays on a version you trust.

Environments are configured in project settings and appear at the top of the [Releases](/brms/deploy/releases) page. If none exist yet, the Releases page shows "No environments configured yet. Add one from project settings to start deploying."

## Stage and deployment environments

GoRules supports two environment types:

| Type | How it works | Best for |
| - | - | - |
| Stage | The release is served by GoRules and evaluated over its HTTP endpoint | Most teams; no infrastructure to run |
| Deployment | The release is pushed to your object storage (S3, Azure, GCS) and pulled by the GoRules Agent or an embedded SDK | High volume, edge, or offline evaluation |

### Stage environments

Stage environments are hosted in GoRules. Deploying is instant, and your applications call the environment's evaluate endpoint over HTTP - see [Developer tools](/developers/developer-tools) for endpoints and code samples.

```mermaid theme={null}
flowchart LR
    app["Your App"] --> brms["GoRules"]
    subgraph brms["GoRules"]
        staging["staging: v1.5.0"]
        production["production: v1.4.3"]
    end
```

### Deployment environments

Deployment environments push each release as a bundle to a deployment target - object storage that agents or embedded SDKs pull from and evaluate locally. Evaluation keeps working from the last pushed bundle even if GoRules is unreachable.

```mermaid theme={null}
flowchart LR
    brms["GoRules"] -->|push| storage["Object Storage"]
    storage -->|pull| agent["Agent / SDK"]
    app["Your App"] --> agent
```

Deployment targets are configured separately - see [Deployments](/brms/setup/deployments).

<Note>
  The two types behave differently when a release is removed: stage environments serving it stop evaluating, while deployment environments keep their last pushed bundle and continue working until a new release is deployed.
</Note>

## Environment status

Each environment card on the Releases page shows the release it serves and its current state:

| Status | Meaning |
| - | - |
| live | The release deployed successfully and is being served |
| deploying | A deployment is in progress |
| failed | The last deployment did not complete; the previous release keeps serving |
| no release | Nothing has been deployed to this environment yet |

Cards also show how long ago the last deployment happened. When you're deploying, an environment already serving the selected release is marked "already live".

## Create an environment

1. Open project settings and go to **Environments**.
2. Click **New environment**.
3. Enter a name, such as "staging" or "production", and a short key, such as "stg" or "prod".
4. Pick the type: Stage or Deployment. For a deployment environment, select an existing deployment target or create a new one by choosing a provider.
5. Choose a deploy approval mode, and for Group Approval, select the approval groups.

## Deploy approval modes

Approval modes control what happens when someone deploys a release to the environment:

| Mode | Behaviour |
| - | - |
| None | Deployments go through immediately |
| Open Request | Deploying opens a request for visibility; no approval needed |
| Single Approval | One approver must approve before the release goes live |
| Group Approval | One member from each assigned group must approve |

Environments with an approval mode other than None show a "requires review" chip in the deploy view. Deploying to them opens a deploy request instead of deploying directly, and the release goes live once the request is approved. See [Requests](/brms/review/requests).

Use None for development environments where speed matters, and an approval mode for production so every change gets a second pair of eyes.

## Evaluating against an environment

Every stage environment has its own evaluate endpoint. Point your application at the environment - not at a specific release - and deployments swap the rules behind the endpoint without any change on your side. Authenticate with a project access token; you can scope a token to a single environment so production credentials can't evaluate anything else. See [Developer tools](/developers/developer-tools) for endpoints, tokens, and code samples.

<Note>
  Older projects may still have a per-environment access token. These are deprecated - create a project access token scoped to the environment instead.
</Note>

## Undeploy or delete an environment

To stop serving a release without deleting the environment, use **Undeploy** in the environment's row menu in settings. Consumers of the environment immediately stop receiving the current release.

Deleting an environment removes it as a deploy target and undeploys any release it was serving. Both actions ask you to type the environment's name to confirm.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.