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: installing the Frontic GitHub App, 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

GitHub integration uses a GitHub App installed on your GitHub organization (or personal account). It’s an organization-wide install: a GitHub admin sets it up once, and every teammate on the Frontic project can use Git features in Studio — push, branch, open PRs — with no individual GitHub setup of their own. You can start the install from either of two places:

From Studio Settings

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

From a Create Job dialog

Open Create Job, expand Source configuration, and switch the source to GitHub Repository. Install the GitHub App inline; the dialog returns with repository mode pre-configured, ready to pick the repo and branch.
Either path opens GitHub’s App installation flow, where you pick the organization to install on and choose which repositories the App can access. After you confirm, the installation is saved at the project level and every subsequent job can target any repository you granted access to.
Installing on an organization may require approval from a GitHub org admin if your organization restricts third-party App installs. If you don’t see your org in the picker, ask an admin to install the Frontic GitHub App for you.
Studio Settings — GitHub tab showing the connected GitHub Organization, the Repository Access list with Manage Repositories, and the Uninstall & Disconnect action
Once the App is installed, Create Job uses your connection to pre-fill the source. The dialog opens with Source configuration collapsed — its summary line shows the current selection (a template name when no GitHub is connected, or the repository’s full name when one is). When you’ve used a repository before, that one comes back pre-selected; with a fresh install and a single accessible repo, that repo is picked silently. Multiple accessible repos with no history is the only case that opens with the section expanded so you can choose.
Create Job dialog showing the Name field and an expanded Source configuration section with a Template / GitHub Repository toggle set to GitHub Repository, the chosen repo with a Change action, and a Base Branch dropdown set to main

​
Repository access

After the App is installed, the GitHub section in Studio Settings shows a Repository Access panel listing the repositories Studio can see. The list is paginated — load more if you have many repos. To change which repositories the App can access, click Manage Repositories. That redirects you to the GitHub App’s installation settings on GitHub, where you can add or remove repositories. Save there, and GitHub redirects you back to Studio with the new list. Changes apply immediately for everyone on the project. Use this when:
  • A new repository was created after the App was installed and isn’t in the picker yet
  • You want to scope Studio to a narrower set of repos than what’s currently granted
  • You’re auditing what Studio has access to

​
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 are authored by the GitHub App, not by the teammate who ran the job — so don’t use the commit author field for attribution.

​
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 (granted to the same App installation) and jobs target whichever one you’re working on.

​
Revoking access

Two ways:
  • From Frontic — Studio → Settings → GitHub → Uninstall & Disconnect. This uninstalls the GitHub App from your organization and removes the connection from the Frontic project. Existing jobs finish; no new jobs can be created against GitHub repositories until the App is installed again.
  • From GitHub — in your organization’s Settings → GitHub Apps → Frontic Studio, click Uninstall. GitHub enforces immediately.
Neither deletes already-committed work — that’s in your Git history and belongs to you.

​
Commit

Once Studio 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 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

The repository wasn’t included in the App’s repository access grant. In Studio → Settings → GitHub, click Manage Repositories to open the GitHub App’s installation settings, add the missing repo, and save. The picker refreshes with the new list.
Most often this is an organization permissions issue: the org requires admin approval for third-party App installs, and the request is still pending. Ask a GitHub org admin to approve (or install) the Frontic Studio App for the organization. If you cancelled the install partway through, just click Install GitHub App again.
Once the App is installed on the org, every teammate on the Frontic project gets Git access — no per-user GitHub setup is required. If a teammate is blocked, check that the repository they’re working on is included in the App’s repository access (see Manage Repositories) and that they have the Frontic permissions to use Studio in this project.

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.