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.

Config target routing

A Confluence configuration table names an app/system per row but has no explicit target column, so WorkspaceGPT decides whether each variable syncs to Vercel or mach. By default it uses judgment — a NEXT_PUBLIC_-prefixed or otherwise frontend-looking key routes to Vercel, generic backend config to mach. To pin specific apps, open Config target routing on the Confluence source and add rules mapping an app/system name to a target. Each rule accepts several comma-separated names, matched as a case-insensitive substring; the first matching rule wins, and unmatched rows fall back to Vercel only if the name mentions “vercel”, otherwise mach.

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.

Hotfix flow

Ship an urgent fix by ticket, without a full release.

The hotfix flow is a separate pipeline from the config-sync release — the magenta card at the bottom of the Releases panel. Instead of config variables, its unit of work is tickets → commits → components → tags. It reuses the same plan → approve → apply spine: nothing is written until you approve, and the plan is recomputed server-side on apply.

mms-bff-v1.2.3-hotfix.1

Configuration

The hotfix repository, base branch, and tag template default from your GitHub workflow-dispatch action's repo topology (its release tags are repo-scoped), and can be overridden per install — the default tag template is {component}-v{version}-hotfix.{n}. Authentication reuses the same mach GitHub token (classic PAT, repo scope) — no extra connection.

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

How WorkspaceGPT reads a wiki page whose structure varies per team and release.

Roster and release-page layouts differ too much between orgs for a strict header parser to be reliable, so when a chat model is configured (Settings → Model) WorkspaceGPT reads pages with AI by default — both resolving today's release from the roster and extracting config variables during Prepare config sync. Strict header matching is used only as a fallback when no model is configured.

Two toggles on the Confluence source let you tune this: AI-assisted page reading (roster resolution) and Always use AI for config sync (release-page extraction). When reading the config table, the model also decides each variable's target by judgment — inferring Vercel vs mach from the key's naming and the row's app/system context — and consults your Config target routing rules when it isn't sure.

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.