The Studio

What It Is

The Studio is where a custom app is built in the browser:

• the chat with an AI agent that builds apps;
• the app's files and an editor that knows TypeScript and React;
• a live preview of the app;
• the app's problems and its log.

Everything in the Studio works on the app's draft: the one working copy that everyone who works on the app shares. That covers the Studio, the app's page, AI agents over MCP and the CLI (jetstack draft). Nothing in the draft is live until it is published as a release and deployed.

Why It Matters

• One place to build an app end to end. You ask for a change, watch the files change and the preview follow, fix what the problems show (or ask the agent to), and publish.
• Nothing to install. A Studio app — React, TypeScript, Tailwind CSS and ready-made components — is built in your browser. No Node, no build server.
• Safe by default. Changes go into the draft. Publishing makes a release; deploying it goes through the app's usual review, approvals and history.

Opening It

• From an app: Apps → the app → Studio.
• A new app: Apps → Create app, then choose what it starts from:
  • React (Studio) — a Studio app from the React template. Best with the app builder agent.
  • Plain — HTML, JavaScript and handlers, served as written, without a build step.
  • Empty — no files; deploy a bundle or push one with the CLI. This one opens the app's page, not the Studio.

The Studio is for people with the Deploy apps permission (deployApps).

The Screen

Arranging it.

• The header's toggles show and hide the chat, the files, the code, the preview and the problems; one of the code and the preview always shows. Ctrl+B (⌘B) shows or hides the files, Ctrl+J (⌘J) the problems.
• Drag the edge between two parts to resize them; a double click puts an edge back.
• Focus in the preview's toolbar shows the preview alone, and a second click brings back what was there.
• The Studio remembers the arrangement in this browser, for every app.

Below 1,024 px the Studio shows one panel at a time: Chat, Code or Preview.

Working In It

Editing

• Changes are saved about a second after you stop typing, or at once with Ctrl+S (⌘S).
• Each save names the version of the file it replaces, so nothing saved meanwhile is lost:
  • a change someone else saved — the agent, a colleague in the app's classic editor, the CLI — is merged into the file you have open, around what you typed and have not saved yet;
  • only where it changed those same lines does the editor stop saving the file and ask: Compare shows their version beside yours; Keep mine saves yours over theirs; Reload theirs takes theirs.
• Changes made elsewhere to files you have not touched simply appear.
• Upload files from the Files header, or from a folder's menu (right-click). Images and other files a Studio app shows as they are go in static/.

Co-Editing

People who have the same file open in the Studio edit it together, as one shared document.

• Typing. What each of you types appears in the others' editors within a moment, where it was typed. Your cursor and the part of the file you look at stay put.
• Who is there. The status bar under the editor names the others who have the file open ("Editing with Ana, Petr"). Their cursors and selections show in their colours, with their names while they move.
• Saving. One of you saves the file for everyone, so each change is saved once. While you all keep typing, it is saved every few seconds. When that person leaves the file, someone else takes over.
• Undo (Ctrl+Z, ⌘Z) takes back your own edits, not the others'. Alone in the file, it works as usual.
• The agent's changes. When the agent, the CLI or the classic editor saves the open file, its change reaches everyone's editor as an edit, merged around what you are typing. The Studio asks what to keep only where it changed lines someone has not saved yet.
• Leaving. Switching to another file, or closing the Studio, saves what you typed and leaves the file.
• Branches. People co-edit a file when they work on the same branch, or all on the app's draft.
• Without live events (an environment without a live-event server), the Studio asks for the others' edits about twice a second while someone else is in the file, so they arrive a little later.

Building And The Preview

• A Studio app is built after every saved change, and the build is stored in the draft: it is what Open in a new tab, other people's previews and the agent's checks show. Your own preview shows a change at once with fast refresh; without it, it reloads on the same path once the build is stored.
• When the Studio has been idle for a moment, it also makes the production build, the one publishing uses.
• Without an open Studio the platform builds the draft itself when it is published, or checked by an agent, with the same tools.
• An app built on a computer ("build": "local" in studio.json) is not built here: the preview shows the last build jetstack draft build sent, and the header says when the sources changed since.
• A plain app is served as written: the preview reloads after each save.
• The preview is sandboxed. It is a page of its own origin, at its own address, without your session: the draft's code may call the app's routes and make the SDK's data calls as you, and nothing else. It cannot reach the Studio, change the draft, install a service worker or send anything to another site. Its storage and cookies last until it reloads. See Preview.
• Other sites the app needs in the preview (images, an API, a video) go in the manifest's preview.allow. What the preview blocks shows among the problems.
• New types, fields and roles the draft declares exist only after the deploy. On development the Studio offers Apply to development, which puts them there now so the draft's routes can use them (see The draft's data model).
• On development, routes that save records as the app ($jetstack->asApp()) work in the preview before the first deploy. The draft acts as the app's draft identity, with the capabilities it declares (see Building Apps With Code).

Fast Refresh

The preview of a Studio app shows each saved change within a few hundredths of a second, without reloading the page.

• What it is: the Studio runs the draft's sources in the preview straight from your browser — each file transformed on its own, the app kit's packages bundled once — so nothing has to be built and stored first. React Refresh swaps the components that changed.
• Why it matters: the page keeps where you were — a counter's count, what a form holds, an open dialog, the route — while you change how it looks and works.

• An error the app does not catch shows over the page too (close it with ×), and among the problems at its line.
• Reload starts the page again from the current sources.
• The stored build follows a moment after you stop changing files.
• Without fast refresh the preview reloads after each build: an app on kit 2026.10 (set kit in studio.json to 2026.11 to use it), an app built on a computer, and plain apps.

Inspect

Inspect (the arrow in the preview's toolbar) changes an element from the preview:

1. Point at the page: the element under the pointer is outlined.
2. Click it. Instead of acting, the click opens its source in the editor, at the line where it is written, with the inspector beside the preview:
   • Text, when the element's only child is plain text in the source;
   • Classes, when its className is a plain string, or not set yet;
   • otherwise a note that they are made in code, to change in the editor.
3. Apply writes the change into the file, which is saved and built as typing is; the preview shows it. Ask the agent puts the element, and where it is written, into the chat.

Escape in the preview ends Inspect. It works for apps the Studio builds: their preview's elements say where they are written. A component used in the source (a Button) is found where it is used, when it passes its props on to its element, as the template's components do.

Problems

Click a problem's place to open it. Fix with AI sends the list to the agent. Type errors do not block publishing; the agent sees the same problems with its app_check.

The Agent

• The chat uses a builder agent the person can see, whose user has Use MCP server, Use the MCP builder and Deploy apps. The App builder template sets one up.
• The agent works on this app's draft only, within both its user's and your permissions. With every message it knows the open file, your selection and the preview's path.
• It reads, edits and checks files, reads the log and calls the app's routes. You see each file it writes as it writes it, and the editor follows.
• It never publishes unless you ask.
• On a production it changes the draft's files freely and asks you before anything else: configuration, publishing and deploying, a route call that writes, data, other systems. You get a card with Run and Don't run, and for configuration what a check says it would change. See Confirm before apply.
• Server code the agent changed (the handlers or the manifest) runs in your preview on a production only after you look at it. The preview names the files and offers Open the files and Run it. Until then its routes answer 409. Everyone who previews decides for themselves. Code you write on top of what you accepted stays accepted.

Publishing

Publish… checks first:

• the production build (for an app built on a computer: that a build of the current sources was sent);
• the manifest and the handlers;
• type errors;
• whether live moved on since the draft started.

It then shows what deploying would change, and makes a release. Next:

• Review and deploy opens the release's plan, with the app's approvals;
• on development, Promote to production opens the promotion.

The next change starts a new draft from the release.

Branches

A branch is a copy of the app's draft that you change on its own and merge back when it is ready: a redesign, an experiment, or what the agent builds for you to review.

• Switching. The button beside the app's name says where you are: the app's draft, or a branch. Its menu lists the branches (who changed each last, and when), opens one, and starts a New branch…. A branch has an address of its own (…/studio?branch=<name>) to share with colleagues.

• On a branch everything works as on the app's draft, on the branch's own files: the editor, the agent, the preview with fast refresh, problems and builds. A bar under the header names the branch.

• Review and merge… (on a branch, the header's main button) shows what the branch changed, file by file:

  • files that merge, with what changed;
  • conflicts, where the app's draft changed the same lines. Each opens in an editor with both versions between markers: the app's draft's tinted blue, the branch's green. Edit the lines into one and choose Use these lines, or Use the app's draft's or Use the branch's.

  Merge then writes it all into the app's draft as one change, removes the branch, and opens the app's draft. If either changed while you looked, it asks you to look again.

• Bring in the app's draft's changes… merges the other way: what changed in the app's draft comes into the branch, with conflicts resolved the same way. The later merge then holds only the branch's own changes.

• Discard this branch… throws it away.

• Publishing is the app's draft's: merge the branch first.

• When someone else merges or discards the branch you have open, the Studio says so and takes you to the app's draft.

Environments

When live is newer than the release the draft started from, the Studio says so ("Live is v9; this draft started from v7"). It offers Compare (the files that differ, side by side) and Start over from live.

Example

A contact form that saves leads.

1. Apps → Create app "Lead form", start from React (Studio). The Studio opens and builds the starter.
2. Ask the agent: "Add a contact form: name, e-mail, company and a message. Save each one as a lead and thank the person." The agent adds a route and its handler, then the form. You watch the files change and the preview follow, keeping what you typed into the form.
3. A type error shows in Problems; Fix with AI, or fix it yourself.
4. Try the form in the preview. Then Publish…, Review and deploy, and promote to production.

Requirements

• A current desktop browser. Building needs WebAssembly and Web Workers; without them the Studio says so and only edits.
• Builds load the app kit and the build tools once, then from the browser's cache.

Related Chapters

• Custom Apps, Studio apps
• Deploying And Rollbacks
• MCP Builder: the same draft tools, for AI outside the platform
• The jetstack CLI: jetstack draft pulls and pushes the same draft
• AI Agents Builder