Skip to main content
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 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:

​
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 for endpoints and code samples.

​
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. Deployment targets are configured separately - see Deployments.
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.

​
Environment status

Each environment card on the Releases page shows the release it serves and its current state: 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: 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. 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 for endpoints, tokens, and code samples.
Older projects may still have a per-environment access token. These are deprecated - create a project access token scoped to the environment instead.

​
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.