Engineering Platform › Source control · See it on the architecture map

Source Control

How my code versions are organized. One account on GitHub holds nine private repositories: one per application, one for the control plane, one for each piece of shared code, and one for the shared CI. Branches map to environments, so where a change is in its life is visible from the branch it sits on. Ports are chosen the same way for every app.

9 repositories

all private, on one account

3 branches

main, sit and prod: one per environment stage

One repository per thing that ships on its own

Applications: tourney, runway, getseen. Each app deploys and versions independently.
Control plane: control-tower. The tool that shows status and runs promotions for every app above.
This site: portfolio. A static site, deployed the same way as the apps.
Shared code: auth-kit (login security), spark-worker (the GPU worker client) and rag-pipeline (document search). Each lives in its own repository so more than one app can install it.
Shared CI: fomx-ci. The five quality gates, written once and called by every repo above.

Branches are environments

A change starts on main. When the five gates go green it moves to sit and is rebuilt on the test environment with no human step. Moving from sit to prod is a deliberate person's action, never automatic.

main is where work lands and where the gates run.
sit always matches what is running in system integration testing.
prod always matches what is live.

Shared code is extracted once, then versioned

Code stays inside its app until a second app needs it. Then it moves into its own repository and both apps install it from there, instead of keeping copies. The shared CI is pinned to a version tag (v1), so a change to a tool version is one commit in one place, and a repo can stay on an older tag until it is ready.

Where each application keeps its data

Tourney: MySQL for the application data, with a cache for rate limits.
GetSeen: SQLite, one database file per deployment.
Runway: No server-side database. Each user's plans stay in their own browser.
Control Tower: An append-only event log, one immutable record per line, so history cannot be edited.

Data never lives in a repository. Each environment has its own, created on the machine that runs it.

Secrets never enter a repository

Deploy credentials live in GitHub Actions secrets and in environment files on the servers, never in code.
A secret scanner runs on every commit locally and again in CI. It is one shared script, so both places apply the same rules.
A commit that trips the scanner is refused before anything is uploaded.

Which ports each app uses

Each app has one port per environment. Dev runs on a local PC. SIT runs on a private machine that is reachable only over a private network (Tailscale). Prod runs on the shared web server behind one nginx, on the standard secure port.

Tourney: Dev 5000 · SIT 5100 · Prod 443
Runway: Dev 5173 · SIT 8080 · Prod 443
GetSeen: Dev 8765 · SIT 8767 · Prod 443
This site: Dev 5330 · SIT 8090 · Prod 443

A new app's Dev port is the next free one in the 53xx range. Its SIT port is the next free one from 8081 to 8099. Prod is always 443, through the shared web server, with a name per app instead of a port.
SIT ports are private and are opened one at a time in the network's access rules. The New app form picks a free port and tests that it can be reached before anything is built.

01 One repository per thing that ships on its own

02 Branches are environments

03 Shared code is extracted once, then versioned

04 Where each application keeps its data