A builder's work is not writing code. It is having AI write it, evaluating it, and integrating it (1-04). But the code that results needs a place to live — the repository. The more code AI generates, the more control over where it lives matters.
GitHub and Azure DevOps both sit on someone else's servers. Here, that workshop gets stood up on your own side.
Why keep code on your own side
Code is an asset. The substance of the business itself is written there. The reason to leave it parked on someone else's platform is now thin.
- Cut the dependency — pricing, terms, and availability don't change at another company's convenience
- Couple it tightly with AI — generation, review, and CI run by your own rules
- One with the gate — code goes inside the 2-03 authentication too
Generic Git hosting is already there as OSS. You don't write it, you stand it up.
Stand up Forgejo
The workshop is Forgejo. A single Gitea-family binary carrying repositories, issues, pull requests, review, and CI in one — a replacement for GitHub, GitLab, and Azure DevOps. The data rides on the PostgreSQL from 2-02.
# compose.yaml — stand up Forgejo on the 2-02 DB
services:
code:
image: codeberg.org/forgejo/forgejo:latest
environment:
FORGEJO__database__DB_TYPE: postgres
FORGEJO__database__HOST: db:5432 # the 2-02 PostgreSQL
FORGEJO__database__NAME: forgejo
FORGEJO__database__USER: postgres
FORGEJO__database__PASSWD: change-me
volumes: ["./forgejo:/data"]
ports: ["3000:3000", "2222:22"]
restart: always
docker compose up -d
git remote add origin ssh://git@localhost:2222/team/app.git
git push -u origin main # already on your own server
CI/CD — Forgejo Actions
Automating tests, builds, and deploys is Forgejo Actions. Workflows in the same syntax as GitHub Actions run as-is. Just drop one file in the repo.
# .forgejo/workflows/ci.yml
on: [push]
jobs:
test:
runs-on: docker
steps:
- uses: actions/checkout@v4
- run: pytest # on your own runner, at zero marginal cost
Step off GitHub Actions' metered billing. The runner is on your side too, so you can verify AI-written code any number of times without watching a meter.
The local tools — Zed and Claude
If the server is Forgejo, local editing is Zed. A Rust-built, lightweight editor with co-editing and AI integration. Call Claude in place to generate, fix, and explain, while the builder concentrates on evaluation and integration.
git clone ssh://git@localhost:2222/team/app.git
zed app/ # call Claude, have it write, evaluate, and push
AI writes; the human decides. With the workshop (Forgejo) and the tool (Zed) in place, that division of labor just runs.
Place it behind the gate, and migrate
Put Forgejo behind the reverse proxy (2-03). Migrating from GitHub, Forgejo's "New Migration" imports a repository together with its issues and PRs.
git.example.com { reverse_proxy code:3000 }
No need to switch in one stroke. Keep GitHub as a mirror and run in parallel, then move production onto Forgejo once it feels natural (parent series, 2-03).
Code is the substance of the business itself. Control of where it lives belongs to you, not another company.
Summary
The builder's workshop, on your own side.
- Forgejo — repositories, issues, PRs, and review in one (on the 2-02 PostgreSQL)
- Forgejo Actions — GitHub Actions-compatible CI/CD, the runner on your side
- Zed + Claude — call AI into a lightweight editor; write, evaluate, push
- Behind the gate — fenced by the reverse proxy, migrate from GitHub gradually
The only code written is configuration. The generic is already there, as OSS. Next, we stand up mail (Stalwart) on our own side and cut the dependency on Exchange and Outlook.