Push to deploy
Push to your main branch and see the result on your staging site minutes later.
All six parts of Forge
Graft · GitOps
Change the file, and the platform follows
Graft is how anything on Forge changes. Machines, networks, applications and settings are files in Git; pipelines check them and apply them; and each kind of change has a set gate - automatic, approved by a person, or emergency only.
Built on FluxCD, OpenTofu and Ansible
Why it matters
When servers are changed by hand, the only record is someone's memory. The next person to touch the system starts by finding out what is actually there.
With Graft, what is written in Git is what is running. Every change has an author, a reason and a review, and rolling back means reverting a commit.
- kinds of change, each with a set gate
- 35
- of them run automatically
- 6
- resources defined in OpenTofu
- 170+
- Ansible playbooks
- 82
How it works
Infrastructure as code
OpenTofu describes the virtual machines, the network and the CDN. Ansible playbooks set up what runs on each machine.
The cluster follows Git
FluxCD keeps the Kubernetes cluster in step with Git. If someone changes something by hand, Flux puts it back.
Staging first, then a person
When you push your code, an image is built and deployed to a private staging site automatically. Production changes only when a person promotes that tested image.
A gate for each kind of change
A catalogue lists every kind of change we make and its gate. Routine changes run automatically; most need a person to approve them; a few are emergency-only and logged.
A report after every change
When an approved change is applied, the result is written back to its ticket, so there is a record of what actually happened.
Live today
- Every product and platform change through Git and CI checks.
- Automatic staging deploys, behind a PIN; a person promotes every live release.
- A catalogue of changes with automatic, approval and emergency gates.
- Reports written back after each applied change; rollback by reverting a commit.
In progress
- A written, tested plan for rebuilding the whole platform from Git.
- Working down the short register of changes that are still made by hand.
What you get
A person on every release
Nothing reaches your live site without someone choosing to promote it.
One-step rollback
If a release is wrong, the previous version is one revert away.
Built on
FluxCD
A CNCF GitOps toolkit. It keeps the cluster matching Git and updates image tags.
OpenTofu
The open-source, community-run fork of Terraform. It defines our machines, network and CDN.
Ansible
Step-by-step playbooks that configure each machine the same way, every time.
GitLab
Our self-hosted Git server and CI pipelines (Community Edition).
Kaniko
Builds container images inside CI, without a privileged Docker daemon.
Related parts
Hallmark
A standard name for every service, so nothing on the platform is a mystery. Every name is checked automatically before it exists.
Portcullis
The front door. It routes visitors to the right place, with a CDN caching public pages so they load fast. The cluster dials out to it, so it opens no web ports to the internet.
Citadel
Disks and S3-compatible object storage. On our main tier, every piece of data is copied to three separate machines, so one failure loses nothing.