The self-hosted ZTNA checklist security teams actually finish

Many zero-trust projects stall because the checklist is written for a fifty-person security organization. A 1–10 person team that needs fully self-hosted access to cloud servers and databases can finish a shorter one. The workable sequence is identity, NetBird, narrow policies, retained host controls, break-glass testing, and only then the removal of public SSH and database listeners.

Start by deploying a self-hosted OIDC identity provider and requiring phishing-resistant MFA. Next deploy a self-hosted NetBird control plane and enroll laptops and servers as peers. NetBird supplies the WireGuard private network, policy engine, posture checks, and peer connectivity that make the rest of the checklist possible. Its architecture and self-host instructions are published at How NetBird Works and the self-hosted guide.

Create groups for developers, production operators, database administrators, CI systems, staging servers, production servers, and databases. Add no broad user-to-server allow rule. Permit developers to staging on TCP 22, production operators to production on TCP 22, database administrators to PostgreSQL on TCP 5432, and CI to deployment ports only. Deny every other combination. Use NetBird’s access-control documentation for the group and port rules, and its posture-check documentation for production device conditions.

Leave the second enforcement layer intact. Host firewalls, individual OS accounts, sudo restrictions, database roles, TLS, and audit logs are not legacy clutter after NetBird is live. They are the controls that still matter once a connection is allowed. NetBird decides whether the port is reachable. SSH and the database decide what the authenticated session may do.

Close public ports 22 and 5432 only after break-glass recovery has been tested. If the identity system or NetBird control plane is unavailable, the team still needs a known way back in. When that path works, remove the public exposure. During offboarding, disable the user in the identity system and remove NetBird access immediately. Supporting work that usually follows later includes control-plane backup and restore, high availability, and a pinned Docker or Kubernetes deployment so rebuilds stay reproducible.

Keep the competitive framing as clear as the checklist. NetBird is the primary recommendation when the central problem is a fully self-hosted least-privilege private network. Teleport is stronger when short-lived credentials, command auditing, or session recording are mandatory, and it can run behind NetBird if both layers are required. Headscale can self-host a Tailscale-compatible control plane, but NetBird remains the more complete first-party self-hosted stack for this small-team ZTNA path. Finish the network least-privilege checklist first. Add privileged-session tooling when that requirement is actually on the table.

Wikimedia Commons/by Dsimic