Deployment Automation

Turn the manual release checklist — syncing feature flags, env vars, and component versions across environments — into a reviewable, one-click pipeline. The model is inspired by AWS CodePipeline, and nothing is hardwired to one team's setup.

A deployment pipeline has three parts: a Source (where releases are described), ordered Stages, and the Actions inside each stage that do the work. WorkspaceGPT reads the source, computes a diff, and only writes after you approve it.

Quickstart

Get a working pipeline in a few minutes by starting from a preset.

Sources

The source answers “what are we releasing today, and what config does it want?”

Confluence roster

A wiki page with a table mapping each date to a release version (plus optional environment and pilot columns), and a per-release configuration table. WorkspaceGPT auto-detects the columns by their headers; if your headers are non-standard, open Column mapping (auto-detected) and pick them from dropdowns populated by reading the page.

JSON file (Git repo)

For teams that keep release info in version control instead of a wiki. Point the source at a repo, branch, and path; WorkspaceGPT reads it with the GitHub PAT. Expected shape:

{
  "releases": [
    {
      "date": "2026-06-26",
      "version": "1.2.3",
      "environment": "stage",
      "pilot": "Jane Doe",
      "config": [
        { "key": "FEATURE_NEW_CHECKOUT", "value": "true", "target": "vercel" },
        { "key": "API_URL", "values": { "stage": "...", "prod": "..." }, "target": "mach" }
      ]
    }
  ]
}

Use value for one value, or values to set per-environment values. target routes each var to an action (vercel or mach).

Manual / None

Manual — you enter the version and environment at run time. None — there's no config source; the desired state comes from the actions themselves (e.g. promoting component versions between environments). Jira source — coming soon

Actions

Each action is one deploy step, run by a provider. Add them to a stage and configure with dropdowns.

Backend env vars land on the sync PR

The Vercel action diffs against live state and writes immediately. The backend is different: component versions and env vars live in a Git repo behind branch protection, so the GitHub — workflow dispatch action opens a sync pull request first. The Repo — file patch action then diffs your release's backend env vars against main.yml on that PR — not the repo's default branch — and commits any add/update back to the same PR branch as one idempotent commit. A single PR ends up carrying both the component-version bumps and the env-var reconciliation.

Reserved for future releases (the seams exist already): blue-green switch, canary, health verify, and rollback.

Connections & permissions

The Settings page shows only the connections your pipeline actually needs.

GitHub (Personal Access Token)

Vercel

Connect via one-click OAuth. In the Vercel action you then pick the project from a dropdown and map each environment (e.g. stage → Preview, prod → Production).

Confluence

Reused from the Confluence integration. Needed only when your source is a Confluence roster.

The Releases workflow

Open the Releases panel (rocket icon in the title bar) to run a pipeline.

Environments & promotion policy

Declare your environments and the policy for each.

By default, promotions never auto-merge — the safest behavior. In the Environments section you can add an environment by name and opt it into auto-merge individually. Each stage also has a gate (manual by default), so a release pauses for approval between stages.

AI-assisted page reading

Optional resilience for when a wiki page's structure changes.

A renamed column or reordered table can break a strict parser. Toggle AI-assisted page reading on the Confluence source, and if the normal parse fails, WorkspaceGPT uses your configured chat model (Settings → Model) to read the page.

Security model

Write access is treated with care.

• Write-scoped credentials (GitHub PAT, Vercel token) live only in VS Code's encrypted secret storage.
• They are never written to plaintext settings and never logged.
• They are excluded from the Chrome share bundle — sharing your setup never shares your write creds.
• Nothing is applied without an explicit in-app approval; backend changes go through a pull request under branch protection.
• The apply re-computes the plan server-side and blocks on unresolved conflicts — the client's diff is never trusted.

Troubleshooting

Issues specific to deployment automation.

FAQ

Quick answers to common questions.