Create an Environment from UI
Create an Environment using the Axio web interface. An Environment belongs to a Workspace and serves as a deployment target for infrastructure stacks.
Prerequisites
Ensure that you have permission to create Environments and that at least one Workspace already exists. If no workspaces exist, create one first under Organization → Workspaces.
Who can create environments:
- Owner and Admin — can create environments in workspaces they can manage.
- Member — can create environments when granted
environment:manageand manage access on the target workspace. Members who are Viewers on a specific workspace cannot create environments there. - Viewer and Unassigned — cannot create environments.
Users with environment-scoped access cannot create additional environments outside their assignment.
If you lack permission, the Create Environment button is disabled and a tooltip explains why. Contact an organization Owner or Admin via Administration → Roles & Access.
Step-by-Step Guide
Sign in to Axio
Sign in using your email and password, plus your Organization ID — an 8-character code shown on Organization → Overview. Use the Organization ID at sign-in, not the organization display name or slug.
Go to Environments
Navigate to:
Organization → Environments
You can filter the list by project or workspace using scope links from the Projects or Workspaces pages.
Click Create Environment
Click Create Environment on the toolbar, or Create Your First Environment when the list is empty.
Fill in Environment Details
Provide the following in the Create Environment dialog:
- Project (required) — The project that contains the target workspace.
- Workspace (required) — The workspace this environment belongs to. The list is filtered by the selected project.
- Name (required) — Unique within the selected workspace. Axio auto-generates an internal slug. Names are compared case-insensitively within the workspace.
- Description (optional) — A short summary of the environment purpose.
Note: The UI uses a single Name field (there is no separate display name). Environment owners and self-approval are configured after creation using Assign owner on the Environments list — not in the create dialog.
Review and Confirm
Review the entered information and click Create. Click Cancel or the back arrow to close the dialog without saving.
While the environment is being created, the button shows Saving…. If the name already exists in the workspace or validation fails, an error message appears in the dialog.
Environment Created
On success, the dialog closes and the environment appears on Organization → Environments. You are automatically granted access to the environment you created.
Recommended next step: Open the row actions menu and choose Assign owner to add environment owners and configure self-approval before running deployments.
Create Environment
Field reference
| Field | Required | Rules |
|---|---|---|
| Project | Yes | Must select a project that contains the target workspace. |
| Workspace | Yes | Must select a workspace within the chosen project. Creation requires manage access on that workspace. |
| Name | Yes | Must not be empty. Must be unique within the workspace (case-insensitive). A URL-safe slug is generated automatically. |
| Description | No | Free text shown on the Environments list. |
| Sensitive | No | Defaults to off. When enabled, restricts delete, archive, and destroy operations — see below. |
Assign owners and self-approval (after creation)
After the environment is created, configure governance from the Environments list using Assign owner in the row actions menu. This opens a separate dialog — it is not part of the initial create form.
Environment Owners
Assign users or groups as owners of an Environment. Owners can run workflows in the Environment and approve deployments when required.
Environment Owners can run workflows within the Environment.
Environment Owners can approve deployments when approval is required.
Assign one or more users or groups as Environment Owners.
When using Assign owner, at least one user or group must be selected before saving.
Skip self-approval for workflows
Controls whether the user who triggered a workflow can approve its deployment. Configure this in the Assign owner dialog.
If enabled (default)
The workflow initiator cannot approve their own deployment — even if they are listed as an owner. Another Environment Owner must review and approve.
If disabled
Self-approval is allowed when the initiator is an Environment Owner. At least one owner must still be assigned.
Production environments typically keep skip self-approval enabled for separation of duties.
What Happens Next?
After creating the Environment:
- The Environment becomes available under the selected Project and Workspace on Organization → Environments.
- Use Assign owner to configure owners and self-approval before production deployments.
- Deploy one or more Infrastructure Stacks into the Environment.
- Sensitive Environments cannot be deleted or archived and block destroy deployments for linked stacks.
- An Environment can be unassigned from its Workspace when editing (moved to the system Default Workspace) — system and Git-managed environments cannot be unassigned.
- Environments can be archived when eligible (not sensitive; system and Git-managed environments have UI restrictions).
- Organization and project lifecycle policies may apply TTL and destroy-protection rules to environments.
Sensitive environments
Mark an environment as Sensitive during creation or when editing it.
- Sensitive environments cannot be deleted
- Sensitive environments cannot be archived
- Destroy deployments for linked stacks are blocked
Discovery runs
From Organization → Environments, open Discovery runs to view PR-driven stack discovery history — provisioned stacks, plans, PR-close destroy actions, discovery status, and related details.