What Is Codeberg Pages?

Updated

Codeberg Pages is a static website hosting service built into Codeberg. You put your site's files into a Git repository on Codeberg, and Codeberg serves them as a live website. It's designed for open source project homepages, developer blogs, and web experiments, and the service describes itself as quick, easy, free, and fast. It only serves static content — HTML, CSS, fonts, images, and similar files — so there's no server-side code execution.

How the hosting model works

Your website lives in a Git repository, and Codeberg Pages maps that repository (or a specific branch of it) to a URL. Two things determine where your site appears:

  • A repository named pages with a branch named pages makes the site available at the main subdomain.
  • A pages branch inside any public repository publishes that repository's site at a URL that includes the repository name.

The resulting address follows this pattern:

https://USERNAME.codeberg.page/REPOSITORY

USERNAME is your user or organization name, and REPOSITORY is the repository name. If the repository itself is called pages, the repository segment is omitted.

Two ways to deploy

Codeberg Pages supports both automated and manual publishing.

With CI (static site generators)

If you build your site with a generator such as Jekyll, Hugo, or a similar tool, you can integrate deployment into a Forgejo Actions workflow that builds the site. Codeberg's documentation covers the workflow setup.

Without CI (plain static files)

If you're serving hand-made static files, you configure a webhook on your repository to deploy changes. The documented steps are:

  1. Set up your repository. Either create a public repository named pages with a branch called pages, or create a pages branch in an existing public repository:

    git switch --orphan pages
    git rm --cached -r .
    
  2. Set up deployment. In your repository's Settings, go to Webhooks and click Add webhook. Choose Forgejo as the webhook type. Set the Target URL to your site's URL (for example, https://USERNAME.codeberg.page/REPOSITORY, or the custom domain if you have one). Set the Branch filter to pages, then click Add webhook.

  3. Upload your files. Push your static content — HTML, styles, fonts, images, anything else. It becomes accessible at https://USERNAME.codeberg.page[/REPOSITORY].

Using a custom domain

You can point your own domain at Codeberg Pages. The configuration has two parts: DNS records and an authorization record.

DNS records — add one of the following on your domain:

Record type Value When to use
CNAME codeberg.page. Standard subdomains
ALIAS codeberg.page. Apex domains where CNAME doesn't work
A 217.197.84.141 Fallback when ALIAS isn't supported
AAAA 2a0a:4580:103f:c0de::2 Fallback when ALIAS isn't supported

If ALIAS isn't supported, the documented fallback is to add the TXT record described below and use the A + AAAA records together.

Authorization record — add a TXT record to the subdomain _git-pages-repository containing the Git HTTPS clone URL of your repository:

TXT https://codeberg.org/user/repo.git

This authorizes the Codeberg Pages server to deploy your repository to the server.

What to check before you start

  • Static only. Codeberg Pages serves files; it doesn't run backend code. If your project needs a database or server logic, this isn't the right host.
  • Public repositories. The documented setup uses public repositories, so treat everything you push as publicly visible.
  • Branch name matters. The pages branch is what gets deployed in the webhook setup, and the branch filter must match it.
  • Custom domains need both DNS and TXT records. Missing the _git-pages-repository TXT record will block deployment to your domain even if DNS resolves correctly.

If your goal is a project homepage, a static blog, or a small web experiment that fits in a Git repo, Codeberg Pages covers it without a separate hosting account.