Workspaces

Workspaces are where you do the work. Each workspace is a project environment with its own files, documentation, agent context, and configuration.

Think of a workspace as the equivalent of a code repository. It should have a clear scope and its own lifecycle. A workspace might contain a landing zone, core networking infrastructure, an application's infrastructure, or a reusable module that embeds your company's security requirements. Whatever you'd put into its own repo with its own versioning is a good candidate for a workspace.

Creating a workspace

From your enterprise dashboard or the Workspaces tab, click New Workspace and give it a name and optional description. Then choose how to get started.

Start from scratch for new projects or when you're bringing existing cloud infrastructure under infrastructure as code management for the first time.

Connect a repository when you already have infrastructure code and want the agent to audit, review, or extend it. Infracodebase supports GitHub, GitLab, Bitbucket, and Azure DevOps. The provider connection must be configured for your enterprise first. See Version Control for workspace setup.

Start from a template when your enterprise has published a template that matches what you're building. Templates are curated starting points your team has already put together. Pick one from the From template chip in the create flow and the new workspace opens with the template's files, rulesets, and configuration already in place, so you can focus on the changes specific to your project instead of setting up the same scaffolding every time. See Templates for how templates work in the enterprise.

What's in a workspace

Organizing with groups

You can create workspace groups to organize your workspaces. Groups help you keep things tidy as the number of workspaces in your enterprise grows. They also show up in your usage data, which makes it easier to track consumption and handle chargebacks within your organization.

How you group is up to you. Some teams group by cloud provider, others by charge code, team, or functional area. You might also group by the type of work, like separating reusable modules from application infrastructure and landing zones.

Visibility

• Private means only members who have been explicitly added to the workspace can access it
• Internal means any member of your enterprise can view the workspace, even if they haven't been added to it directly. This is useful for workspaces that should be visible across your organization without granting everyone explicit membership.
• Public means anyone with the URL can view files and the workspace overview. Only members can edit or use the agent.

How visibility is set depends on how you started. A repository-backed workspace follows the visibility reported by its provider. If you started from scratch, you choose the workspace visibility yourself. See Version Control for repository-backed workspace behavior.