How it's protected and built
Two machines in a house, free and open-source software and a near-zero budget, run like a small company. Below: how the network is protected, and how software gets built.
A home lab built like a small company
Everything on this site, and the apps behind it, runs on two machines in my house, on free and open-source software, on a near-zero budget. This section explains how it is protected. Not to claim it cannot be broken (nothing can), but to show how far careful layering gets you without buying a single licence.
The principle: defence in depth. No layer is trusted to stop everything. Each one assumes the layer in front of it has already failed.
Security in layers
Every layer assumes the one in front of it failed
Tap a ring. The outer rings are what the internet meets first, and the centre is what is left after them: someone physically inside the house.
Read all eight layers in detail
1. The front door: almost nothing is open
- The router forwards only what the public services need: the website, mail, live streaming and game voice.
- Checked by outside scan on 2026-10-13.
- Every web app sits behind one reverse proxy (Nginx Proxy Manager). Apps never publish their own ports to the internet.
- HTTPS everywhere, with certificates renewed automatically; plain HTTP is redirected.
2. Admin tools are invisible from the internet
- Management panels (containers, databases, DNS, downloads, dashboards, the proxy itself, the VPN server and the identity admin console) answer only to the home network and the VPN. From anywhere else they refuse the connection, each one tested from outside.
- Being on the right network is not enough on its own: where a panel has single sign-on, both checks must pass, the right network and the right identity. Two keys, not one.
- The VPN's own admin side is not reachable on the home network at all, only through the proxy and single sign-on.
- Every rule was tested from three places: the open internet, the home network and a real VPN tunnel.
- Public sign-in pages for the apps stay reachable, so locking the admin side never locks users out.
3. One identity, checked properly
- Sign-in runs through Keycloak (single sign-on with OpenID Connect) for 20+ apps: one account, one place to set password rules. Two-factor authentication is required for every password sign-in, and repeated failed sign-ins lock the account for a while.
- Tools that have no login of their own sit behind an authenticating proxy (oauth2-proxy), so they are never open by accident.
- Registration is closed where it is not needed; new accounts are created on purpose.
4. Remote access through an encrypted tunnel
- Remote access runs only through a self-hosted zero-trust mesh (NetBird), never through open ports.
- Signing in to the mesh goes through the same single sign-on, so there is one account and one place to revoke access.
- Access is per group and denied by default: friends reach game streaming and nothing else; only admins reach internal systems; devices can't see each other unless a policy allows it.
- Tested with two devices: the admin one reached the internal systems, the other reached none.
- The mesh's setup page stayed invisible from the internet until the first administrator existed.
5. DNS that blocks the bad stuff
- AdGuard Home blocks ads, trackers and known malicious domains before a connection is made, at home.
- Its own lookups are encrypted, validated (DNSSEC) and sent to two independent resolvers.
6. Privacy where it matters
- Download and media-fetching traffic leaves through a VPN container with a kill switch: if the tunnel drops, that traffic stops instead of leaking.
7. Every service in its own box
- Each app runs in its own container on its own internal network. A problem in one app does not hand over the others.
- Secrets live in environment files and a self-hosted password manager (Passbolt), never in code.
- The mail server bans IPs that keep guessing passwords (fail2ban).
8. Watching and recovering
- All network addresses live in one settings file, so a new router or a move means editing one file.
- A watcher keeps an eye on the home internet address, asks several independent sources and acts only when they agree. If the provider changes it, the access rules update themselves and I get one short mail.
- Every change is backed up first and can be undone one service at a time.
- Alerts for runaway CPU, disk health and failed jobs go straight to my inbox.
- Dependency updates are proposed automatically every week and reviewed before they land.
- Daily database dumps plus encrypted, versioned backups (restic) on separate disks, all kept in-house, with a weekly integrity check of the backup data.
The honest part
After all this, the easiest way in is no longer through the internet. It is walking into my house and plugging into the network. That is the point: the remaining risk is physical, and physical risk is handled by locks, not software.
That is not "impenetrable". Software has bugs, people reuse passwords, and new vulnerabilities appear every week. What layering buys you is that one mistake is not enough. An attacker needs several things to go wrong at once, and every layer is a chance to notice.
What you can take from this: none of it needs an enterprise budget. A reverse proxy, single sign-on with two-factor, a zero-trust mesh instead of open ports, DNS filtering, isolated containers and regular backups will protect a home or a small company far better than most paid setups that skip the basics.
A one-person team that works like an enterprise
Big companies split software work across roles: product, architecture, development, QA, security, operations. Here the same roles exist, filled by a mix of local AI models, a frontier AI assistant and me. Everything runs on my own hardware with free and open-source tools. The AI does the volume; a human can take over any role at any moment.
The principle: every change earns its way to production. Nothing ships because someone (or something) says it works, and nothing reaches production without passing the same gate. It ships because tests, linters, scanners and a review all agree.
The pipeline and who steps in
Every change earns its way to production
Watch a change travel through the pipeline. Pick a role to see where a person takes over. AI does the volume, and anyone can step in at any stage.
Every stage in detail
| Stage | What happens | Default | Where a human steps in |
|---|---|---|---|
| 1. Plan | A task is written with goal, steps and "done when". Never a title-only ticket. | AI planner, from a written roadmap | Planner: set priorities, reorder the queue, reject a task |
| 2. Design | Work is split into small units, each one function or file, small enough for a local model to get right. | AI architect | Architect: change the design, the split or the interfaces |
| 3. Tests first | Checks and tests for each unit are written before the code. | AI, reviewed against the spec | QA: add or tighten tests |
| 4. Code | Local models on my own GPUs draft each unit. Failed drafts get their own errors back and try again. | Local AI coder | Developer: write or fix any unit by hand |
| 5. Learn | Every correction becomes a written lesson, and the exact situation is saved so it can be replayed when the models improve. | AI, logged automatically | Mentor: review the lessons, decide what becomes a rule |
| 6. Review | Each change opens a pull request. An AI reviewer comments on it; every finding is checked and either fixed or explained. | AI reviewer + triage | Reviewer: approve, request changes, overrule a finding |
| 7. Verify | CI runs builds, unit tests, browser tests in light and dark at phone width, linting across languages and security scanning. Lint is fixed for real, never suppressed. | Self-hosted CI | Debugger: pick up any red job |
| 8. Merge | Only changes where every check and the review gate are green merge; branch protection enforces it. | Automatic when fully green; anything not fully green waits for me | Release manager: hold a merge, or decide the ones that aren't green |
| 9. Deploy | A clean build from the main branch only, then deploy. | Automatic after a green merge | Ops: hold or roll back |
| 10. Measure | Every task reports lines written by local AI vs. corrected, tokens used locally vs. in the cloud, retries and lessons. | AI, published as a report | Manager: read the numbers, steer the models |
Measured, not claimed
How much the local AI really writes
Every task reports what the local models drafted, what survived review and what the cloud AI had to write itself.
Measured 2026-10-12
Enterprise vs. here
The same jobs, without the licences
Tap a card to flip it from the usual paid tool to the self-hosted, open-source one used here.
The full tool list
| Enterprise | Here | Why |
|---|---|---|
| GitHub Enterprise / GitLab | Forgejo | Own Git server, mirrored publicly for open-source projects |
| Jenkins / GitHub Actions | Forgejo Actions with self-hosted runners | Builds run on my own machines; heavy jobs go to the free GPU machine |
| SonarQube | MegaLinter | Dozens of linters in one gate, no licence server |
| Code review bots (paid) | PR-Agent, backed by AI | Every pull request gets a written review before a human looks |
| Snyk / Dependabot | Renovate + Trivy | Weekly dependency updates and vulnerability scans, all reviewed |
| Copilot-style coding assistant | Local models on my own GPUs, served by OpenVINO Model Server and Ollama | Code drafts never leave the house; the cloud AI plans and reviews |
| Cypress Cloud / BrowserStack | Playwright in a container | Real browser tests on every change |
| Okta / Azure AD | Keycloak | One login for the whole stack (see the security section) |
| Datadog / PagerDuty | Small self-written watchers that send mail | Alerts when something runs hot, fails or stalls |
| Confluence + Jira | Written handoff docs, a skills library and my own planner app | Every rule and lesson written so a smaller model can follow it alone |
What makes it different
- The AI is a team, not a tool. Local models do the drafting, a stronger model plans and reviews, and every mistake makes the next run better.
- Nothing is trusted, everything is checked. The same gate applies to AI code and to mine.
- A human can step in anywhere. The pipeline does not need me to keep running, but it never stops me from taking over.
The honest part
AI did not build this for me. It accelerated what I had already learned over years: what a good pipeline looks like, which checks matter and where models go wrong. The rules the AI follows are mine, written from experience, and they keep growing every time it makes a mistake.