Use the Terraform code editor

The Terraform code editor is the workspace for reviewing infrastructure source and its evidence. It combines a file browser, editor, saved revisions, diagnostics, policy results, plan information, and a constrained product terminal.

You can use this page without writing Terraform. A beginner’s first goal is to understand where the files came from, review their structure, and run safe checks—not to deploy them.

Typical time

15–20 minutes

You need

A linked workspace

End result

Saved, reviewed files

Caution

Saving files, formatting, validation, policy checks, and Terraform planning do not authorize an apply. Never approve or apply changes you do not understand.

Note

File review and revision saving are the required beginner path. Format, Init, Validate, and Run plan are runner-backed actions. Use them only when the controls are visible and enabled and the workspace preflight succeeds. If an action is unavailable, keep the saved revision and record the blocker.

Open the correct code workspace

From Architecture Studio:

1. Confirm the intended project and workspace in the header.
2. Confirm the diagram is saved.
3. Choose Code Editor.
4. Wait for the editor to load the workspace.
5. Reconfirm the workspace name inside the editor.

After project setup, you can also select Open Code Editor in Choose where to continue. ScrinCloud opens the same project and workspace with the code tab selected.

Code 1 of 7 · Open the active workspace in Code EditorShow the Architecture Studio header with the workspace context and Code Editor action.

Choose a safe starting point

Before a Terraform draft exists, the editor can show a local preview with a scaffolded file and the available workspace actions. This preview is not a saved Terraform revision.

• Generate from Architecture Studio returns to the visual design. It does not generate files by itself.
• Import Terraform loads supported local .tf, .tfvars, or JSON files for review.
• Create a file starts an empty Terraform file.
• Open a saved revision reviews or restores an immutable workspace snapshot.
• Use a starter template adds provider and Terraform version files without creating resources.

For this beginner journey, choose Generate from Architecture Studio when the saved canvas is the source of intent. Use Import only for files you are authorized to review and that contain no secrets or Terraform state.

After returning to Architecture Studio:

1. Confirm the intended diagram and workspace.
2. Confirm the diagram is saved.
3. Choose Generate Draft in the canvas header or Terraform area.
4. Review any regeneration warning before continuing.
5. Wait for the generated draft and workspace revision to finish.
6. Choose Code Editor again.

If Generate Draft is missing or blocked, stop and report that exact control. Do not create substitute files merely to bypass the unavailable generation path.

Code 2 of 7 · Understand the first-use local previewShow the first-use local preview with the file browser, scaffolded Terraform file, and the prompt to generate a draft.

Code 3 of 7 · Generate the Terraform draft on the canvasShow the saved Architecture Studio context and the Generate Draft action before returning to Code Editor.

Understand the editor layout

The expanded editor contains several coordinated areas:

• File browser: folders and files in the active workspace.
• Editor tabs: files currently open for review.
• Code editor: the selected file with line numbers and syntax highlighting.
• Problems or diagnostics: formatting, syntax, validation, and other findings.
• Terminal or run output: constrained workspace commands and their status.
• Governance and plan views: policy, cost, plan, health, and deployment evidence when available.

Select a file in the browser to open it. Common starter files describe required Terraform versions, providers, variables, and generated resources.

Code 4 of 7 · Learn the file, editor, and evidence areasShow the file browser, one open Terraform file, editor tabs, line numbers, and the Problems or Terminal area.

Review files before editing

For each file:

1. Read the file name.
2. Identify whether it contains versions, provider configuration, variables, resources, outputs, or supporting metadata.
3. Look for unexpected provider, region, account, backend, or resource changes.
4. Check the Problems area for diagnostics.
5. Compare generated resources with the saved canvas.
6. Ask a Terraform reviewer before changing code you do not understand.

Never add these values

• cloud access keys or secret keys;
• passwords or private keys;
• session, OAuth, or API tokens;
• Terraform state or plan binary data;
• customer secrets or production records; or
• unreviewed provider backend credentials.

Use approved variables and secret references instead of literal secrets.

Make a small, reviewable edit

Skip this section if you are not authorized to edit Terraform.

1. Select the intended .tf file.
2. Make one small change, such as improving a safe description or an approved tag.
3. Check the tab or file indicator for an unsaved change.
4. Open File and choose Save, or use Ctrl+S.
5. Use Save All only after reviewing every changed file.
6. Wait for the save action to finish.

If the workspace is read-only or locked, do not copy files elsewhere to bypass the control. Ask the workspace owner to resolve the access or lock state.

Code 5 of 7 · Review one small change before savingShow one open Terraform file, its modified indicator, the File menu, and Save or Save All.

Save a workspace revision

A saved workspace revision records a durable version that can be reviewed, compared, and restored.

1. Save the current file or all intended files.
2. Confirm no unexpected files remain dirty.
3. Open revision history when you need to compare with an earlier version.
4. Review changed-file and diff information before restoring or replacing content.
5. Keep the current workspace context visible during review.

Saving is not a Terraform apply. It changes the workspace source revision, not the cloud environment.

Run safe checks

Run checks in this order:

1. Format to normalize supported Terraform formatting.
2. Init to perform the product’s bounded static initialization.
3. Validate to check Terraform structure and configuration.
4. Run plan only when the workspace, provider connection, permissions, and approval path are correct.
5. Review policy and governance evidence produced for the plan when it is available.

There is no separate Policy check action in the editor toolbar. Policy evidence belongs to the governed plan and review flow.

The product terminal accepts a bounded command set and blocks arbitrary shell execution and apply commands. Use the product actions or autocomplete rather than pasting shell commands from an untrusted source.

Code 6 of 7 · Run the available governed checksShow the Format, Init, Validate, and Run plan controls with truthful safe status output.

Review a plan without applying

This section is environment-dependent. Continue only when Run plan is visible and enabled and its preflight confirms the required connection and permissions.

Create or open a plan only after confirming:

• organization, project, workspace, and environment;
• provider connection, account or subscription, and region;
• saved Terraform revision;
• active policy settings;
• reviewer and approval requirements; and
• expected cost context.

Then review:

1. resources to create;
2. in-place updates;
3. replacements;
4. deletions;
5. provider or backend changes;
6. security and public-access changes;
7. cost changes; and
8. policy findings or required exceptions.

If source code changes after approval, create and review a new plan. Approval for one revision does not carry to another.

Code 7 of 7 · Review plan impact and governance evidenceShow the plan review area with no plan yet because the local workspace has no linked cloud account.

Keep canvas and code aligned

If code changes should update the visual design:

1. use the code-to-canvas preview action;
2. review every proposed create, update, or delete;
3. resolve warnings and unsupported resources;
4. apply the preview to the canvas only when it matches your intent;
5. save the diagram; and
6. run Architecture Validation again.

Code-to-canvas sync is a reviewed preview flow. It should not silently mutate the saved canvas.

Check your result

The beginner journey is complete when:

• the editor is attached to the intended workspace;
• the file source is understood;
• files contain no secrets or state;
• the intended revision is saved;
• any available formatting and validation actions have completed;
• policy findings are understood when governance evidence is available;
• any available plan has been reviewed without assuming approval; and
• no apply or deployment was started.

Common blockers

Code Editor is disabled

The active project does not have a linked Terraform workspace. Return to Set up a workspace.

The workspace is empty

Choose one of the first-use actions. For this journey, return to the saved canvas and use Generate from Architecture Studio.

Save is disabled

The file may be unchanged, the workspace may be read-only or locked, or another save may be running. Read the visible status before retrying.

Plan is unavailable

The workspace may need a saved revision, valid files, provider connection, permissions, or policy prerequisites. Do not add broad credentials to bypass the preflight. If Run plan is absent in the deployed editor, record the availability blocker and stop; do not run Terraform from another surface as a substitute.

Validation passes but policy fails

Terraform validity and policy compliance are different checks. Read the policy finding, fix the configuration when practical, or use the configured exception and review path.

Where to go next

• Learn the complete Terraform workflow.
• Use the Terraform plan review checklist.
• Learn how policies and approvals govern delivery.
• Return to Start with ScrinCloud to verify the completion checklist.