05/10/2026 · Git, คู่มือ

Deploy from Git (GitHub / GitLab): let BrewInTH pull your code

Release an app from a Git repository instead of a ZIP: the https link, the branch, a read-only token for private repositories, and the limits to know.

If your code already lives on GitHub or GitLab, zipping it and uploading it after every change is double work, and sooner or later the wrong ZIP goes up.

BrewInTH can pull the code straight from a Git repository, build it and publish it. This guide covers the setup step by step, for public and private repositories, how to make a read-only token, and the limits worth knowing first.

In short
✅ App projects (Node, Python, PHP, Laravel, Go, Java, .NET, Ruby, Bun) can be released from a Git repository instead of a ZIP
✅ https links only: GitHub, GitLab, Bitbucket or any Git host reachable from the internet
✅ A private repository uses a read-only token the owner saves in the console; it is stored encrypted and never shown again
✅ Nothing is published on push: press Build & publish, or tell your AI, whenever you want a release
✅ Every release records the commit it was built from, so you always know which code is live

What releasing from Git means, and how it differs from a ZIP

Normally an app reaches BrewInTH as one source ZIP; the build machine installs the dependencies and produces the new release. Releasing from Git works the same way in every respect but one: the platform clones the code from your repository instead of waiting for a file.

Uploading a ZIP compared with releasing from a Git repository: with a ZIP you pack the files again each time, risk sending an old set and cannot tell which code a release came from; with Git the newest code of the branch is fetched for you, every release records its commit, and private repositories work

It suits:

people whose coding agent writes code and pushes to GitHub as a habit;
teams with several people on one repository;
anyone who wants to know exactly which commit is online.

If you have never used Git and your AI hands the files over directly, carry on as you are. There is no need to switch.

What you need

An app project with its technology chosen. Releasing from Git does not work for static sites, and a project whose technology is "Let the platform decide" must make its first release from an upload, or have its technology picked when the project is created.
The repository's https link, such as https://github.com/myname/myapp. Links like git@github.com:... or ssh:// are not accepted, and no user name or token belongs in the link.
The app's files at the root of the repository: package.json with its lock file, requirements.txt or composer.json, exactly as they would sit at the root of a ZIP.
For a private repository, a read-only token (see below).

Set it up, step by step

Five steps to release from Git: open the Releases tab and choose Git repository, enter the https link and the branch, add a token if the repository is private, press Save repository and Check access, then press Build & publish

1. Open the Releases tab and choose Git repository

Open the project and go to the Releases tab. Under Publish a new release there are two sources, Uploaded .zip and Git repository. Choose the second.

2. Enter the link and the branch

Repository link (https), for example https://github.com/myname/myapp
Branch / tag / commit, for example main. Left blank, the repository's default branch is used.

3. Private repository: add the token

Fill in Token for a private repository only when the repository is private; skip it for a public one. Token user name can stay blank for GitHub, GitLab and Bitbucket.

4. Save and check access

Press Save repository, then Check access (uses the saved token). When all is well you see Reachable with the branch name and the first seven characters of the commit. Otherwise the message says whether the link is wrong, the token lacks permission or the branch was not found.

5. Press Build & publish

Read the Preflight result, then press Build & publish. The code is cloned, built on a separate machine and switched live once the app answers properly. In Release history, a release made from Git carries a label such as main@a1b2c3d: the branch and the commit.

Make a read-only token for a private repository

The rule is least privilege: read the code, nothing else, and only this repository.

GitHub: create a fine-grained personal access token, select only the repository you need, and give it Contents: Read-only.
GitLab: create a deploy token or a project access token with the read_repository scope.
Bitbucket: create a repository access token with read permission on the repository.

Menu names on those sites change over time. If you cannot find one, ask your AI "how do I create a read-only token for a single repository on GitHub?".

What BrewInTH does with the token:

stores it encrypted and never shows it again after saving;
uses it only with the Git host it was saved for; if the repository moves to another host, the token is not sent along;
lets only the owner set or change it, in the console. An AI holding a project token can release from this repository but cannot set or read the repository token;
removes it whenever you press Remove token.

When a token expires, the next release fails. Create a new one and enter it in the same field.

Updating the site after a change

BrewInTH does not publish when you push. A push only stores code; the site changes when you say so. The upside is that half-finished work never slips onto the live site.

Two ways:

Yourself: on the Releases tab choose Git repository and press Build & publish. The newest commit of the saved branch is fetched.
Through your AI: in a coding agent already connected to the project, say:

Push the latest work to the main branch, then release the project on BrewInTH from the saved Git repository
(deployment_plan, then deployment_apply with {"git":{}}).
Wait until the new release is active, open the site to check it works, and tell me which commit was built.

To release only what you mean to, use tags: put v1.2.0 in Branch / tag / commit instead of a branch name.

Limits worth knowing

Four things to know about releasing from Git: only the chosen branch or tag is cloned, without submodules or Git LFS; .env files stay out of the repository and go into the app settings; nothing is published on push; and static sites cannot use it

No submodules, no Git LFS. The clone is shallow and covers only the chosen branch or tag. If the project uses submodules, bring that code into the repository or go back to a ZIP.
No symlinks, and the source has the same size limits as a ZIP.
Secrets stay out of the repository. Do not commit a .env with real values; set them on the project's App settings tab.
Static sites still need uploaded files. For a React or Vue site that needs a build, create the project as Node and the platform builds it.
A project bound to Git is not offered on the Upload and go live page, so a ZIP cannot overwrite work that comes from the repository.

Watch the video

▶ From creating a project to a live site (1:30, in Thai)
Watch on YouTube

FAQ

Does the site update when I push?

No. Press Build & publish, or have your AI release it, each time.

Can I use an SSH link (git@github.com)?

No. Only links starting with https:// are supported. On the repository page of GitHub or GitLab, copy the HTTPS link.

Can the app live in a subfolder of the repository?

The project files, such as package.json, must be at the root of the repository. If a repository holds several apps, give the one going online its own repository, or use a ZIP of that folder.

Can I go back to ZIP files?

Yes. On the Releases tab choose Uploaded .zip and publish as usual. Each release picks its source freely.

The new release is broken. Can I go back?

Yes. In Release history press Restore this release on the previous one. The branch and commit labels show which code you are returning to.

The build failed. Where is the reason?

Open that release's log in the release history, or have your AI read the log and fix it, then push and release again.

Summary

When the code is already in Git, letting BrewInTH fetch and build it is easier and leaves a better trail. Enter the https link, pick the branch, add a read-only token for a private repository, check access, and press Build & publish whenever you are ready to ship.

Start your first project free →