Frontage

Developers

Frontage edits real Next.js code. Nothing about your site is stored in a format only Frontage can read: the repository is the source of truth.

Importing a repository

Frontage edits Next.js 15 or 16 apps that use the App Router and Tailwind CSS 4. Other projects can be imported, but open read-only.

  1. Connect GitHub. On the New site screen, press Connect GitHub. GitHub asks which account and which repositories the Frontage app may reach. Frontage then checks with your own GitHub sign-in that the installation is yours before it lists anything.
  2. Read the report. Pick a repository and press Check what can be edited. Frontage reads it in a throwaway workspace and shows how many pages and components are editable, what is not and why, which files break a code rule, and whether it builds as a static site. Nothing is kept afterwards, and nothing is written to your repository.
  3. Import it. Press Import this repo. Frontage pushes a branch named frontage/draft-<date> to your repository and works there. Every saved version of your edits is pushed to that branch.

The draft branch and the pull request

Frontage never pushes to your default branch and never force-pushes. When you publish, it squashes the draft's edits into one commit on a new branch, frontage/publish-<7 characters of the commit>, and opens a pull request into your default branch. The title comes from the edits; the description summarises them, lists the changed files and links the preview when there is one. Your team reviews and merges it on GitHub as usual.

The squashed commit sits on the point where the draft last took your default branch, so the pull request never undoes work merged since.

When your default branch gets new commits, the site's page says so. Update from main merges them into the draft as one commit. If both changed the same lines, nothing is merged and the page lists the files; you can open a pull request anyway and resolve them on GitHub.

Hosting an imported site

If the repository builds as a static site (output: "export" in next.config, or a build that succeeds when Frontage asks for one), previews and going live on Frontage work alongside the pull request. If it does not, publishing opens the pull request only, and your own hosting deploys it when it merges.

Sites made in Frontage

A site made from a template or a description lives in a private repository that Frontage keeps on GitHub, with drafts on a frontage/draft-<date> branch and each go-live saved as one commit on main.

The CLI

The web app runs the same engine and editor as the Frontage CLI, which developers can use on their own machines. The CLI is not on npm yet; during the beta it runs from a checkout of the Frontage repository:

pnpm frontage start                 # make a site: a template, a description or a repo, then open the editor
pnpm frontage dev <site>            # the visual editor on your machine
pnpm frontage check <repo> --report # the editability report
pnpm frontage lint <repo>           # the dialect rules; exits 1 on errors
pnpm frontage login you@company.com # sign in to Frontage cloud
pnpm frontage cloud link <site>     # link a local site to your organization

The dialect

The shape of code Frontage can edit is written down as a specification, with the rules the linter checks: spec/dialect-v0.1.md in the Frontage repository.