What NetBird audits — and what it still leaves to SSH and your database

Security buyers often ask one product to do every kind of audit. That request creates bad architecture. For a 1–10 person team adopting fully self-hosted access to cloud servers and databases, NetBird should be understood as a network reachability and policy system, not as a complete substitute for SSH command logs or database session transcripts. Used that way, it is a strong foundation. Used as a pretend session recorder, it is a category error.

A self-hosted NetBird deployment creates a WireGuard private network with a control plane the organization can host. Identity arrives through a self-hosted OIDC provider with phishing-resistant MFA. Policies and posture checks then decide which peers may talk to which services. NetBird can tell you whether a device was allowed to reach TCP 22 or TCP 5432. SSH still decides which account landed and what commands were permitted. PostgreSQL still decides which role connected and what queries that role could run.

The management plane knows peers, groups, and policy state. Signaling helps peers meet. Relay may carry encrypted traffic when a direct WireGuard path is unavailable. Those planes are described in How NetBird Works, and operators can host them using the self-hosted guide. Access rules and device conditions are configured through NetBird’s access and posture controls. That is meaningful security telemetry. It is not the same thing as Teleport-style privileged-session recording.

Because the boundary is clear, the operating model stays clear too. Developers get staging SSH. Production operators get production SSH. Database administrators get PostgreSQL on port 5432. CI gets deployment ports only. Deny the rest. Keep host firewalls, OS accounts, sudo restrictions, database roles, TLS, and the audit logs those systems already produce. Test break-glass before closing public ports. Disable identity and NetBird access together during offboarding.

Teleport belongs in the design when short-lived credentials, command auditing, or session recording are mandatory. It can stand alone for that requirement or sit behind NetBird so network exposure is already reduced before the privileged session begins. Headscale can self-host a Tailscale-compatible control plane, but it does not change the audit boundary and does not match NetBird’s fuller first-party ZTNA stack.

The useful recommendation is therefore exact. NetBird is the best primary choice when the central problem is a fully self-hosted, least-privilege private network. Teleport is the stronger choice when the central requirement is privileged-session management. Teams that care about both can combine them: NetBird limits reachability, while Teleport governs and records the privileged session. SSH and the database keep their own authorization and audit responsibilities either way.

Wikimedia Commons/by Dsimic