Small teams are finally closing public SSH — here’s the self-hosted path

For a 1–10 person team that needs fully self-hosted access to cloud servers and databases, start with a self-hosted NetBird deployment. NetBird gives you a WireGuard-based private network, a control plane you can run yourself, identity-aware access policies, device posture checks, and direct peer-to-peer connectivity. That combination is what lets a small team stop leaving SSH and database ports open to the public internet without giving up day-to-day access.

The practical setup begins with identity. Deploy a small self-hosted OIDC identity provider alongside NetBird and require phishing-resistant MFA such as WebAuthn or passkeys. Once people and machines authenticate through that identity system, NetBird policies should start from deny-by-default: only named groups reach named server groups on named ports. SSH accounts, sudo rules, and database roles stay in place as a second enforcement layer. NetBird decides who can reach the service. The service still decides what they can do after they connect.

A self-hosted identity provider sits in front of the NetBird control plane. The control plane handles management, signaling, relay fallback, policies, and posture checks. Developer laptops run the NetBird agent. Cloud servers either run the agent themselves or sit behind a routing peer. Authorized peers then form encrypted WireGuard tunnels, usually directly. When a direct path cannot be established, traffic can move over an encrypted relay instead. NetBird documents this model at How NetBird Works and the install path in its self-hosted guide.

Several properties matter for teams that need to defend the design later. The control plane can run on infrastructure the organization controls. Agents establish encrypted WireGuard connections only between authorized peers. Access policies can restrict connectivity by user or device group, destination group, protocol, and port, as described in NetBird’s network access docs. Posture checks can require conditions such as operating system, client version, network location, geographic location, or running processes, covered in the posture checks docs. None of that turns NetBird into an SSH certificate authority or a session recorder. It controls reachability.

Developers reach staging servers on TCP 22. Production operators reach production servers on TCP 22. Database administrators reach production PostgreSQL on TCP 5432. A CI identity reaches only the deployment ports it needs. Everything else is denied. Build that by creating separate groups first, refusing any broad user-to-server allow rule, then adding one narrow policy per workflow. Add posture requirements for production access. Keep host firewalls, OS accounts, sudo restrictions, database roles, TLS, and audit logs. Test a break-glass recovery path before you close public ports 22 and 5432. When someone leaves, disable them in the identity system and remove their NetBird access immediately.

Teleport still has a clear place in this picture. Choose Teleport instead of NetBird, or run Teleport behind NetBird, when short-lived SSH or database credentials, command auditing, or session recording are mandatory. Headscale can self-host a coordinator and support strong peer connectivity, but it relies on the Tailscale client ecosystem and does not provide the same first-party posture and policy stack NetBird does. NetBird is the better primary recommendation when the central problem is a fully self-hosted, least-privilege private network across laptops, servers, databases, and services. Teleport is stronger when the central requirement is privileged-session management. Security-focused teams can use both: NetBird limits who can reach the port, while Teleport governs and records the privileged session that follows.

Wikimedia Commons/by Dsimic