Environments

Environments in Realm9 represent any infrastructure setup — development servers, staging clusters, production systems, or specialised test environments. They are the central resource that teams book, track costs against, and automate with Terraform.

Overview

Each environment can be:

• Booked by teams with configurable approval workflows
• Tracked for hourly costs and utilisation
• Automated through linked Terraform workspaces
• Extended with custom fields, software tracking, and access credentials
• Shared across multiple teams concurrently (with concurrency limits)

---

Environments List

Navigate to Environments in the sidebar to see all environments your organisation has access to.

Filters and Search

• Status filter — filter by operational status: Available, Occupied, Under Maintenance, Preparing, Offline
• Provisioning status filter — filter by provisioning state: Unprovisioned, Provisioning, Provisioned, Failed, etc.
• Environment Type — filter by your organisation's defined types
• Needs Approval — toggle to show only environments that require booking approval
• Advanced filters — build additional conditions on any custom field (text, number, date, select, etc.), with a Match All / Match Any toggle to control whether conditions are combined with AND or OR. Applied filters appear as removable chips and persist in the URL, so a filtered view can be bookmarked or shared

View Modes

Switch between four views using the toolbar — your choice is remembered across sessions:

• Grid — card-based overview of each environment
• Table — sortable, dense list view with all key fields
• Calendar — visualise environment bookings on a monthly calendar; hover a day to preview what's booked without opening it
• Timeline — a row per environment against a time axis, so you can see at a glance which are occupied and when the gaps are. Zoom between quarter, month, week and day; "Hide empty" (on by default) drops environments with nothing booked in the window

Calendar and Timeline show occupancy, not every booking. Both leave out bookings that were cancelled or rejected, and ones that expired before anyone approved them — none of those ever held the environment, and counting them would make a free environment look busy. Completed bookings stay, so past periods still read correctly. The Bookings section's own calendar and timeline list every booking regardless of status, so the same day can legitimately show a higher number there.

Summary Cards

The top of the list shows five status summary cards giving a quick count breakdown:

• Available
• Occupied
• Under Maintenance
• Preparing
• Offline

Export

Export the current list view as CSV or JSON using the export button in the toolbar. Export currently respects the Status, Environment Type, and Needs Approval filters only — an active search term, provisioning-status filter, or advanced/custom-field filters are not yet reflected in the exported file.

Pagination

Control how many environments appear per page: 6, 12, 24, or 48.

---

Creating Environments

1. Navigate to Environments in the sidebar
2. Click New Environment
3. Fill in the core details:

Basic Information

• Name — a unique identifier, letters/digits/underscore/hyphen/slash only (up to 100 characters). Name can be changed later from the environment's edit page with a live availability check — renaming only affects future logs and emails, historical entries keep the old name
• Display Name — optional friendly name shown in the UI (use this for free-text labels that don't fit the Name character restrictions)
• Description — free-text description
• Environment Type — select from your organisation's configured types, or use the "Manage types" link to add a new one on the fly (see Environment Types)
• Lifecycle Stage — Development, Testing, Staging, Production, or Deprecated
• Status — initial operational status. Only Available, Preparing, or Under Maintenance can be set at creation; Occupied and Offline are system-driven and set automatically later
• Hourly Cost — used for cost tracking and FinOps reporting
• Is Shared — if enabled, multiple teams can book the environment concurrently (set max concurrent teams: 2–20)
• Labels — up to 10 freeform, organisation-wide labels for organising and filtering environments (see Environment Labels)

Ownership

• Technical Owner — email of the person responsible for the environment's technical upkeep
• Business Owner — email of the person responsible for the environment from a business/project perspective

Booking Control

Booking settings only apply while the environment's status is bookable (Available or Occupied) — if the status is Preparing or Under Maintenance, this whole section is locked/dimmed until the status changes, though any values already set are preserved.

• Enable or disable bookings
• Require approval for all bookings — when enabled, pick a Booking Approval Workflow from your organisation's configured workflows (a warning appears if the selected workflow has no approval level that can attach Terraform workspaces, when booking provisioning is configured)
• Set maximum booking duration, in Hours or Days (up to 10,000 hours)
• Auto-Release After (hours) — if set, any active booking is automatically completed and the environment released after this many hours, even if the booking's scheduled end time is later; leave blank or 0 to disable

Maintenance Windows

Define scheduled maintenance periods. During a maintenance window, the environment is automatically set to Under Maintenance and restored afterwards. Fields include:

• Start and end time
• Recurrence (one-off or repeating)
• Notification lead time

Terraform Workspaces

Link Terraform workspaces to the environment — there are two distinct kinds:

• Environment Workspaces — provisions the environment's own infrastructure; see Environment Provisioning for attachment and the provisioning tab
• Booking Provisioning — one or more workspaces triggered automatically when a booking starts, with optional buffer time before start; see Booking Provisioning for how attachment, approval-gating, and teardown work

CMDB Import

If ServiceNow integration is configured, you can import CMDB data when creating the environment:

1. Select one or more ServiceNow CI classes to import from
2. Confirm — review each selected class, and optionally mark any of them as sensitive (encrypted, with a minimum viewing role of Admin Only or Provisioner & Admin)
3. Import — records are fetched and merged into the environment's custom fields, with per-class progress and error handling

Custom Fields

Any custom field groups enabled by your admin appear at the bottom of the creation form. If the environment is being created from an approved Environment Request, any custom-field values already collected on that request carry over as read-only reference tabs.

4. Click Create

---

Environment Types

Environment types are configured by your organisation (not a fixed list). Common examples include Development, Staging, Production, Testing, and Sandbox — but admins can define any types that match your team's needs.

Manage types under Settings → Environment Types: add, edit, drag-and-drop to reorder, set a colour and icon, and activate/deactivate a type (inactive types are hidden from the create/edit dropdowns but remain on any environment already using them). System-default types can only have their colour, icon, sort order, and active status changed — their name and description are locked. A type can't be deleted while any environment still uses it, or if it's a system default.

---

Status Systems

Environments have two independent status dimensions:

Operational Status

Reflects the current availability of the environment:

Available, Preparing, and Under Maintenance are the only statuses you can pick when creating an environment — Occupied and Offline are set automatically by the system (a booking starting, or a decommission completing).

Provisioning Status

Reflects the Terraform provisioning state of the environment:

---

Environment Detail Tabs

Each environment has a set of tabs. Admins can enable and reorder tabs via Field Mapping.

Overview

Core identity, ownership, status, lifecycle stage, cost information, and a Recent Activity card showing the five most recent things that happened (see below).

Recent Activity

The Overview tab ends with a Recent Activity card showing the five most recent things that happened to the environment, newest first and grouped by day. Unlike bookings and requests, an environment has no separate Activity tab — this card is where its history appears.

What it records:

• Status changes — available, occupied, under maintenance, offline, decommissioned — each showing the status it moved from and to, alongside provisioning status changes
• Edits — which fields changed, expandable to show old and new values, including owner and type changes
• Bookings — when a booking took the environment and when it released it
• Terraform — workspaces linked and unlinked
• Access — who viewed the access credentials, and who revealed a sensitive field. Visible to administrators only
• Lifecycle — created (and the request it came from, where there was one), archived, and decommissioned (and the decommission request that retired it)

A bulk operation applied across many environments collapses into a single entry showing how many were touched, rather than one line on every environment.

Environments that existed before this feature shipped keep the history that was recorded at the time, which covers fewer kinds of entry than is captured now.

Inherited from the request

An environment created from an approved request can carry groups of information across with it — what was entered in any additional form submitted on the request, and any request field group an administrator marked to inherit. Where the same form was completed more than once, only the latest round comes across. These appear as their own tabs, marked Inherited, alongside a link back to the request they came from.

They behave like the environment's own fields: editable when you edit the environment, and changing them here doesn't alter the original request. Sensitive ones follow the usual rules and stay hidden from anyone below the minimum role. See Carrying request details onto the environment.

Booking (Booking Control)

The same booking settings described in Creating Environments above, editable from the environment's own page:

• Enable or disable bookings
• Require approval, and which approval workflow applies
• Maximum booking duration and auto-release
• Linked Terraform workspaces for auto-provisioning on booking start (with buffer time)

Access Credentials

Store encrypted access details for the environment — endpoints, credentials, keys, and freeform instructions. Fields can be marked as sensitive; sensitive values are hidden by default and revealed on demand. Visible to PROVISIONER and above only.

Software & Services

Track software and applications running on the environment:

• Name, version, type (Database, Web Server, Cache, etc.)
• Notes per entry
• Add, edit, and remove entries

Documentation

Free-form markdown documentation and notes associated with the environment.

Terraform Workspace (Provisioning)

View the environment's linked Terraform workspace(s), provisioning status, and run history directly from the environment. See Environment Provisioning for the full detail — plans/applies are triggered by navigating to the linked workspace or run, not inline on this tab. Visible to PROVISIONER and above.

CMDB (ServiceNow)

If ServiceNow integration is configured, this tab shows synced CMDB data for the environment's configuration item. Fields can be mapped from ServiceNow CI attributes.

Custom Field Groups

Any custom field groups enabled by your admin appear as additional tabs with organisation-specific fields (configured under Field Mapping). Every field in the group is listed, including ones nobody has filled in — those read Not set, so a field added to the group after an environment was created is visible as something still to answer rather than silently absent. If the environment originated from an Environment Request with its own custom-field values, those appear as additional read-only reference tabs.

Deleting an Environment

Delete is blocked while the environment has:

• Any linked Terraform workspaces (unlink or delete them first), or
• Any booking that is active, pending, or approved (scheduled in the future) — cancel or complete those bookings first

Deleting an environment is permanent — it removes the environment's bookings, software entries, access credentials, and other related records along with it.

---

Booking an Environment

1. Open an environment and click Book
2. Set the start and end time
3. Provide a title and business justification
4. Submit — if approval is required, approvers are notified automatically

See Bookings for full booking documentation.

---

Environment Labels

Organise and filter environments using labels — freeform, organisation-wide tags (up to 10 per environment) that you create inline as you type. Unlike a fixed set of categories, any label your organisation has used before can be reused, so they naturally converge into a consistent set over time (e.g. cost centres, project names, compliance markers, technology stacks).

---

Best Practices

Naming Conventions

Use clear, consistent naming:

<project>-<environment>-<region>

Examples:
- web-app-dev-us-east
- api-staging-eu-west
- db-prod-us-west

Lifecycle Stages

Set the lifecycle stage to reflect where the environment sits in your delivery pipeline:

• Development — active development work
• Testing — QA and test workloads
• Staging — pre-production validation
• Production — live workloads
• Deprecated — scheduled for decommission

Cost Tracking

Set an hourly cost on each environment to enable:

• Budget monitoring in FinOps
• Utilisation reports
• Cost allocation by team or project

Shared Environments

For environments that multiple teams need to use simultaneously (e.g. a shared database or test network), enable Is Shared and set the maximum concurrent teams. Bookings will be allowed up to that concurrency limit without conflict.

Access Control

Realm9 uses role-based access:

• VIEWER — read-only access to environments
• USER — can view and book environments
• PROVISIONER — can manage Terraform, access credentials, and booking provisioning
• ADMIN — full control including creating, editing, and deleting environments

---

Next Steps

• Environment Provisioning
• Book an Environment
• Request a New Environment
• Decommission an Environment
• Connect Cloud Accounts
• Automate with Terraform
• Configure Approvals