Workspace

Workspaces connect your managed infrastructure resources to a real Git repository that stores the generated Infrastructure-as-Code for each resource. While Templates define the abstract structure and Resources represent concrete instances, Workspaces are the Git-backed execution surface where resource code is synchronized, reviewed, and promoted through pull requests.

A workspace represents a single repository on a supported Git provider (GitHub, Bitbucket, Azure DevOps). The repository itself must be created manually beforehand in the provider and then registered inside InfraKitchen. InfraKitchen never creates repositories; it consumes them.

Core Concepts

Think of a Workspace as the stable home and audit boundary for all code generated from Resources belonging to a given integration scope. When a Resource is provisioned or updated, InfraKitchen syncs (or deletes) the corresponding code folder into the workspace repository under a deterministic path based on the template and resource name.

Workspace automation handles:

• Cloning and branching
• Copying generated resource code (e.g. OpenTofu/Terraform modules and support files)
• Creating pull requests for new or updated resources
• Merging (approve) or closing (reject) those pull requests
• Deleting resource code when the resource is destroyed

Every change is evented and audit-logged.

Workspace Properties

Folder Layout for Synced Code

When a resource is synchronized into a workspace repository its code is placed at:

<repo_root>/<template_key>/<resource_name_slug>/

Where:

• template_key is the template’s unique key
• resource_name_slug is the lowercased resource name with spaces replaced by underscores

Example:

aws_vpc/prod_network_vpc/
kubernetes_namespace/analytics_namespace/

Lifecycle & Actions

Workspace status transitions revolve around task execution:

• Set to in_progress at start of a sync/approve/reject/destroy pipeline
• Set to done on completion
• Set to error on failure or retry exhaustion

Branch Naming Convention

Branches created for resource operations follow:

The suffix derives from the slugified resource name.

Pull Request Flow

For each resource provision/update/destroy that targets a workspace, InfraKitchen:

1. Clones the repository (SSH or HTTPS depending on integration type)
2. Creates a new branch from the default branch
3. Copies or deletes the resource code path
4. Commits with a structured message including the initiating user
5. Pushes the branch (force if necessary to ensure latest state)
6. Creates a PR, skipping if one already exists for the head branch
7. Waits for a manual action: Approve (merge PR into default branch) or Reject (close PR without merge)

Creating a Workspace

You must first create a repository in your Git provider (GitHub, Bitbucket, Azure DevOps). Then register that repository in InfraKitchen.

InfraKitchen normalizes provider-specific metadata into a unified configuration.

Updating a Workspace

Only description and labels can be modified. Name, provider, integration, and configuration internals are immutable. Updates emit an audit log and event.

Deleting a Workspace

A workspace can be deleted only if it has no dependent resources.

Constraints:

• No resources referencing the workspace
• No implicit locks or pending tasks

Attempting deletion with dependencies raises an error.

Permissions

Permissions leverage the platform RBAC and entity-level access checks.

Integration with Templates & Resources

• Templates define structural hierarchy and naming; workspace code layout nests resource folders under their template key.
• Resources trigger workspace sync tasks on create/update/destroy.
• The workspace never stores execution state; it stores generated IaC code for review and promotion.
• Pull requests provide a human approval gate before code lands in the default branch, enabling policy checks or external CI.

Cross-links:

• Templates
• Resources

Troubleshooting