Set up a workspace

A workspace is the working boundary for one environment, account, region, team, or delivery stream. It connects architecture diagrams, Terraform revisions, provider context, policy checks, plans, and history.

Typical time

10–15 minutes

You need

Environment and region

Next step

Configure policies

Decide the workspace boundary

Create separate workspaces when any of these differ:

• development, test, staging, or production environment;
• AWS account or Azure subscription;
• cloud region;
• team ownership;
• source repository or branch;
• approval requirements; or
• deployment schedule.

For a first-time setup, create one non-production workspace. Avoid a single catch-all workspace for unrelated systems.

Prepare your choices

Have these values ready:

Choice	What it means
Workspace name	A recognizable environment and purpose, such as customer-portal-development
Environment	The saved lifecycle boundary used by diagrams and Terraform variables
Provider	AWS or Microsoft Azure
Region	The approved region for this workspace
Cloud account	Optional existing connection for workflows that need provider access
Execution type	Manual workspace or a connected Git repository
Variables	Non-secret values used by the starter Terraform workspace
Tags	Search, ownership, product, or cost labels

Caution

Do not enter passwords, API keys, access keys, private keys, tokens, connection strings, or other secrets as workspace variables. Use the organization’s approved secret-management workflow.

Open Add Workspace

1. Continue from Add Members, or open the project’s setup progress.
2. Select Create Workspaces.
3. Confirm the page title is Add Workspace.
4. Confirm the progress row shows Workspace details, Environment & provider, Repository & execution, and Review.

If the project already contains workspaces, make sure you are creating a new boundary rather than duplicating an existing environment.

Step 1: Workspace details

1. Review the suggested Workspace Name.
2. Change it to a clear environment-and-purpose name if needed.
3. Review the generated, read-only Workspace ID.
4. Add a short Description.
5. Check Workspace readiness for completed details.
6. Choose Continue.

The Workspace ID is derived from the name. Use a stable name because other records and links may refer to the workspace over time.

Workspace 1 of 4 · Screenshot placeholder

Name the workspace boundary

Show Workspace Name, generated Workspace ID, Description, the four-step progress row, and Workspace readiness.

Future capture briefCapture Workspace Details with a synthetic non-production name. Keep the project breadcrumb and readiness panel visible.

Check your result

Workspace readiness shows Workspace details complete, and the generated ID contains letters or numbers.

Step 2: Environment & provider

1. Select the saved Environment for this workspace.
2. Select the Region approved for that environment.
3. Confirm the Cloud provider.
4. Wait for the region catalogue to finish loading.
5. Optionally select a cloud account connection.
6. Choose Continue.

The provider normally starts with the project default. If you change it, verify that the region and any selected cloud connection also belong to the new provider.

About cloud account connections

A connection lets approved workflows interact with a real AWS account or Azure subscription. It is optional for visual design and local file review.

• Select a connection only when you recognize its name, provider, scope, and environment.
• The connection should use the smallest permissions required.
• Do not create or paste provider credentials into this form.
• If no suitable connection is available, continue without one or ask an administrator.

Workspace 2 of 4 · Screenshot placeholder

Choose environment, provider, region, and optional account

Show the saved environment, provider picker, region selector, and cloud-account selector in one consistent state.

Future capture briefCapture Environment & Provider with a synthetic development environment and approved example region. Do not expose account IDs, subscription IDs, role ARNs, or tenant details.

Check your result

Workspace readiness shows Environment and provider complete. The selected environment, provider, and region agree with each other.

Step 3: Repository & execution

Choose how this workspace will manage Terraform source.

Option A: Manual workspace

Use a manual workspace when you want to:

• learn the ScrinCloud workflow;
• generate or import Terraform for review inside the workspace;
• connect Git later; or
• avoid linking a repository during initial setup.

Leave the Git or VCS option disabled. ScrinCloud creates safe starter workspace files without creating cloud resources.

Option B: VCS-driven workspace

VCS means version control system. In this setup, it refers to a Git-backed workflow. Use a VCS-driven workspace only when an approved repository and Git connection already exist.

1. Enable the Git or repository option.
2. Select the connected Git account.
3. Enter the approved repository URL.
4. Enter the branch, usually main unless your team specifies another.
5. Confirm the repository belongs to the expected organization.

Repository and branch become required when VCS execution is enabled.

Variables and tags

1. Review the starter variables such as environment and application name.
2. Add only non-secret values.
3. Remove variables that do not apply.
4. Add search or ownership tags.
5. If Allow custom Terraform resources appears, leave it disabled unless your role and organization policy explicitly allow resources outside the approved canvas catalogue.
6. Choose Continue.

Workspace 3 of 4 · Screenshot placeholder

Choose manual or repository-backed execution

Show the repository controls, execution choice, variables, tags, and any authorized workspace controls.

Future capture briefCapture Repository & Execution in manual mode for the primary beginner screenshot. A later variant may show synthetic repository and branch values with no real connection identifiers.

Check your result

Workspace readiness shows Execution settings complete. If VCS is enabled, the connected Git account, repository, and branch are all present.

Step 4: Review and create

1. Review Workspace summary:
   • Name
   • Workspace ID
   • Environment
   • Provider
   • Region
2. Review Execution review:
   • Manual or repository-backed source
   • Cloud account connection
   • Variables
   • Tags
3. Use the edit actions to correct any mismatch.
4. Confirm no secret or customer data appears.
5. Choose Create Workspace.
6. Wait for the workspace revision and setup status to be saved.

Workspace 4 of 4 · Screenshot placeholder

Review the full workspace before creation

Show Workspace summary, Execution review, readiness, and the Create Workspace action.

Future capture briefCapture Review immediately before creation with synthetic values. Include the execution type, optional connection state, variables, tags, and final action.

Confirm the workspace was created

The step succeeded when:

• the setup progress marks Create Workspaces complete;
• the new workspace name is available to the project;
• no workspace creation error is shown; and
• the setup continues to Policy Guardrails or asks where to continue.

Creation saves a Terraform workspace revision. It does not run Terraform and does not deploy infrastructure.

Common blockers

Region is unavailable

Wait for provider regions to load. Confirm the provider first, then select a region supported by your organization. If the catalogue falls back to bundled regions, verify the final choice with your cloud owner.

A cloud connection is missing

Continue without one when the workflow is visual design or local review. For live discovery, plan, or apply workflows, ask an administrator for a least-privilege connection that matches the provider and environment.

Continue is disabled in Repository & execution

When Git is enabled, connected Git account, repository URL, and branch are required. Disable Git to create a manual workspace, or complete all three repository fields.

Create Workspace is disabled

Read the reason in Workspace readiness. The required groups are:

• valid workspace details;
• environment, provider, and region; and
• complete execution settings.

The workspace already exists

Return to the project and open the existing workspace. Do not create a second workspace with a slightly different spelling to bypass an ownership or state conflict.

Continue

Policies can be saved as a draft earlier, but applying project policy guardrails requires an active workspace. Continue with Configure policy guardrails.