Your Own Git Server and Agent Runners: When Sovereignty Pays

For most small teams, GitHub or GitLab.com is the right default. Consider your own forge when sustained build minutes and storage bills, client contracts or data residency, heavy AI jobs, offline work, or enough paid seats justify an operator and tested recovery. Usually, try your own runners attached to GitHub first. Don't move merely because a server looks cheaper than a subscription.

“have each of us the advantage of using the books of all the other members, which would be nearly as beneficial as if each owned the whole.”

Benjamin Franklin, describing his club's shared books in his Autobiography.

Franklin's first arrangement also suffered from poor care of the collection. Sharing the books solved one problem; looking after them remained work. His account moves on to the subscription library. The useful parallel is a shared workshop with a keeper, rather than a romantic argument for owning every tool.

GitHub supplies that workshop for software. Git is the version history, recording changes so people can collaborate and recover earlier work. A forge adds accounts, issues, reviews and releases around those repositories. A runner is the worker that executes a build, test or agent assignment. You can change the worker without moving the library.

Our Sovereign AI Made Simple guide makes the distinction that governs this article: files on your server, execution on your server and inference on your server are separate choices. A coding agent can edit a local repository while sending context to a hosted model. Buying a dedicated server does not erase that destination.

The prices below are US dollars before tax, read November 1, 2026. The examples are planning illustrations, not customer bills or performance benchmarks. The download kit carries the installation sequence, security checks, restore exercise and matching worksheets.

Buy control over the part that is causing trouble

A team with ordinary private repositories, occasional builds and no server administrator should normally stay hosted. GitHub Free includes unlimited public and private repositories; repository count by itself is a weak reason to migrate. Paid controls, compute, retained artifacts and seats are the more useful things to count. GitHub plans.

Start a review when build overages become a recurring operating expense, when large binaries dominate storage, or when jobs need devices and network access that hosted runners cannot provide. Client restrictions may require a particular country, operator or disconnected environment. Those requirements can justify a higher bill. Read the actual contract before translating “private repository” into “permitted data location.”

A hybrid keeps GitHub's repository and review interface while your machines run selected jobs. Developers keep familiar pull requests, and the operator takes responsibility for workers. A fully self hosted forge also transfers responsibility for its database, authentication, upgrades and recovery. It may save seat charges, but someone now owns every broken login.

Air gapped work goes further: dependencies, actions, container images, model weights, identity and recovery must all work without external services. Cloudflare Tunnel and hosted AI are unsuitable dependencies for that boundary. Treat offline operation as a separate design and rehearse it with the connection absent.

Terms used below: CI means continuous integration, the automatic checks after a change. An artifact is an output worth retaining, such as a tested installer. An ephemeral runner accepts a bounded job and is discarded. A GPU is a graphics processor suited to parallel calculations; it is useful for some AI jobs that a general CPU handles slowly. SSO means single sign-on through a shared identity provider. Provenance records how an artifact was built. An SBOM, or software bill of materials, lists the components inside it, much as an ingredients list describes a packaged meal.

What GitHub charges today

GitHub's pricing page lists Free at $0, Team at $4 per user per month and Enterprise starting at $21 per user per month. Seat prices can change at renewal; the calculations hold Team's rate constant so you can follow the comparison.

The current Actions billing documentation expresses the included compute allowance in dollars. Older minute tables can mislead when a team mixes machine types.

Those minute equivalents divide the credit by $0.006, assuming no other eligible product consumes that shared value. They are neither allowances per seat nor extra credits beside the dollars. Standard hosted runners for public repositories remain free. Eligible larger runners can draw from Team or Enterprise Cloud compute credit, but larger runners are billed even for public repositories. Each job's partial minute rounds upward.

Here is a useful selection from the runner rate card, billed per execution minute:

A minute on one row is not the same amount of completed work as a minute on another. Measure your build before multiplying a rate by yesterday's runtime.

The self hosted runner charge that was postponed

GitHub's December 16, 2025 announcement originally proposed a $0.002 per minute platform charge from March 1, 2026 for self hosted Actions. The notice now says that change is postponed while GitHub reconsiders its approach. The current billing documentation says self hosted runners are free to use with Actions. We therefore use $0 platform minutes in the hybrid budgets, with hardware and administration charged separately.

Do not turn the old proposed date into an invoice. Nor should a three year plan assume pricing cannot change. As a sensitivity calculation, $0.002 times 200,000 monthly minutes would be $400 before any future allowance rules. Treat that as arithmetic about the postponed proposal; nobody is billing it today.

Storage has several meters

Actions artifacts and GitHub Packages share the storage allowance above. Additional shared storage is $0.25 per GB per month. Actions cache has a separate 10 GB allowance per repository, with additional configured capacity at $0.07 per GB per month. Custom image storage has separate Team and Enterprise allowances of 75 GB and 150 GB, with excess at $0.07. Storage accrues over time; deleting everything on billing day cannot erase the earlier usage.

Packages includes monthly transfer of 1 GB on Free, 10 GB on Team and 100 GB on Enterprise Cloud. Container registry storage and bandwidth are currently free under its separate policy. Package downloads authenticated with a workflow's GITHUB_TOKEN receive the documented Actions transfer exemption, including on self hosted runners. A personal token can change the billing treatment.

Git LFS, which stores large file contents outside ordinary Git objects, has another allowance: 10 GiB storage and monthly downloads on Free, or 250 GiB of each on Team and Enterprise Cloud. Its metered rates are $0.07 per GiB per month for storage and $0.0875 per GiB downloaded, confirmed in GitHub's calculator. The calculator also lists excess Packages transfer outside Actions at $0.50 per GB. Changed LFS versions consume storage too. A model checkpoint can be expensive history to retain accidentally.

GitLab.com is a credible alternative, especially if the team already uses its pipeline and issue workflow. Its pricing page lists Free at $0 and Premium at $29 per user per month billed annually; Ultimate requires a sales quote. Free includes 400 monthly compute minutes, Premium 10,000. Compare user limits, storage and required features before treating the free tier as interchangeable with GitHub. Moving between hosted products is usually a smaller operating commitment than maintaining a forge.

Choose the forge separately from the workers

GitLab also calls for 40 GB of application storage before repository data, with PostgreSQL needing roughly 5 to 12 GB depending on use. None of these figures includes an arbitrary local language model or an unbounded build queue. Our proposed 4 GiB forge VPS is a starting budget for Forgejo, not a measured capacity promise.

Use Forgejo Runner with Forgejo Actions, Gitea Runner with Gitea, or GitLab Runner with GitLab. Gitea's current runner documentation describes the successor to act_runner; choose instructions matching your installed release. Their configuration, tokens and supported workflow features differ. “Actions compatible” does not guarantee every GitHub integration transfers unchanged. The Forgejo runner guide, Gitea runner guide and GitLab Runner documentation are the implementation references.

Our kit chooses Forgejo with PostgreSQL and a separate disposable worker. A database holds users, issues and review state; repositories alone cannot restore those records. Put the forge on a quiet machine and noisy jobs elsewhere. A runner label called gpu merely selects a worker; it cannot manufacture a graphics card, driver or compatible runtime.

The distinction has an older counterpart. The 1963 CTSS Programmer's Guide explains time sharing as a way to improve programmers' interaction with expensive computers. The point was useful turnaround. A busy server whose queue leaves everyone waiting can lose the economic argument while looking admirably occupied.

Put each workload in the right place

A VPS is a virtual machine. A dedicated server is rented physical hardware. Neither includes your application's maintenance. The following are advertised monthly prices, before tax, read November 1; optional disks, traffic and support can add charges.

Sources: DigitalOcean Droplets, US Kimsufi, Rise and US Eco catalog. OVH figures are advertised monthly starting prices. Minimum commitment, final configuration and delivery must be confirmed in an order; we did not complete a cart. The 36 month example uses the published SYS-5 starting price as a budget scenario, with its setup fee included.

Our Kimsufi and Access guide explains the tradeoffs: cheap physical hardware, variable availability and your own software recovery. The AWS comparison explains why equivalent thread counts don't establish equal performance. A hardware thread is not another independent physical core.

Vercel Pro starts at $20 per month, with one deploying seat and $20 usage credit; additional deploying seats cost $20 each monthly under its Pro plan terms. Hobby is free for personal, noncommercial use. Vercel belongs on the public static and preview side of this design. It is not where we install a persistent Forgejo database or a privileged runner daemon. Private previews need their own access controls and plan review.

For burst AI work, RunPod's pricing lists an RTX 4090 Secure Cloud Pod at $0.89 per GPU hour on demand. Standard network storage below 1 TB is $0.07 per GB per month. Our GPU example uses those two rates. Community offers, interrupted capacity and other GPUs are different purchases. “Tensor server” is a broad description, not a standardized unit of performance.

Keep the controller and source history on dependable CPU hosting; rent the GPU when a tested job needs it. Store durable outputs independently before termination. Benchmark model memory, batch size and runtime first. Hosted model API charges remain separate, as our API and subscription guardrails guide explains.

Three budgets over 36 months

We price administration at $68.09 per hour, the series' employee compensation proxy: the BLS administrator median of $47.66 divided by a 70.0% wage share. Those underlying sources were read October 29. It is not a contractor quote. Setup and monthly hours below are our low and high assumptions, including routine updates, backup checks and restore exercises.

Backblaze B2 costs $6.95 per decimal TB per month, with the first 10 GB free. Thus retained storage costs max(0, GB − 10) × $0.00695. Count all retained versions. The examples stay within included transfer and request allowances: downloads up to three times average stored data are free; additional ordinary egress costs $0.01 per GB. Chargeable Class D requests and source-provider egress would be additional.

The common existing administration computer and independent local backup disk need no new purchase in these examples. Both hosted and self hosted paths export recoverable data to B2. We assume an existing domain, free access within the team's allowance, no excess Packages or LFS charges, and no paid model inference. Add those if your workload needs them. Serious incidents, custom migration software, tax and required compliance work are excluded. These are operating budgets, not high availability designs.

The method is setup + 36 × monthly. Setup is hours times $68.09 plus any installation fee. Monthly includes seats, machines, usage, retained backup data and administration. Break even is the rounded-up month when accumulated monthly savings repay the extra setup. Equal or higher monthly cost with higher setup means never. Tables round to whole dollars; calculations retain cents and smaller storage fractions.

A three person shop: keep GitHub

Assume 2,000 standard private Linux minutes monthly, within Team's $18 credit, and 100 GB of retained B2 data costing $0.6255 monthly. GitHub seats cost $12. The alternative uses a $24 forge VPS and a separate $42 worker, with enough job disk assumed after cleanup.

For example, Forgejo's low total is 8 × $68.09 + 36 × ($24 + $42 + $0.6255 + 2 × $68.09) = $7,845.718. It costs $6,029 more than GitHub in the low case and $14,336 more in the high case. Break even is never under these assumptions. A contractual reason may still justify it; saving money does not.

Fifteen developers with heavy CI: rent the workers first

Assume 200,000 standard Linux minutes monthly. GitHub compute is 200,000 × $0.006 − $18 = $1,182; 15 Team seats add $60. Retained B2 data is 1,000 GB, costing $6.8805 monthly. The private worker is one SYS-5 at the advertised $125 monthly plus $125 installation. Forgejo adds a separate $24 VPS; hybrid keeps the $60 GitHub seats.

Hybrid saves $29,756 low or $18,862 high, breaking even in month 2 or 4. Forgejo saves $25,605 low or $4,089 high against fully hosted CI, breaking even in month 2 or 17. Hybrid wins both labor cases because the assumed forge administration exceeds the seats removed.

This depends on capacity. Our illustration assumes matching completion times, jobs spread across the month and at most eight simultaneous two-core workers, with disposable VMs on the dedicated host. The workload represents about 6,667 allocated core-hours monthly. Sixteen allocated cores across our assumed 730-hour planning month supply 11,680 core-hours before overhead. That is a plausibility check, not a benchmark or queue guarantee. Compile speed, disk pressure and peak arrivals can invalidate it.

Keep a representative build on each platform before committing. At one tenth the assumed minutes, GitHub's usage bill shrinks while the operator still needs paying. The headcount is not the break-even switch; sustained useful work is.

Nightly AI jobs: GPU scheduling matters more than the forge

Assume five developers and 240 RTX 4090 GPU hours each month, including startup and retries. The GPU bill is 240 × $0.89 = $213.60; 100 GB network storage adds $7. RunPod container disk is separate at $0.10 per GB monthly while running. We reserve a conservative full $2 monthly for an assumed 20 GB; actual time-prorated disk charges would be lower. Both paths have a $24 controller VPS and 500 GB retained B2 data at $3.4055. Hybrid adds $20 GitHub seats; Forgejo adds its own $24 VPS. GPU jobs run reviewed private work, with ordinary hosted CPU checks inside the included credit.

Moving the forge costs $5,591 low or $11,038 high more. Break even is never. By contrast, leaving that GPU allocated for our full 730-hour month costs $649.70 in compute. Ending it after 240 hours avoids $436.10 monthly, or $15,700 over 36 months, before any changed storage or scheduling expense. The same saving is available with GitHub.

RunPod Pods are containers, not the disposable VMs used in the kit's general GPU runner recipe. Here the controller dispatches trusted inference into an approved Pod image. We do not assume nested Docker or VM isolation from a Pod. An always-needed GPU, a large private dataset or strict offline requirements would need a separate quote and design.

Protect the forge from the work it is asked to run

Treat a workflow as executable code. A pull request that changes a build script can ask the runner to read credentials or reach internal services. GitHub's security guidance warns that persistent self hosted runners can be compromised by untrusted work. Container cleanup alone does not restore a compromised host.

Use disposable workers separated from the forge, its database and the administrator's desktop. Restrict network reach as well as files. Never run untrusted pull request code on a persistent worker with secrets. Public contributions belong on an appropriately isolated service or disposable VM without privileged credentials. A Docker socket gives control over its daemon's host; it must never be the forge host's socket.

Agent jobs need the same boundary. The model routing playbook assigns deterministic work to ordinary code, bounded local tasks to local models, and difficult drafting or review to suitable hosted models. Give each job an owned checkout, branch, output and budget. A separate branch prevents accidental file collisions; it does not restrict operating-system access.

Use OpenSSF's concise guidance and Scorecard checks as a review list. Require protected branches and independent approval for sensitive changes; require passing checks before merge. Review changes to workflows and dependency locks especially carefully. Use signed commits where your policy requires attributable changes, while remembering that a signature cannot prove the code is safe.

Keep credentials in a secret store, scoped to a job and destination, with expiry and rotation. Prefer short-lived credentials where supported. Pin third-party actions and container images to reviewed immutable identities. Let Renovate or another supported updater propose changes, then test and review them. Generate an SBOM for releases and retain it beside the artifact and its provenance.

SLSA's build track, short for Supply-chain Levels for Software Artifacts, distinguishes provenance at Build L1, hosted generation with authenticated provenance at L2, and hardened builds at L3. A signed commit or an SBOM is not a SLSA level. Specify which builder properties you have actually established rather than announcing compliance because a pipeline turned green.

Require multifactor authentication through the forge or its SSO provider, and protect recovery accounts. Export meaningful audit events: membership changes, token creation, runner registration, protected-branch changes and release promotion. Check the chosen edition's audit features; reverse tunnel logs cannot replace forge events. Keep logs outside a worker's write permissions and omit secrets and sensitive prompts.

Our workstation security guide and operating guide supply the ongoing habits: bounded concurrency, progress records, deliberate updates and independent recovery. A practical starting policy is weekly routine review, prompt security triage and a monthly restore exercise. Those intervals are our recommendation; a serious advisory may require faster action. Follow the safe update procedure with a consistent backup and rollback plan before a database migration.

Two doors: private work and public reading

Cloudflare Tunnel connects outward from the origin, so this design needs no inbound application ports. Access supplies email or SSO authentication before requests reach the forge. Create the Access application and policies before publishing its route; also keep the forge's own authorization. The Access application guide describes connector or origin token validation.

Automation uses a scoped service token and Service Auth policy, plus whatever credential the forge itself requires. A normal Git client cannot fill out an interactive email form. Test clone, fetch, push, LFS and API calls through the chosen authentication path. Do not add a broad bypass merely to make the command line work.

The tradeoff is dependence on Cloudflare's identity and traffic path. This is not an air gap, and the hostname need not be secret. Zero Trust Free lists $0 with a 50 user limit; the cost examples stay inside that limit. Retain provider console or rescue access independent of the tunnel. Our Kasm subdomain guide explains why each application gets its own policy.

A second server can instead serve public documentation, releases or explicitly public repository mirrors directly over HTTPS. Push approved exports outward with a restricted credential. Give the public server no credential that can fetch private material or write back to the forge. Test absence of private branches, issue data, build logs and embedded secrets before publishing.

That server improves public availability during forge maintenance, but adds rent, patching, certificates and publication delay. It is a publishing endpoint, not automatic write failover. A Git mirror also does not preserve all forge metadata, LFS objects or historical deletions. A static export is often the smaller public surface. Neither option makes private backups suitable for publication.

┌─────────────┐    ┌─────────────────────────┐
│ Developer   │ →  │ Access: email or SSO    │
└─────────────┘    │ Tunnel: origin outbound │
                   └────────────┬────────────┘
                                ▼
                   ┌─────────────────────────┐
                   │ Private forge + database│
                   └────────────┬────────────┘
                                ▼
                   ┌─────────────────────────┐
                   │ Isolated job workers    │
                   │ CPU VMs     GPU jobs    │
                   └────────────┬────────────┘
                                ▼
                   ┌─────────────────────────┐
                   │ Artifacts + provenance  │
                   └─────┬──────────────┬────┘
                         ▼              ▼
               ┌────────────────┐  ┌──────────────────┐
               │ Private backups│  │ Approved public  │
               │ Forge + DB +   │  │ export or mirror │
               │ runner config  │  └─────────┬────────┘
               └────────┬───────┘            ▼
                        ▼          ┌──────────────────┐
               ┌────────────────┐ │ Read only server │
               │ Restore test   │ │ Public HTTPS     │
               │ Isolated host  │ └──────────────────┘
               └────────────────┘

The backup branch includes a consistent copy of forge state, database and runner configuration as well as artifacts; it is not just an artifact archive.

Back up enough to rebuild, then prove it

Use the 3 2 1 principle: three copies, on two kinds of storage, with one off site. RAID keeps a service running through some disk failures; it does not preserve yesterday's state after an authorized deletion. A public mirror is also no substitute for independent retained history.

Back up repositories, the matching database, attachments, LFS and package objects, application configuration and the recipe for rebuilding runners. Preserve recovery secrets through a separately protected process. Stop writes for a coherent small-system backup, or use a documented consistency procedure. A database dump taken at one time and repository files copied during later changes can disagree.

The kit uses encrypted restic backups to B2. Restic's copying guidance supports independent repositories; a sync that reproduces deletion is a different operation. Restrict backup credentials and arrange independently controlled retention. Test restores into a clean isolated system before relying on them.

Write your recovery point objective, the amount of recent work you can lose, and recovery time objective, how long you can wait. Our suggested monthly exercise restores a selected snapshot, verifies repository history and database records, retrieves an LFS object and runs a harmless build. Record elapsed time and compare it with the objective. An exit code from the backup command answers a smaller question.

The Windows and Drive backup guide offers another storage path if you already have suitable capacity. Its lessons about encryption, independent account recovery and tested restoration apply equally here. In Franklin's terms, ownership becomes useful when the collection remains usable by the next person who opens the door.

Download the kit

Download the sovereign Git server kit. Start with its decision checklist, then implement a disposable pilot and complete the restore exercise before moving important repositories. The commands were checked against documentation; we did not deploy a forge or prove a live migration for this article.

For readers turning this workshop into a small service business, The $20 Dollar Agency connects the tools to a defined piece of work someone can buy. Keep the operating responsibility in that definition.

Related reading

The foundation articles and their companions were reviewed November 1, 2026. Their earlier measurements retain their original dates and limits.

Fact-check notes and sources

All sources below were read November 1, 2026, at the UTC times shown, except the explicitly dated labor inputs. Prices are published list rates with the billing terms stated above. They are not reserved inventory or an installation test. Related reading and its downloads supply the earlier operating practices; their measurements have not been relabeled as new tests.

• Historical texts: Franklin's Autobiography, 21:16; CTSS Programmer's Guide, May 1963, opening pages, 21:17.
• GitHub seats and compute: Plans, Actions billing, runner rates and updated fee announcement, 21:16. Current billing documentation takes precedence over older minute summaries.
• GitHub storage: Packages, LFS, 21:16; metered price calculator, 21:17. Actions uses binary GB, equivalent to GiB; B2 prices here use decimal GB.
• Hosted alternative: GitLab pricing, 21:16. Paid plan annual billing differs from the monthly server budgets.
• Forge sizing and workers: Forgejo installation, Gitea requirements, GitLab requirements, Forgejo Runner, 21:16; Gitea Runner, GitLab Runner, GitHub self hosted workers, 21:22.
• CPU rental: DigitalOcean, 21:16 and 21:18; US Kimsufi, Rise, 21:16; US Eco catalog, 21:17. OVH final order commitments remain unverified; no cart was submitted.
• Public hosting and GPU rental: Vercel pricing, Pro terms, RunPod GPU and storage prices, 21:16; Pod disk billing, 21:22; Pod storage types, 21:22.
• Labor and backup prices: BLS administrator profile, October 29, 21:12; BLS wage share, October 29, 21:17; B2 pricing, November 1, 21:16. Hours, workload volumes and retention sizes are our assumptions.
• Build security: OpenSSF guide, Scorecard controls, SLSA build track, 21:17; GitHub secure use, 21:16. Scorecard principles are adapted here; no claim that every check runs unchanged on Forgejo.
• Private access: Tunnel, 21:16; service credentials, 21:17; Access application validation, 21:22; Free plan limit, 21:23.
• Recovery: 3 2 1 explanation, 21:22; restic independent repositories, 21:17 and 21:24. The kit cites the database, runner, tunnel and restore commands individually.

This post is informational, not financial, legal or technical consulting advice. Product names identify the services discussed; no affiliation or endorsement is implied.