Platform and Apps · Setup & configuration · 8 min read

Set up environments and release policies

Describe each place the system runs, set its recovery targets and maintenance window, and decide how many approvers a release needs.

Before you begin

An environment is a place the system runs: development, staging, production or recovery. A release goes to exactly one environment, and its gates use that environment's recovery targets and maintenance window.

Create an environment

1. A configuration owner opens Platform > Releases > Environments and presses New.
2. Enter a Code (capitals, digits and _, 2 to 40: STAGING) and Name. The code cannot change and must be unique.
3. Choose the Tier: Development, Staging, Production or Recovery.
4. Optionally enter the Region, Database class (Small, Medium, Large) and Runtime.
5. Set the RPO (minutes), the oldest acceptable verified backup, from 1 to 10,080. The default is 1,440.
6. Set the RTO (minutes), the time you allow to restore, from 1 to 10,080. The default is 240.
7. Set Retention (days), 1 to 3,650.
8. Set the maintenance window: Window day, Window opens (HH:MM) and Window length (minutes). If you give a start time the length must be above 0: 'Say how long the window lasts.' With no start time any time is allowed.
9. Set the Time zone, an IANA zone such as Asia/Dubai.
10. Tick This server is this environment on the environment you are using. Only one can be current; ticking it clears the others.
11. Add Secret references, one per line, as env:NAME, vault:path or file:path. Never type a password: 'A secret is referenced as env:NAME, vault:path or file:path - never written here.'
12. Save. The environment is In review.

Approve and deploy

1. An approver other than the creator opens the environment and presses Approve, with an optional reason. The creator is refused: 'Somebody other than the person who prepared this environment must approve it.'
2. An operator presses Mark deployed.

Each approval adds a row in Approved versions, a snapshot of the tier, RPO and RTO at that time.

Change an approved environment

An approved or deployed environment cannot be edited: 'Send the environment back to review before changing it.' A configuration owner presses Back to review, edits, and it must be approved again. Only the creator is barred from approving, so avoid having the same person send it back, edit it and approve it.

Archive

Archiving is refused while a release is in flight on the environment: 'Release REL-0001 is still in flight here.' Archived environments are no longer offered when you create a release.

Release policies

A release policy says how many approvers and which optional gates a release needs.

1. A configuration owner opens Platform > Configuration > Release policies and presses New.
2. Enter a Code and Name.
3. Set Approvers needed, 1 to 3 different people.
4. List Optional gates, one per line: contracts, restore, sbom. These add a module contract check, a passed restore drill and an attached SBOM to the gates. Other gates are always asked.
5. List the tiers it applies to, or leave empty for every tier.
6. Add the Recovery plan template text if you have one.
7. Save. The policy is a Draft.
8. An approver other than the author presses Activate. The author is refused.

Rollout batch (%) is recorded but not enforced. There is no canary or percentage rollout.

A release picks its policy automatically if exactly one active policy fits the environment's tier.

Good to know

• The workload and drill screens measure against an environment's RTO and RPO only when a drill is linked to the environment. A drill started from the Restore drills screen is not linked, so its targets are not applied.
• The Environments list shows the active release, migration head, RPO and RTO, and which one is this server.