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.

Start from a template to build on something that already exists. Any public workspace is automatically available as a template that others can fork. If someone has already built something relevant to what you need, forking their workspace is a fast way to get going. Browse available templates in the Templates gallery.

Connect to GitHub when you already have existing infrastructure code and want to use the agent to audit, review, or extend what you've already built. The repository's files are pulled into the workspace automatically. This requires a GitHub organization or personal account to be connected to your enterprise first. If you haven't done that yet, see Integrations to set it up. See Git for details on how workspaces work with GitHub.

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. If you connected to a GitHub repository, the workspace adopts the visibility of the repository and GitHub manages it from that point. If you started from scratch, you choose the visibility yourself. When you later connect to GitHub, your chosen visibility becomes the default for the repository and GitHub takes over from there. See Git for more on how visibility works with GitHub.