Insites Studio®Docs

Command Palette

Search for a command to run...

Publish a project

Push a draft to production.

Publishing in Studio is two actions chained: Deploy to a Dev or Staging instance, then Promote up to Prod. This guide covers the full path.

Pre-flight#

Before you publish:

  • Hit Deploy to Dev at least once. The first deploy is the one that's most likely to surface plumbing issues (GitHub auth, CloudShell config, missing env vars). Catch them in Dev where it's cheap.
  • All accepted patches should reflect the change you want. Open the file tree and spot-check a few files. Originals are preserved, so if something looks off, you can roll back via the per-instance Deploy history menu.
  • The preview pane should match expectations. Toggle to Preview mode and walk the affected pages.

Deploy to Dev#

  1. Hit Deploy

    The Deploy button is in the editor's top bar. With a Dev instance selected as the target, it commits the dirty files to your connected GitHub repo, then triggers a CloudShell deploy.

  2. Watch the panel

    The deploy panel streams two things in sequence:

    • GitHub commit (with a link to the commit).
    • CloudShell deploy job status.

    Both must report success for the deploy to count as complete. Errors surface inline with enough context to retry or escalate.

  3. Verify in preview

    Switch the centre pane to Preview. Walk the changed pages. Click through the flows you touched. Use the live instance URL (in the project home's instance row) to validate against an unframed view if you need to.

Promote to Staging#

  1. Open the project home

    Click the project name in the top bar, or navigate to /p/<id>.

  2. Promote

    Open the per-instance action menu on Dev → Promote to next instance. Studio copies the deploy artefact to Staging without rebuilding. Staging's status walks idle → deploying → active while you watch.

  3. QA on Staging

    Same drill as Dev: walk pages, run flows. This is where stakeholders typically check off the change before Prod.

Promote to Prod#

Same pattern as Staging → Prod. Open Staging's action menu, Promote to next instance.

For projects with UAT, the chain becomes Dev → Staging → UAT → Prod. The promote action always targets the next environment in the configured order.

Rollback#

If a Prod deploy goes bad:

  1. Open the deploy history

    Project home → Prod row's action menu → Deploy history. The dropdown lists every prior deploy with commit, message, and timestamp.

  2. Roll back

    Pick a known-good prior deploy → Rollback. Studio redeploys that revision; the instance status walks deploying → active again. The previous (broken) deploy stays in history for forensics.

Rollback is a real deploy — it commits, builds, and ships. It's not instantaneous, but it's safe.

What gets deployed#

Deploy ships the dirty files in your in-browser session — files you've edited (directly or via accepted AI patches) since the last deploy. Files you haven't touched are skipped.

If you want to ship a "rebuild from scratch" deploy, the simplest path is to make a no-op edit to a key file (or use the AI to do it), so every relevant file is included.

Common questions#

Can I deploy to multiple instances at once? No. Each Deploy targets one instance. Use Promote between environments rather than parallel deploys.

What if Deploy fails halfway through? The GitHub commit is atomic — either it lands or it doesn't. If CloudShell fails after the commit lands, the previous deploy is still live and you can re-run the deploy from the same commit.

Is there an automated CI/CD path? Today, Deploy is manual. Webhook integrations on the project's Integrations tab can be wired up to surface deploy events to Slack and other systems, but the deploy itself is human-initiated.