What runs Forge

Most clouds hide their building blocks. We name ours. Each part of Forge has a plain-English job and a credit line to the open-source project it is built on - because you should be able to check our work, and because those projects deserve the credit.

The core

Six parts that make it a platform

Hallmark

Naming

A standard name for every service, so nothing on the platform is a mystery. Every name is checked automatically before it exists.

Validated with CUE

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.

Built on Pangolin, Traefik and WireGuard, with bunny.net in front

Keystone

DNS and certificates

How our services find each other, and how browsers and services know they are really talking to us.

Powered by Knot DNS, Unbound, step-ca, cert-manager and Let's Encrypt

Citadel

Storage

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.

Powered by Ceph

Graft

GitOps

Every setting lives in Git. Change the file and the platform follows - so there is a record of everything.

Built on FluxCD, OpenTofu and Ansible

Flash

Identity

One "Sign in with Forge" account across the apps you use with us, defined as code. In testing now.

Built on Keycloak

Capabilities

What you can run on it

The services your project actually uses. We run them, patch them and back them up - and we are proud of what each one is built on, so we say.

Secrets

Passwords and keys kept encrypted in a vault, never in code, and handed to services as they need them.

HashiCorp Vault

Databases

PostgreSQL and MySQL, run, patched and backed up by us. You get a connection string.

PostgreSQL (CloudNativePG) · MySQL

Cache

Fast in-memory caching, so your application does not ask the database twice.

Redis

Search

Fast, typo-tolerant search across your own content, indexed on our hardware.

Meilisearch

Files and email

Shared files synced to your devices, and outgoing email sent from your own domain.

OpenCloud · Stalwart

Zero-trust networking

Every connection checked, every time, with no trusted inside. Being rolled out across the platform now.

Calico · Headscale · MikroTik

Observability

Logs, metrics and dashboards for everything we run, with an alert when something fails.

Prometheus · Grafana · Elasticsearch · Kibana

Analytics

Visitor numbers for your site without cookies or tracking anyone across the web.

Umami

CI/CD

Pipelines for your code as well as ours: linted, tested and checked before anything lands.

GitLab CI · ansible-lint · pytest

Resilience and recovery

What happens when something fails

Machines fail. Power goes. Someone deletes the wrong thing. We plan for each of these rather than hoping, and we are working towards practising every recovery, not just the backup.

Ask us how far each one has got. We would rather give you the facts than a promise.

  • Storage keeps three copies

    On our main storage tier, every piece of data lives on three machines. One can fail without anyone noticing.

    Ceph

  • Automatic backups

    Databases, secrets and our code host are backed up automatically. Next come encrypted copies kept off-site, with restores we test.

    CloudNativePG · mysqldump · Vault snapshots

  • Ready for a power cut

    A chain of batteries carries the cluster through a power cut, and shuts it down cleanly before they run out.

    Network UPS Tools

  • Rebuilt from the files

    Because machines are written as code, a lost one is rebuilt from Git, not from memory. That is how we replaced every Kubernetes worker.

    Graft · OpenTofu · Ansible

AI inference

Run models on hardware in Sheffield

Brocco includes an NVIDIA DGX Spark. It runs open models on our own hardware - today a coding model for our own tools - so the work it does never leaves the building.

It is one machine, not a data centre, and we say so. It suits research tools and internal workloads today; we are opening it up carefully.

  • Your data stays put

    Prompts, documents and results handled on the Spark stay on Brocco. Nothing is sent to an outside model provider unless you choose one.

  • Open models

    We run openly published models you can inspect, and we tell you which one: today, Qwen3-Coder, served with vLLM.

  • Honest about scale

    One DGX Spark suits research and internal tools. If you need more, we will say so and help you plan.