Websites that live in git

Gitt One Pages is a site-building technology: your content lives in a git repository, a standard Docker image turns it into a fast static website, and CI ships it to any hosting — including yours

POWERS THE WEBSITES OF

Two kinds of website, one production line

Whatever you publish, the engine arrives as a ready-made builder image and your repository stays down to content plus a few lines of Dockerfile.

{project}/docs

Knowledge bases

The markdown your team already writes in GitLab, published as a website. Clients read the site instead of walking into your repository.

Plain .md files — no front matter, no rewriting for the web
A page looks the same in the repository and on the public site
Publish to the world or keep it intranet behind basic auth

{project}/www

Landing pages

Marketing sites with strictly typed content: the structure is fixed, the copy changes often — and changing it never touches the layout.

Content written as semantic typed tags, separate from the design
Edited by a content manager, an AI agent, or both
One config file per site: title, contacts, logo, locales, menu

WHO IT IS FOR

Three ways a small website goes wrong

Gitt One Pages started as our own production line — we are its first and most demanding user.

If you commission websites

Your site is a hostage: it is built on whatever the studio that made it understands, so leaving means rewriting. The usual escape — a CMS of your own — buys you hosting bills, break-ins and updates.

Here the content is yours in plain files, and the site runs as a standard image on any hosting — including your own.

If you build websites

Every project is a unique artifact. A year later nobody remembers how to build it, the dependencies have rotted, and the developer who knew has left.

One conveyor for every site: the same builder image, the same pipeline, the same quality bar. Knowledge lives in conventions, not in people.

If you write the docs

Knowledge in markdown looks decent only inside GitLab. Handing it to a customer means either an invite to your repository or a website nobody has time to build.

Point a builder image at the repository and the same files become a site. Publishing costs a Dockerfile.

From a git repository to a live site

A new website is just a new content repository. Time to first site — hours, not weeks.

1
Write content
Put your content in a git repository: markdown files for articles and knowledge bases, semantically typed content tags for landing pages
2
Add a tiny Dockerfile
A few lines on top of our standard builder image — no build configs, no toolchain to maintain in your repo
3
Push to master
CI builds your content into a ~50 MB nginx image and deploys it — to our Kubernetes clusters or any Docker hosting of yours
4
Edit and preview
Change content right in the GitLab web editor; every draft gets a staging replica of the real site to review before release

The technology inside

Boring, proven building blocks — assembled into a production line

Jamstack

JavaScript, APIs and Markup: pages are pre-rendered at build time and served as static files — fast, always on, nothing to hack

Astro + Tailwind

An open-source content framework that ships zero JavaScript by default, and ready-made design concepts — fonts, spacing, components — instead of a graphic designer on the project

GitLab-flavored Markdown

One rendering engine everywhere: a page looks the same in the repository and on the public site — with Mermaid and PlantUML diagrams

Docker portability

A site is a repository plus a standard image. Hosting is a detail, not a cage — the same image runs on any infrastructure

GitLab UI as the CMS

The web editor and Web IDE are the admin panel: no separate CMS to install, host, update and defend from attacks

CI/CD with staging

Every change builds an exact replica of the future site to discuss before release — content managers see real feedback on drafts

AI-ready content

Semantically typed data is a substrate for agents: AI edits and generates content without a programmer and without breaking the build

Built for speed

Minimum JavaScript, maximum pre-rendering: Lighthouse 100 is the acceptance target for every produced site, not a nice-to-have

Own your website, don't rent it

Most websites are hostages of the studio that built them: leaving means rewriting. Ours are designed for leaving — content in plain typed files that migrate to any CMS, an MIT-licensed engine any developer or AI agent can pick up, and a Docker image that runs anywhere. We measure this honestly as exit time: minutes from git clone to a working local build

IN NUMBERS

Industrialized, not handcrafted

Every site produced by the technology shares the same conveyor: the same builder images, the same deployment pipeline, the same quality bar. Knowledge doesn't get lost with a departed contractor — it is encoded in conventions.

>9production websites are built and running on Gitt One Pages

~50 MBproduction image nginx plus your entire static website

hoursto the first site a new website is just a new content repository

100Lighthouse score is the acceptance target for produced sites

OUR MISSION

Industrialize the production of small websites

A landing page or a knowledge base shouldn't be a unique handmade artifact. Content belongs to git; turning it into a fast website is the job of standardized infrastructure. A developer drops markdown files into a repository — and gets a site. A content manager or an AI agent edits semantically marked-up data — and the site updates. No vendor lock-in, no CMS to maintain, no site held hostage.