NetBird Reviews

Our main use case for NetBird is to provide secure, lightweight, and high-performance remote connectivity while reducing our dependency on traditional VPN solutions.

Previously, we were using traditional SSL and IPsec VPNs for remote access. We found that these VPN connections could consume significant bandwidth and sometimes negatively impact internet speed and overall user experience, particularly when users were working over slower internet connections or mobile hotspots. We were looking for a solution that could provide secure access to internal resources without introducing the same level of performance overhead.

NetBird addressed this requirement by providing seamless and secure connectivity between users, servers, and internal infrastructure. It allows me to access required machines and services from different locations while maintaining controlled access through policies. We can define one-way, one-to-one, or two-way communication depending on the requirement, which gives us better control over which systems can communicate with each other.

Another important use case we discovered was automation testing. We were using Jenkins for testing automation of our product applications, and we identified an opportunity to improve the performance and efficiency of this workflow by combining NetBird with Docker.

We deployed automated Docker containers that connect to NetBird as peers. When a testing container starts, it establishes the required NetBird connectivity and can securely communicate with the machines hosting services such as PostgreSQL and Grafana. The automation runs the required test cases, sends the results, and once the job is completed, the container and its associated environment can be automatically destroyed.

This has significantly reduced manual intervention and simplified our testing workflow. The complete process is essentially automated from start to finish: the container starts, establishes secure connectivity through NetBird, performs the required testing, publishes the results, and is then removed.

For my day-to-day IT operations, NetBird has also made remote infrastructure management easier. Instead of repeatedly connecting to traditional VPNs whenever I need to access internal systems, I can maintain secure connectivity to the required machines. This is particularly useful when working from locations with limited connectivity, such as a mobile hotspot.

Overall, our primary NetBird use cases are secure remote access, replacing or reducing traditional VPN dependency, automated infrastructure connectivity, Docker-based testing automation, and controlled communication between systems. The combination of security, simplicity, performance, and automation has made NetBird a valuable part of our infrastructure.

NetBird has had a significant positive impact on our organization by improving secure network access, infrastructure management, automation, and operational efficiency.

One of the key benefits has been its integration with our Ansible automation environment. We use NetBird to provide secure connectivity between managed devices and our centralized Ansible server. Devices that are connected to the Ansible environment can be managed and patched centrally, which reduces the need for manual intervention and gives us better visibility and control over the patching process.

NetBird has also been particularly valuable for accessing backend systems that do not have public network interfaces. Instead of exposing these machines directly to the internet, we can establish secure peer-to-peer connectivity through NetBird and access the systems when required. For example, I can securely connect to a backend machine using SSH, perform the required administrative or troubleshooting tasks, and disconnect when the work is completed. This allows us to keep critical infrastructure isolated from public access while still maintaining operational accessibility.

Another major benefit is the ability to manage infrastructure distributed across different locations and cloud environments. As an IT administrator, I need to access machines hosted across Azure, AWS, and other environments, including systems that support critical application and database services. Many of these systems do not have public interfaces, so NetBird provides a secure way to reach them without exposing them externally.

We have also integrated NetBird into our testing and monitoring workflows. The connectivity between our systems allows us to collect and centralize operational metrics and display them through Grafana, giving us better visibility into the health of our infrastructure while keeping the underlying machines protected from direct internet exposure.

Overall, NetBird has improved our security, operational efficiency, remote infrastructure management, and automation capabilities. It has reduced the time required to access and manage distributed systems, minimized the need to expose internal machines publicly, and provided a seamless way to connect infrastructure regardless of its physical or cloud location.

For our organization, NetBird has become an important part of our day-to-day infrastructure operations because it allows us to maintain secure connectivity while keeping our environment simple, automated, and easier to manage.

The features that stand out most to me in NetBird are SSO integration, flexible logging, peer-based connectivity, access policies, and reverse proxy capabilities. These features make NetBird flexible and easy to integrate into an existing IT and security environment.

SSO Integration

SSO is one of the most valuable features for us, particularly as our organization continues to grow. We can integrate NetBird with our existing identity provider so that users can authenticate using their existing corporate credentials.

This makes it much easier to provide secure access to on-premises servers and resources. Users can authenticate through SSO and establish connectivity without having to manage separate credentials. It also provides centralized control over who can access specific resources.

Another feature I find useful is that we do not necessarily need to install a NetBird peer on every individual device. Depending on the network design, a single NetBird peer can provide access to multiple resources on an internal network. We can then use NetBird policies to control which users or peers are allowed to access specific systems. This makes the deployment simpler while still maintaining granular access control.

Logging and Integration

I also like the flexibility around logging. NetBird logs can be integrated with a syslog server and then forwarded to our existing security monitoring infrastructure, including EDR, XDR, or MDR platforms.

This is useful because organizations can integrate NetBird into their existing security-monitoring and SIEM workflows rather than having to rely exclusively on a separate logging platform. The flexibility of the self-hosted deployment also gives us greater control over how we collect, store, and process these logs.

Reverse Proxy

The reverse proxy capability is another feature I find particularly useful. When we need to make an internal service accessible externally, NetBird can provide a simpler way to expose the required service over HTTP or HTTPS without having to build a completely separate infrastructure stack.

For certain use cases, this can reduce the need to provision additional cloud infrastructure, such as an Azure or AWS VM, or manage additional components simply to make an internal service accessible. It can also simplify the configuration and management of certificates and external access.

Overall

What I like most about NetBird is its flexibility and simplicity. It provides secure connectivity while still giving administrators control over authentication, access policies, logging, network connectivity, and service exposure.

For our environment, the combination of SSO, centralized access control, peer connectivity, logging integration, self-hosting, and reverse proxy capabilities makes NetBird a very useful solution for both day-to-day infrastructure management and secure remote access.

Azure/Entra ID Group-Based Access

One feature I would like to see is deeper integration with Microsoft Entra ID groups. Ideally, administrators should be able to map Entra ID groups directly to NetBird access policies so that users who are added to a specific corporate group automatically receive the appropriate NetBird access.

This would make user onboarding and offboarding much easier because access could be managed centrally through existing identity-management processes rather than requiring additional manual configuration in NetBird.

Direct EDR/XDR/MDR Integration

Another improvement would be more direct integration with security platforms such as CrowdStrike, Microsoft security solutions, XDR, or MDR platforms for self-hosted deployments.

Currently, for our self-hosted environment, we can collect NetBird logs through a separate logging or syslog server and then forward them to our security-monitoring platforms. This works, but having a more direct integration with EDR/XDR/MDR platforms would simplify the architecture and reduce the additional infrastructure required for log collection and forwarding.

Just-in-Time Access

I would also like to see a just-in-time (JIT) access capability. For example, we could integrate NetBird with a ticketing or ITSM platform such as Jira or ServiceNow and create a temporary access policy for a specific machine.

An administrator could request access to a particular server, receive approval, and then automatically receive access for a defined period—for example, 10 minutes. Once the period expires, the access would automatically be revoked.

This would strengthen our zero-trust approach by ensuring that privileged access is provided only when required and for the minimum necessary duration.

Self-Hosted High Availability and Backup

For organizations running NetBird in a self-hosted environment, enhanced database backup, high availability (HA), and disaster-recovery capabilities would also be valuable. These features would provide additional resilience for organizations that depend heavily on NetBird for production connectivity.

Overall

There is no major issue with the current product from my perspective. The self-hosted version already provides a strong and flexible foundation. My recommendations are mainly focused on making enterprise integrations and security workflows more seamless.

The features I would prioritize are Entra ID group-based access, direct EDR/XDR/MDR integrations, just-in-time access with automatic expiration, and improved HA/backup capabilities for self-hosted deployments.

These enhancements would make NetBird even stronger for organizations that are building a mature zero-trust and infrastructure-access strategy.

I have been using NetBird for approximately one and a half years, primarily in a self-hosted deployment.

We implemented NetBird as part of our approach to provide secure remote access and connectivity to our internal infrastructure without relying entirely on traditional VPN solutions. The self-hosted setup gives us greater control over the management environment and allows us to integrate it with our existing infrastructure and security requirements.

During this period, we have used NetBird for secure connectivity between remote users, servers, and internal resources. It has also helped us simplify remote infrastructure management and support automation and administrative activities across our environment.

One of the key benefits we have seen over this period is the ability to maintain secure, persistent connectivity while keeping access centralized and manageable. The experience over the last one and a half years has been positive, and NetBird has become a useful component of our remote-access and infrastructure-management strategy.

Yes, based on my experience, NetBird has been stable and reliable in our environment. We have been using the self-hosted deployment for around one and a half years, and it has performed consistently for our remote-access and infrastructure-management requirements.

The peer connectivity has been reliable for day-to-day operations, including accessing servers and internal resources across different cloud and network environments. We also use NetBird as part of our automation and testing workflows, where Docker-based workloads establish connectivity, perform their tasks, and are then automatically removed. This has been running reliably without requiring continuous manual intervention.

One aspect I particularly appreciate is that established peer-to-peer communication does not depend entirely on the management server being continuously available. The management server is primarily responsible for managing and coordinating the environment, while authenticated peers can continue communicating with each other.

The main consideration from a stability and availability perspective is the self-hosted management infrastructure. Our current deployment uses a single server, so the management component itself does not have built-in redundancy in our setup. If the management server fails, this could affect management and new peer connections even though already-established peer connectivity can continue. For a production environment requiring higher availability, I would recommend designing the underlying infrastructure with appropriate backup and HA capabilities.

Overall, based on our experience, NetBird has been stable for our use cases and has provided reliable connectivity without the performance issues we experienced with our traditional VPN setup.

From my experience, NetBird is highly scalable from a user and device connectivity perspective, particularly with the self-hosted deployment.

With our current self-hosted setup, we can add additional machines and users without having to provision a separate NetBird server for every device. Users can authenticate through SSO, and we can apply appropriate access policies to control which resources they can access. This makes it easy to expand NetBird across additional users, machines, and environments without significantly increasing operational complexity or licensing costs.

The main scalability consideration with our current setup is the NetBird management server itself. We currently use a single self-hosted server, so high availability and server-level redundancy would require additional architecture or moving to an enterprise offering with the appropriate HA capabilities. Therefore, the scalability of the management infrastructure depends largely on how the organization designs and provisions the underlying environment.

For example, an organization could deploy the NetBird management components on appropriately sized cloud infrastructure and design the surrounding infrastructure for redundancy as the environment grows. The actual scalability will therefore depend on the resources allocated to the self-hosted deployment and the organization's availability requirements.

Overall, I would say NetBird is very scalable for adding users, machines, and network resources, while the main consideration for self-hosted deployments is planning the management-server architecture if high availability and redundancy are required.

Since we are using the self-hosted version of NetBird, we have not needed to rely on customer support or professional services so far.

I handled the deployment and configuration internally and am familiar with the components involved, including the Docker Compose configuration, Traefik configuration, and NetBird dashboard and management components. Because of this, I have been able to troubleshoot and manage the environment independently without requiring external technical support.

So far, we have not encountered an issue that required us to open a support case with NetBird. The available documentation has been sufficient for our deployment, upgrades, configuration, and troubleshooting requirements.

For our particular self-hosted use case, the ability to manage the underlying components ourselves is actually an advantage because it gives us full control over the environment and allows us to troubleshoot issues directly.

Before NetBird, we primarily used a traditional VPN solution based on our FortiGate firewall, using both SSL VPN and IPsec VPN for remote access.

While the traditional VPN setup provided secure connectivity, we found that it could have a noticeable impact on internet performance. With the traditional VPN architecture, traffic was often routed through the VPN/firewall infrastructure, which could introduce additional latency and bandwidth overhead. This was particularly noticeable for users working with slower internet connections or mobile hotspots, where download and upload performance could be significantly affected.

As our requirement for secure remote access increased, we were looking for a solution that could provide secure connectivity while offering better performance, simpler management, and a more flexible architecture.

We switched to NetBird because it provides a lightweight and easy-to-manage approach to secure connectivity using WireGuard-based encrypted networking. It allows us to establish secure connectivity between required peers without relying on the same centralized VPN architecture for every connection.

The result has been a better remote-access experience for our users and IT administrators, particularly when working across geographically distributed infrastructure. NetBird has also made it easier to manage secure access policies and connect to internal resources without unnecessarily exposing them to the public internet.

Overall, the main reasons for switching were better performance, simpler management, secure WireGuard-based connectivity, and greater flexibility for accessing distributed infrastructure.

The initial setup of NetBird was straightforward and relatively easy, especially with the self-hosted deployment. I did not find the implementation overly complex, and the documentation provided clear guidance throughout the setup process.

I initially tested NetBird on a local machine to validate the functionality before moving the deployment to our AWS infrastructure. The setup mainly involved installing Docker, following the NetBird installation instructions, configuring our domain and DNS records, setting up the required SSL/Let's Encrypt certificate, and configuring authentication through SSO.

Once the initial configuration was completed, adding peers and connecting machines was simple. The management interface also makes it easy to configure access policies and control which users or machines can communicate with specific resources.

The upgrade process has also been straightforward in our self-hosted environment. We can follow the documented upgrade procedure without requiring significant changes to the existing deployment.

Overall, I would describe the initial setup as simple, well documented, and easy to manage, particularly for an IT administrator who is comfortable with Docker, DNS, and basic cloud infrastructure.

No. We did not use an external integrator, reseller, or consultant for the deployment.

I handled the NetBird deployment and configuration internally using the documentation provided by NetBird. We initially tested the self-hosted deployment on a local machine and, after validating the setup, deployed it on our AWS infrastructure.

Because the self-hosted installation was straightforward and well documented, we did not require external professional services or consulting assistance. This also helped us keep the implementation costs low and gave us complete control over the configuration and ongoing management.

Yes, we have seen a positive return on investment from NetBird, particularly in terms of time savings, operational efficiency, and reduced infrastructure costs.

The biggest benefit for us is that we are using the self-hosted version, so we do not have a significant per-user licensing cost. Our main expense is the cloud infrastructure used to host the NetBird management server. This makes the overall solution very cost-effective compared with traditional VPN infrastructure and commercial per-user VPN solutions.

The initial implementation was also straightforward. I was able to deploy NetBird by following the documentation, configure the required domain and certificates, and integrate it with our environment without a lengthy implementation project. This reduced the amount of time and effort required to introduce the solution.

We have also saved significant operational time by simplifying remote access to infrastructure. Instead of repeatedly configuring or connecting through traditional SSL/IPsec VPNs, I can use NetBird to securely access machines across our cloud and on-premises environments.

Another area where we see ROI is automation. We use NetBird connectivity with our Docker-based testing and Ansible automation workflows. This allows systems to establish the required secure connectivity automatically, perform their tasks, publish results, and then be removed without requiring manual intervention.

The benefits are therefore not limited to licensing savings. We have gained faster implementation, reduced administrative effort, simpler remote access, better automation, and lower ongoing VPN infrastructure costs.

Overall, while we have not calculated a specific dollar-based ROI, the combination of the low cost of our self-hosted deployment and the amount of time and operational effort saved makes NetBird a cost-effective solution for our organization.

My experience with NetBird's pricing and setup has been very positive, particularly because we are using the self-hosted version.

We did not purchase NetBird through the AWS Marketplace or another third-party marketplace. Instead, we deployed the self-hosted version ourselves on our AWS infrastructure.

The initial setup cost was straightforward. I followed the installation instructions provided in the NetBird documentation, installed Docker, and followed the setup process step by step. The main requirements were configuring our domain, setting up the required DNS records and Let's Encrypt certificate, and configuring the email address. Once these prerequisites were in place, the installation was relatively simple.

From a licensing perspective, the self-hosted deployment is very cost-effective for our use case. We do not have a per-user licensing cost for the self-hosted deployment, so we can add users and machines without the same licensing concerns associated with a per-user commercial plan. Our primary ongoing cost is the AWS infrastructure used to host the NetBird environment.

NetBird also offers commercial/business plans for organizations that require additional managed or enterprise capabilities. However, for our requirements, the self-hosted deployment provides the flexibility and functionality we need while keeping the overall cost low.

Overall, I find the self-hosted pricing model, simple deployment process, and absence of per-user licensing costs to be significant advantages for organizations that have the technical capability to manage their own infrastructure.

I did not formally evaluate or compare multiple solutions before choosing NetBird. I initially came across NetBird while researching secure remote-access and VPN alternatives online. I reviewed the available documentation and wanted to validate whether it would fit our environment before making any implementation decision.

I first deployed NetBird on a local test machine to understand its functionality, configuration, connectivity, and overall usability. After successfully validating it in the test environment, I moved forward with deploying it on our AWS infrastructure.

The initial deployment was straightforward, and we have continued using NetBird since then. One of the things I particularly appreciate is that upgrades and ongoing management are relatively simple and manageable in the self-hosted environment.

So, rather than selecting NetBird after a formal comparison with several competing products, our decision was based on hands-on testing and validation. The product met our requirements during the proof-of-concept, so we proceeded with it for our production use case.

Based on my experience with the self-hosted deployment, I would rate NetBird 9 out of 10 overall.

The main reasons for the high rating are its secure WireGuard-based networking, simple deployment, SSO integration, flexible access policies, and low operational cost. We have deployed NetBird in our public cloud environment and have been using it for secure connectivity across our infrastructure.

One feature I particularly appreciate is the resilience of the peer-to-peer networking model. Once peers are authenticated and connected, they can continue communicating even if the central management component becomes temporarily unavailable. This provides an additional level of reliability because the ongoing connectivity between established peers does not depend entirely on the management server being continuously available.

NetBird also provides policy and posture-management capabilities that help us control which users, machines, and services can communicate with each other. I do not currently make extensive use of the AI capabilities; most of our policies are created and managed based on our own requirements and operational experience.

For organizations considering NetBird, particularly small and mid-sized organizations, I would recommend evaluating the self-hosted deployment. It is relatively easy to deploy and maintain, supports SSO, provides secure WireGuard-based connectivity, and can significantly reduce the infrastructure and licensing costs associated with traditional VPN solutions.

The self-hosted model is especially attractive if an organization has the technical capability to manage its own infrastructure. You can host NetBird in your own cloud or on-premises environment and scale the number of users and machines without the same per-user licensing concerns.

Overall, NetBird has provided us with a secure, reliable, lightweight, and cost-effective alternative to traditional VPN infrastructure, which is why I would rate it 9/10 and recommend it to organizations looking for a modern approach to secure remote access.