Organization
What is an organization?
An organization is the top-level tenant boundary in Axio. Everything you manage—projects, workspaces, environments, stacks, runners, policies, and users—belongs to a single organization.
| Concept | Description |
|---|---|
| Organization | Your tenant: billing, members, governance, and all platform resources |
| Organization ID | An 8-character code shown on Organization → Overview. Use this at sign-in—not the organization display name or slug |
| Organization name | Human-readable display name for the tenant |
| Members | Users invited or provisioned with a role and optional scope |
After sign-in, the organization context determines which resources, permissions, and settings apply to your session.
Every new organization is also provisioned with a system Default Project, Default Workspace, and Default Environment for bootstrap and fallback assignment.
Resource hierarchy
Organization resources form a nested hierarchy. Use this order when creating resources and assigning access.
| Layer | Role |
|---|---|
| Project | Groups workspaces; project-level configuration, lifecycle policy overrides, and access scope |
| Workspace | Belongs to a project; contains environments; links to IaC state and stack provisioning |
| Environment | Deployment target where workflows run, deployments are approved, and governance rules apply |
| Stack | Infrastructure defined in Git (Terraform, Pulumi, etc.) deployed into an environment |
- Project:
payments-platform - Workspace:
payments-infra(assigned to the project) - Environment:
production(owners assigned, self-approval disabled) - Stack: Terraform stack deployed into
production
Organization Resources
An organization consists of the following core resources.
Group related workspaces and manage project-level configuration and access.
Features
- Group related workspaces
- Mark projects as sensitive
- Archive projects when eligible
- Override organization environment lifecycle policies
In the UI: Organization → Projects
Key concepts
Projects, workspaces, and environments can be marked Sensitive for production-critical or compliance-bound resources.
- Sensitive resources cannot be deleted
- Sensitive resources cannot be archived
- Destroy deployments for stacks linked to sensitive environments are blocked
Archive projects, workspaces, or environments when they are no longer active. Archiving is a reversible soft deactivation.
- Archived resources are retained for reference and can be unarchived
- Sensitive resources cannot be archived
- System and Git-managed resources have limited archive/delete options in the UI
- Delete is permanent: projects must have no workspaces; workspaces must have no environments
Each environment controls whether the user who triggered a workflow may also approve it.
- Self-approval allowed — the initiator may approve when they are an owner
- Skip self-approval — the initiator cannot approve; another owner must approve
- Production environments typically disable self-approval
Access, roles, and permissions
Who can create and manage organization resources depends on organization membership role and optional scoped assignments via Administration → Roles & Access.
| Role | Create projects / workspaces | Delete projects | Manage org settings & members |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Admin | Yes | Yes | Limited |
| Member | Yes* | No | No |
| Viewer | No | No | No |
| Unassigned | No | No | No |
*Members with project-, workspace-, or environment-scoped access only cannot create new projects.
Scoped assignments can apply at organization, business unit, project, workspace, or environment level.
Organization settings and business units
Organization settings
Organization → Settings covers tenant-wide governance, including environment lifecycle policies (default TTL, max TTL, active environment limits), MFA, and other organization-level configuration. Project detail pages can override lifecycle defaults when permitted.
Business units (enterprise)
Organization → Business Units provides hierarchy and delegated administration for multi-team tenants. Business units complement Project → Workspace → Environment for access and delegation—they do not replace that resource hierarchy.
When a workspace is unassigned from a project, it moves to the system Default Project along with its environments.
Ways to Create Resources
Choose the workflow that best matches your team's development process.
Create and manage Projects, Workspaces, and Environments directly from the Axio web interface.
Best for: quick setup, exploration, and one-off changes without a Git workflow.
- Create Projects, Workspaces, and Environments
- Manage resource hierarchy and assignments
- Configure owners, sensitivity, archiving, and lifecycle options
Getting started:
- Sign in with your Organization ID and credentials
- Create a Project under Organization → Projects
- Create a Workspace and assign it to the project
- Create an Environment, assign owners, and set self-approval
Define Projects, Workspaces, and Environments using YAML or JSON files stored in Git. Git is the source of truth; Axio reconciles desired state with the live platform.
Best for: GitOps, pull-request review, audit trails, and CI/CD-driven provisioning.
- Define organization resources as code
- Track changes with Git
- Automate resource configuration
- Manage resources consistently at scale
Important: Platform as Code manages the Axio platform (projects, environments, policies, runners, etc.). It is not the same as axio.yaml stack blueprint files in IaC repositories, which describe stack provisioning.
Example manifest:
apiVersion: platform.axio.io/v1
kind: Project
metadata:
name: payments-platform
spec:
displayName: Payments Platform
description: Core payments infrastructureWorkflow: validate → plan → apply / reconcile → monitor drift