Technical Details

CodeFloe Pages runs on CodeFloe’s own infrastructure. Sites are served by git-pages, the same software Codeberg Pages uses, on CodeFloe’s own servers.

Where your site is served from

Three dedicated virtual machines, one on each host of our Hetzner cluster in Falkenstein.

Every node holds a complete copy of every site. A publish is sent to all three, and any one of them can serve any request, so losing a node costs nothing: the other two keep answering.

Each node has 4 vCPU and 8 GB of RAM, with site content on its own disk. The nodes live on shared storage, so a node can be moved between hosts without stopping it.

How a request reaches your site

flowchart TB
  V["your visitor"]
  subgraph EDGE["edge — HAProxy on all 3 cluster hosts"]
    E["terminates TLS and HTTP/3<br/>picks your site from the hostname"]
  end
  subgraph NODES["nodes — private 10G network"]
    N1["node 1<br/>git-pages<br/><i>full copy</i>"]
    N2["node 2<br/>git-pages<br/><i>full copy</i>"]
    N3["node 3<br/>git-pages<br/><i>full copy</i>"]
  end
  V -->|"HTTPS and HTTP/3"| E
  E --> N1
  E --> N2
  E --> N3

1. Your visitor resolves a codefloe.page address, which points at all three cluster hosts. If one is unreachable, browsers and command line tools simply try the next.
2. The edge terminates the connection. It speaks HTTP/2 and HTTP/3 over the same certificate, and chooses your site from the hostname the visitor asked for.
3. The request is forwarded to one of the three nodes over a private 10 Gb/s network that never touches the public internet.
4. The node serves your files.

Requests are spread across the nodes, and a node that stops answering is taken out of rotation until it recovers.

How your site gets published

Publishing is a push, not a pull. Your site’s files are uploaded to all three nodes. Nothing on the serving side ever reads your repository, which is why private repositories work exactly like public ones and no deploy key is involved.

Each upload is authorised against CodeFloe itself: a node accepts it only after confirming with the forge that whoever sent it may push to the repository the site belongs to. For a workflow, that is the run’s own token, which is scoped to that one repository and expires with the job.

Stored content is compressed, and files that are identical between sites are stored once. In practice a site occupies well under half the space its files take in your repository.

Addresses

Sites are served under codefloe.page:

<username>.codefloe.page/<repository>/

A repository named myproject owned by techuser is served at https://techuser.codefloe.page/myproject/.

A repository named pages is special: it is served at the root of your own subdomain, https://techuser.codefloe.page/.

Addresses from before the migration (2026-09-20)

Sites that existed before Pages moved to CodeFloe’s own infrastructure had a flat address, <username>-<repository>.codefloe.page. Those addresses still work and are not going away on a schedule.

They are served, not redirected. A visitor stays on the old address and the site behaves exactly as it did before, which means absolute paths resolve there even when they would not under the new one.

HTTPS

Certificates are issued automatically from Let’s Encrypt and renewed before they expire. There is nothing to configure and no certificate to upload.

HTTP requests are redirected to HTTPS.

Limits

Limit	Value
Maximum site size	512 MB
Bandwidth	no fixed limit
Build minutes	see your plan’s CI quota

Sites are built by Forgejo Actions using your repository’s own workflow, so build time counts against your CI quota rather than a separate Pages allowance.

Performance

Pages is not a CDN. Your site is served from a single region (Falkenstein, Germany) rather than mirrored to edge locations worldwide.

For visitors far from Europe this adds latency on the first connection. In practice it is rarely noticeable for static content: the edge supports HTTP/3, which recovers most of that cost on a slow or lossy connection, and content is compressed before it is sent.

Serving from one region is also what keeps your visitors’ requests inside the EU.