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.

How it is protected 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
      StageWhat happensDefaultWhere a human steps in
      1. PlanA task is written with goal, steps and "done when". Never a title-only ticket.AI planner, from a written roadmapPlanner: set priorities, reorder the queue, reject a task
      2. DesignWork is split into small units, each one function or file, small enough for a local model to get right.AI architectArchitect: change the design, the split or the interfaces
      3. Tests firstChecks and tests for each unit are written before the code.AI, reviewed against the specQA: add or tighten tests
      4. CodeLocal models on my own GPUs draft each unit. Failed drafts get their own errors back and try again.Local AI coderDeveloper: write or fix any unit by hand
      5. LearnEvery correction becomes a written lesson, and the exact situation is saved so it can be replayed when the models improve.AI, logged automaticallyMentor: review the lessons, decide what becomes a rule
      6. ReviewEach change opens a pull request. An AI reviewer comments on it; every finding is checked and either fixed or explained.AI reviewer + triageReviewer: approve, request changes, overrule a finding
      7. VerifyCI 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 CIDebugger: pick up any red job
      8. MergeOnly 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 meRelease manager: hold a merge, or decide the ones that aren't green
      9. DeployA clean build from the main branch only, then deploy.Automatic after a green mergeOps: hold or roll back
      10. MeasureEvery task reports lines written by local AI vs. corrected, tokens used locally vs. in the cloud, retries and lessons.AI, published as a reportManager: 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.

      79% of new lines kept from local drafts
      8 / 12 units passed on the first draft
      17 local drafts, all on my own GPU
      40 lines the cloud AI wrote itself
      Before the loop was fixed 5%
      Latest task (form redesign) 79%

      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
      EnterpriseHereWhy
      GitHub Enterprise / GitLabForgejoOwn Git server, mirrored publicly for open-source projects
      Jenkins / GitHub ActionsForgejo Actions with self-hosted runnersBuilds run on my own machines; heavy jobs go to the free GPU machine
      SonarQubeMegaLinterDozens of linters in one gate, no licence server
      Code review bots (paid)PR-Agent, backed by AIEvery pull request gets a written review before a human looks
      Snyk / DependabotRenovate + TrivyWeekly dependency updates and vulnerability scans, all reviewed
      Copilot-style coding assistantLocal models on my own GPUs, served by OpenVINO Model Server and OllamaCode drafts never leave the house; the cloud AI plans and reviews
      Cypress Cloud / BrowserStackPlaywright in a containerReal browser tests on every change
      Okta / Azure ADKeycloakOne login for the whole stack (see the security section)
      Datadog / PagerDutySmall self-written watchers that send mailAlerts when something runs hot, fails or stalls
      Confluence + JiraWritten handoff docs, a skills library and my own planner appEvery 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.