Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.frontic.com/llms.txt

Use this file to discover all available pages before exploring further.

GitHub integration is optional but unlocks production shipping. Studio works end-to-end without GitHub — scaffold from a framework template, build with the chat, iterate against the live preview, and share via the preview URL or a workspace download. Connect GitHub when you’re ready to push work to a real repo, open pull requests, and run it through your team’s review flow. Once connected, Studio builds on real Git branches in real repositories. File changes the Studio chat makes are committed to a branch on your GitHub repository, and you open a pull request through GitHub’s normal flow. No custom review tool, no “AI commits” marker — ordinary Git that happens to have been authored through a chat interface. This page covers the full GitHub-side flow: connecting your account, committing from the Changes panel, opening a PR, and coordinating PRs with Releases when a change touches both frontend code and stack config.

​
Connecting GitHub

Connecting is a one-time setup per Frontic project. You can start the connection from either of two places:

From Studio Settings

Go to Studio → Settings, open the GitHub section, and click Connect GitHub. Useful when you want to set up GitHub up front, before any job.

From a Create Job dialog

In the Create Job dialog, switch Start from to Repository. Connect GitHub inline if prompted; the dialog returns ready to pick the repo and branch.
Either path opens GitHub’s OAuth page, where you authorize Frontic to act on your behalf. After you authorize, the connection is saved at the project level and every subsequent job can target any repository you’ve authorized.
Studio Settings — GitHub tab showing the project's GitHub Integration with the Connect Account action

​
What Studio does with the connection

When a job runs against a GitHub repository:
  • The workspace clones the repo when the job starts
  • The Studio chat creates a new branch off the base branch you pick
  • Every file edit is a change on that branch
  • Clicking Commit in the Changes panel commits on the branch and pushes to GitHub in one step
  • Pull requests target the base branch
Everything is standard Git. Commits show up in your repo history with your GitHub identity — not a generic bot — because the commit author is the account that authorized the connection.

​
Multi-repository projects

Each Studio job picks its own repository and base branch at creation — there’s no per-project default repository to override. If your team maintains multiple frontends (web storefront, mobile app, admin surface) against the same Frontic project, each can live in its own repo and jobs target whichever one you’re working on.

​
Revoking access

Two ways:
  • From Frontic — Studio → Settings → GitHub → Disconnect. Existing jobs finish; no new jobs can be created against GitHub repositories until you reconnect.
  • From GitHub — in your authorized OAuth apps, find the Frontic authorization and revoke it. GitHub enforces immediately.
Neither deletes already-committed work — that’s in your Git history and belongs to you.

​
Commit

Once the Studio chat has made file changes you’re happy with, commit them from the workspace. The Workspace page covers reviewing the diffs in detail; this section covers the commit mechanics.

Review the diffs

Before committing, open the Changes panel and read every file — not only the ones you expected. Agents sometimes touch imports, shared utilities, or generated files you didn’t mention. Worth knowing what landed.

Write a commit message

In the Changes panel, there’s a commit message input. Write a real message — not “WIP” or “Studio changes”. A concise summary of what changed and why is what your teammates read during review.

Click Commit

Studio commits on the branch and pushes to GitHub in one step. The first commit creates the branch on GitHub; later commits fast-forward it. The Changes panel shows the branch up to date with remote when it’s done.

​
Open a pull request

Once your branch has commits on GitHub, the Changes panel shows a link to open a pull request. Clicking it takes you to GitHub’s compare page with the base and compare branches pre-filled via URL params. From there you write the PR title and description in GitHub’s own form — Studio doesn’t compose PR content itself. Add the context your team needs (ticket links, screenshots, test notes) and create the PR as you normally would.
Take 30 seconds to write a real description: what changed, why it changed, and what to look at first. A good description saves more review time than it takes to write.

​
Merging and cleanup

When the PR is approved and CI is green, merge it like any other PR. After merge:
  • The feature branch can be deleted (your team’s usual branch cleanup applies)
  • The Studio job stays around — you can reopen it later for follow-up work in the same workspace
  • If the change involved stack configuration (new blocks, listings, pages) that went through a preview release, promote the preview if you haven’t already

​
Coordinating with stack releases

A PR is about code. A release is about stack config. When a change involves both — which most meaningful changes do — the order matters:

Preview the stack change first

Create a preview in the admin app so the stack state is frozen.

Generate the Client SDK against the preview

Run frontic generate --env preview (or frontic generate and pick preview from the prompt). The SDK embeds a version token pointing at the preview.

Commit the SDK + frontend code

Commit the generated client files alongside the frontend code that uses them. Push the branch.

Open the PR

Mention in the description that there’s an accompanying preview release and link to it. Reviewers need to know the PR depends on stack state that isn’t public yet.

Deploy the PR to a preview environment

Your deploy pipeline builds a preview deploy. Because the SDK in the branch carries the preview token, the preview deploy talks to the Frontic preview — so QA validates the full stack, not only the code.

Merge the PR

Production deploys the new frontend. Because the SDK carries the preview token, production is now talking to the Frontic preview — so real traffic hits the validated stack state.

Promote the Frontic preview

Promote the preview to public. The preview version becomes the new public; the token your frontend is pinned to falls back to public gracefully — same content, no code change needed.
The preview-then-promote sequence gives you a QA checkpoint where the frontend and stack state are both frozen, so you’re not chasing a moving target. For a worked example, see Your First Feature.
Preview — the next iteration of this flow pairs a draft with the Studio job and the PR, so the stack sandbox, the frontend code, and the release that ships both move together. In preview today; expanding as it matures.

​
Troubleshooting

You might not have access to that repository on GitHub, or your authorization of Frontic was scoped before the repo existed. Confirm your GitHub access, then disconnect and reconnect in Studio Settings so Frontic refreshes its view of your repositories.
Usually means GitHub declined the authorization — either the organization has SSO/SAML restrictions that need an admin to approve the OAuth app, or the flow was cancelled. Ask an org admin to approve Frontic, or try again and complete GitHub’s authorization page fully.
Commits are authored with the email GitHub returns for your account. If you don’t expose a public email on GitHub, Studio falls back to your GitHub noreply address (<id>+<login>@users.noreply.github.com). Commits still show as yours on GitHub, but any tooling that matches a specific email may treat them as unlinked. Set a public email on GitHub if you need commits to link to a specific address.

Release Control

How the stack-side of your changes moves between stages. (Plus plan.)

Studio

Where chat-driven changes happen before they hit the connected repository.