Environment Provisioning
Separate from Booking Provisioning (Terraform triggered when a booking starts), an environment can have its own Terraform workspace attached to provision the environment's own infrastructure — the thing being booked, not something spun up per-booking.
Attaching a Workspace
- Pick an existing workspace from a project, or deploy a new one from a Template
- Today, the create/edit form allows attaching one workspace (or one template deploy) per environment
- Attaching a workspace automatically triggers a Terraform plan
The Environment Provisioning Tab
Each environment's detail page has a Provisioning tab showing:
- The environment's own aggregate provisioning status (the same 7-state status described in Environments: Unprovisioned, Provisioning, Provisioned, Provision Failed, Destroying, Destroyed, Destroy Failed)
- Per-workspace details: an execution-order badge, lifecycle stage, template badge, active/inactive state, and a richer 12-state run status (Queued, Pending Approval, Planning, Planned, Applying, Applied, Completed, Failed, Policy Failed, Errored, Cancelled, Destroying, Destroyed)
- A live indicator when a run is currently in progress, the last run's status and relative time, resource count, and cloud provider
Actions here link out to the workspace and run pages rather than triggering plans/applies inline — use Outputs to jump to the run, or Open to manage the workspace directly.
This tab also shows a Booking Provisioning summary alongside the environment's own workspace — see Booking Provisioning for that side of things.
Deleting an Environment
An environment with a linked workspace can't be deleted until the workspace is unlinked or deleted — see Environments for the full deletion rules. There's no destroy/snapshot step tied to the environment itself the way there is for a booking's workspaces — an environment's workspace is meant to persist for the environment's whole lifetime, not torn down automatically.
