Keep your site's code in GitHub

GitHub sync keeps your site's own code in a GitHub repository, in step both ways. Every version that goes live becomes a commit there, and a push to the connected branch is checked, built and published on your site.

5 minute readChecked against the studio on 8 October 2026

What goes to GitHub

Only your site's own files: the ones the File Explorer shows and its download holds. The shared parts every Briks site runs on, the site's settings, your keys and your database's records never go there. So the repository doesn't build or run on its own: Briks builds and publishes what you push.

FolderWhat's in it
app/The site's pages.
components/custom/The sections written for your site.
content/The site's words and facts.
api/The site's own server code, if it has any.
db/schema.ts and db/data/The shape of the site's data and the records it starts with.
public/The site's own pictures and files.

If the repository has no README, Briks adds one that explains these folders and how syncing works.

Connect a repository

  1. Press Connect GitHub

    Where: Settings, GitHub

    GitHub opens. If the Briks app isn't on your GitHub account or organisation yet, GitHub asks where to install it and which repositories it may use, then sends you back.

  2. Choose the repository and branch

    Where: Settings, GitHub

    Pick the account, then the repository. The branch starts as the repository's default; name another if you like, and one that doesn't exist yet is made from the default branch. Create a repository on GitHub opens GitHub to make a private one named after your site. Repository not listed? Give Briks access to it opens the app's settings on GitHub.

  3. Press Connect

    Where: Settings, GitHub

    An empty branch is connected at once. If the branch already has files, Briks first shows how many, which of them are in your site's folders and what its first commit does to them. Press Connect and commit this site to go ahead, or Choose another.

Within a couple of minutes, the first commit brings your live version. It replaces the files in your site's folders with the site's own and removes the ones the site doesn't have. Everything else in the repository stays as it is. Nothing is lost from its history, because Briks never force-pushes.

From Briks to GitHub

  • Each version that goes live and changes your site's files becomes one commit on the branch, however it was made: a build, a change, a save in the File Explorer or the Visual Editor, or a restore. While an A/B test runs, its versions wait for it to end.
  • The commit's message is the summary you read in the studio, with the version's number and the name of whoever asked for it.
  • GitHub shows each commit's status, such as Live as version 15.
  • If a file holds something shaped like a key or names one of Briks's own services, nothing is sent, and you're told which file. Keys belong in Secrets.

From GitHub to Briks

A push to the connected branch is published on your site, with no AI and no credits. First it passes the same safety check as a save in the File Explorer: a script, frame or form that would reach another website is refused unless you've added that website under Settings, Preferences, Allowed websites. Then Briks builds it, and within a minute or two the commit's status says Live as version 16, or why it wasn't published.

What a push changesWhat happens
Files in app/, components/custom/, content/, api/, db/schema.ts, db/data/ or public/Published on the site.
A README, a licence and other files at the repository's root, and .github/Kept on GitHub. They are never part of the site.
db/migrations/Refused. Briks writes the data's changes from db/schema.ts, so change the schema instead.
Pictures and other files that aren't textRefused. Add them through the Media library. Deleting one is fine.
Anything else, such as configuration files, .env files or a file shaped like a keyRefused, with the reason on the commit. Nothing of the push is published.
  • A push can change up to 300 files, up to 256 KB each and 8 MB in all.
  • Up to 20 pushes an hour and 100 a day are published for each site. A push over the limit waits, and its status on GitHub says when it will be published. Pushes that arrive while one waits are published together.
  • While an A/B test runs, a push waits for it to end.

When both sides changed the same file

A push that arrives while Briks is publishing waits its turn. If the push and Briks changed different files, both are kept. If they changed the same file differently, nothing of the push is published: Briks puts its own version on a branch called briks-sync, and the push's status names the file. Merge briks-sync on GitHub and push again, or settle it in Settings, GitHub:

  • Use GitHub's version publishes the whole push, the file both sides changed included.
  • Keep Briks's version publishes the push without the files both sides changed.

If the branch's history is rewritten, for example by a force-push, syncing pauses until you choose one of the same two buttons.

What you're told

Syncs that work are quiet, apart from the message that a push is live. A push that wasn't published, a push waiting for a merge and a connection that stopped show in the bell, and in Telegram and Discord chats that have the Builds finished or failed alert on. Settings, GitHub shows the last 20 syncs both ways, each with its commit, its files and its result.

Disconnect

  • Disconnect in Settings, GitHub stops both directions. The repository and its history stay exactly as they are.
  • Moving the project to another workspace disconnects it.
  • If the app is uninstalled on GitHub, or the repository is taken out of its access, syncing stops and you're told.
  • Deleting the project never touches the repository.
Can I start a project from a repository I already have?

Not yet. Importing an existing repository isn't available. Build the site in Briks, then connect a repository to it.

Can I run the repository on my own computer?

No. It holds your site's own files, not the shared parts every Briks site runs on, so it doesn't build on its own. Push your changes, and Briks builds and publishes them.

What can Briks do on my GitHub account?

Only what the app asks for when you install it: read and write the files of the repositories you give it, and set the status of commits. It writes only to the branch you connected and, when both sides changed a file, to a briks-sync branch.

Does Briks read my commit messages?

No. The sync log shows each push's commit, its files and who pushed it, never the message.