How do you turn a GitHub repo into a website without Pages?

Have an agent read the repository and publish the static files. It builds first if the repo holds sources, then hands the output to Birta, which serves it at an address. Nothing in that path touches Pages settings or a workflow file.

Can you publish from a private GitHub repository?

Yes. Publishing this way reads files, so a local clone is enough and the repository stays private. On Pages itself, GitHub's documentation puts publishing from a private repository on its paid plans, which is the most common reason people look for another route.

Does the site update automatically when I push?

No. There is no hook watching the branch, so a new version goes live when you or your agent publishes one. The address never changes when you do, and old versions stay available for a rollback.

What if my repository is a Next.js or Astro project?

Build it locally and publish the output directory. Nothing is built on our side, so a repository of sources has to become a folder of files first, and any part of it that expects server-side rendering will not survive the trip.

Is it against GitHub's terms to run a shop on Pages?

GitHub's terms for Pages say it is not allowed as free hosting to run an online business, an e-commerce site, or another site primarily facilitating commercial transactions or commercial SaaS, and they describe the service as primarily for showcasing personal and organisational projects. That is a specific list rather than a blanket rule about commercial intent, so read the terms themselves before deciding your case.

What if my files are not in a repository at all?

Then it is a folder, and the publish a folder route is the shorter walkthrough: no clone, no build question, the agent reads what is on your disk.

Deploy a Site from a GitHub Repo Without GitHub Pages

The short answer

Point an agent at the repository and ask it to publish the site. It reads the files and hands them to Birta, which stores them and serves them at an address. No Actions workflow, no Pages settings, no branch to keep clean.

One condition decides how much work that is. If the repo already holds a built site, publishing is one step. If it holds sources, the build happens on your machine first, because nothing is built on our side.

Which repository goes live as it is

Publishable without a build

index.html at the root of the folder being published.
The CSS, JavaScript, images and fonts the HTML references, at matching paths.
Nothing that needs a server: no PHP, no .env, no runtime API.

Hand-written static sites qualify. So do most course projects, documentation exported to HTML, and anything you would have dropped on Pages without configuring a build.

What gets published is that folder, not the repository. Your .git directory, the README, the CI config and the history stay where they are.

When the repo holds sources, not a site

A Next.js, Astro, Vite or Jekyll repository is a description of a site rather than the site. Somebody has to run the build, and that somebody is you or your agent, locally:

npm install && npm run build

Then publish the output directory, whatever the framework calls it: dist, build, out, _site. Tell the agent which one, or ask it to work it out from the config and tell you what it found.

Two things to check in the output. That it opens correctly from your own disk, and that nothing in it expects server-side rendering, because a static export is what actually ships.

The prompt

For an agent with repository access and a Birta connection:

Publish the site in this repository to Birta.

Repository: [url or local path]

Work out and tell me first:
- whether this repo holds a built static site or sources that need a build
- if it needs a build, the command and the output directory
- whether anything in it requires a server at runtime

Then build if needed, publish the static output as a project named [name],
and give me the address.

Do not publish the repository itself: no .git, no README, no CI config.

For a private repository, the agent needs access. Working from a local clone you already have is the simplest version of that: it reads the files on disk and never touches GitHub's API.

Four times Pages is the wrong tool

The repository is private and the account is free. GitHub's own documentation puts publishing from a private repository on its paid plans. If the code has to stay closed and the account is not paid for, Pages is not available to you.

The site is a shop or a commercial service. GitHub's terms for Pages describe it as primarily for showcasing personal and organisational projects, and say it is not allowed as free hosting to run an online business, an e-commerce site, or another site primarily facilitating commercial transactions or commercial SaaS. Read that narrowly: it is a specific list, not a ban on every page that mentions money. If your site is a shop, though, it is on the list.

The repository is not yours. You found a static site you have permission to publish, or you are working on a client's code without admin rights to their repository. Enabling Pages is a repository setting, so you need that access. Reading files and publishing them somewhere else does not.

You want the agent to stay the maintainer. Pages publishes what lands on a branch, so the loop runs through commits and workflow runs. If your intent is to describe a change in a sentence and have the agent make it and publish, the repository stops being the place the site lives.

What Pages does better

Two things, plainly. A custom domain on Pages costs nothing, while here your own domain comes with Solo, the first paid plan. And Pages publishes on push: merge to the branch and the site updates by itself, with no one to remind.

If those two are what matter most to you, and the repository is public and not a shop, Pages is the better fit and the Birta and GitHub Pages comparison lays out the rest of the trade.

Publish again after a commit

Publishing again keeps the same address. Prior versions stay, so a bad deploy is a rollback rather than a scramble.

The part to be clear about: nothing here reacts to a commit. There is no webhook watching the branch, so a new version goes live when you or your agent publishes it. In practice that means saying "publish the latest" at the end of a work session, which suits a site that changes when you decide it does and suits a busy branch less well.

Point your agent at the repo

It works out whether the repo needs building, publishes the output, and returns the address.

Connect your agent to Birta