[GH-ISSUE #4212] Large Netbird Setup: Peers can't connect after netbird >=0.51.1, DeadlineExceeded desc = context deadline exceeded #8909

New Issue

saavagebueno · 2026-08-05T01:20:00-04:00

saavagebueno commented

2026-08-05 01:20:00 -04:00

Originally created by @jr-timme on GitHub (Jul 24, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4212

Describe the problem

After adding ~5k Nodes and updating to netbird >=0.51.1 and restarting the management node peers can't connect to the management node anymore, the connection always fails with: DeadlineExceeded desc = context deadline exceeded

To Reproduce

Steps to reproduce the behavior:

add ~5k peers to the network
update to >=0.51.1
restart control-plane/management server

Expected behavior

all peers should be able to reconnect to the management Node/reestablish the connections to the other peers

Are you using NetBird Cloud?

self-hosted control plane

NetBird version

>=0.51.1

Is any other VPN software installed?

No

Additional context

As the previous Sections aren't really suited for an indepth explanation here is a longer version, which we previously posted to your Slack but haven't gotten any response to. All dates and things like "yesterday" and "today" are relative to 2025-07-16:

I'm not sure if this is the right place for this, but as we also don't know if this is a bug or a regression with the newer version I'll try it here anyway:

We're currently evaluating if we can switch our VPN Setup over to netbird. For this we have set up a self-hosted Instance for now, which we might switch to the cloud offering later on due to a requirement for a HA Management Setup and Multi Tenant functionality. We currently have ~5k Nodes connected to netbird, which we added in increasing batches and as long as we limited the parallel number of netbird up commands everything worked fine. Yesterday we updated the docker-compose stack which lead to a restart of almost all services, except coturn and dashboard, which then lead to all peers reconnecting to the management node which took a bit, but after a short while everything was working normally. Today we did the same and updated to the newly released 0.51.1 and now almost no nodes can connect anymore, and the Dashboard is not accessible. The docker logs are flooded with entries like these:

management-1  | 2025-07-16T11:16:53Z DEBG [context: GRPC, requestID: xxxxxxxxxx] management/server/grpcserver.go:441: Login request from peer [xxxxxxxxxx] [x.x.x.x]

which is expected since all peers need to reconnect. And in between there are messages like these:

management-1  | 2025-07-16T11:15:28Z DEBG [context: GRPC, requestID: xxxxxxxxxx, accountID: xxxxxxxxxx, peerID: xxxxxxxxxx] management/server/account.go:1623: SyncAndMarkPeer: took 8m23.407635647s

management-1  | 2025-07-16T11:15:28Z DEBG [context: GRPC, requestID: xxxxxxxxxx, accountID: xxxxxxxxxx, peerID: xxxxxxxxxx] management/server/grpcserver.go:200: Sync: took 8m30.352848964s

management-1  | 2025-07-16T11:15:28Z DEBG [peerID: xxxxxxxxxx, context: GRPC, requestID: xxxxxxxxxx, accountID: xxxxxxxxxx] management/server/peer.go:110: MarkPeerConnected: took 685.825795ms

which probably means after a very long time some peers are able to connect and sync.

The clients, user-facing ones which need to log in through our keycloak instance as well as headless servers which were added with setup-keys, mostly output:

Error: waiting sso login failed with: rpc error: code = DeadlineExceeded desc = context deadline exceeded

and

ERRO management/client/grpc.go:349: failed to login to Management Service: rpc error: code = DeadlineExceeded desc = context deadline exceeded

Currently, we're still using the SQLite Backends as it worked fine until today, however switching to postgres or mysql (which according to the commits is also planned in the future?) would probably be a good idea.

To finally arrive at my question: Should netbird currently be able to handle a setup like this or is it more meant for setups with at most a few hundred Peers? And if it should be able to handle larger amounts of peers could this be a bug or regression with the current version?

Have you tried these troubleshooting steps?

Reviewed client troubleshooting (if applicable)
Checked for newer NetBird versions
Searched for similar issues on GitHub (including closed ones)
Restarted the NetBird client
Disabled other VPN software
Checked firewall settings

Originally created by @jr-timme on GitHub (Jul 24, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4212 **Describe the problem** After adding ~5k Nodes and updating to netbird `>=0.51.1` and restarting the management node peers can't connect to the management node anymore, the connection always fails with: `DeadlineExceeded desc = context deadline exceeded` **To Reproduce** Steps to reproduce the behavior: 1. add ~5k peers to the network 2. update to `>=0.51.1` 3. restart control-plane/management server **Expected behavior** all peers should be able to reconnect to the management Node/reestablish the connections to the other peers **Are you using NetBird Cloud?** self-hosted control plane **NetBird version** `>=0.51.1` **Is any other VPN software installed?** No **Additional context** As the previous Sections aren't really suited for an indepth explanation here is a longer version, which we previously posted to your Slack but haven't gotten any response to. All dates and things like "yesterday" and "today" are relative to 2025-07-16: -------- I'm not sure if this is the right place for this, but as we also don't know if this is a bug or a regression with the newer version I'll try it here anyway: We're currently evaluating if we can switch our VPN Setup over to netbird. For this we have set up a self-hosted Instance for now, which we might switch to the cloud offering later on due to a requirement for a HA Management Setup and Multi Tenant functionality. We currently have ~5k Nodes connected to netbird, which we added in increasing batches and as long as we limited the parallel number of `netbird up` commands everything worked fine. Yesterday we updated the docker-compose stack which lead to a restart of almost all services, except coturn and dashboard, which then lead to all peers reconnecting to the management node which took a bit, but after a short while everything was working normally. Today we did the same and updated to the newly released `0.51.1` and now almost no nodes can connect anymore, and the Dashboard is not accessible. The docker logs are flooded with entries like these: ```log management-1 | 2025-07-16T11:16:53Z DEBG [context: GRPC, requestID: xxxxxxxxxx] management/server/grpcserver.go:441: Login request from peer [xxxxxxxxxx] [x.x.x.x] ``` which is expected since all peers need to reconnect. And in between there are messages like these: ```log management-1 | 2025-07-16T11:15:28Z DEBG [context: GRPC, requestID: xxxxxxxxxx, accountID: xxxxxxxxxx, peerID: xxxxxxxxxx] management/server/account.go:1623: SyncAndMarkPeer: took 8m23.407635647s management-1 | 2025-07-16T11:15:28Z DEBG [context: GRPC, requestID: xxxxxxxxxx, accountID: xxxxxxxxxx, peerID: xxxxxxxxxx] management/server/grpcserver.go:200: Sync: took 8m30.352848964s management-1 | 2025-07-16T11:15:28Z DEBG [peerID: xxxxxxxxxx, context: GRPC, requestID: xxxxxxxxxx, accountID: xxxxxxxxxx] management/server/peer.go:110: MarkPeerConnected: took 685.825795ms ``` which probably means after a very long time some peers are able to connect and sync. The clients, user-facing ones which need to log in through our keycloak instance as well as headless servers which were added with setup-keys, mostly output: ```log Error: waiting sso login failed with: rpc error: code = DeadlineExceeded desc = context deadline exceeded ``` and ```log ERRO management/client/grpc.go:349: failed to login to Management Service: rpc error: code = DeadlineExceeded desc = context deadline exceeded ``` Currently, we're still using the SQLite Backends as it worked fine until today, however switching to postgres or mysql (which according to the commits is also planned in the future?) would probably be a good idea. To finally arrive at my question: Should netbird currently be able to handle a setup like this or is it more meant for setups with at most a few hundred Peers? And if it should be able to handle larger amounts of peers could this be a bug or regression with the current version? **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [x] Checked for newer NetBird versions - [x] Searched for similar issues on GitHub (including closed ones) - [x] Restarted the NetBird client - [x] Disabled other VPN software - [x] Checked firewall settings

saavagebueno added the triage-needed self-hosting labels 2026-08-05 01:20:00 -04:00

saavagebueno commented

2026-08-05 01:20:01 -04:00

@nazarewk commented on GitHub (Jul 24, 2025):

Did it happen when upgrading from 0.51.0 to 0.51.1 or from an earlier version? https://github.com/netbirdio/netbird/releases/tag/v0.51.0 notes the need to update Relays before things start working correctly

@nazarewk commented on GitHub (Jul 24, 2025): Did it happen when upgrading from `0.51.0` to `0.51.1` or from an earlier version? https://github.com/netbirdio/netbird/releases/tag/v0.51.0 notes the need to update Relays before things start working correctly

saavagebueno commented

2026-08-05 01:20:01 -04:00

@jr-timme commented on GitHub (Jul 24, 2025):

We were using latest in our compose file at that point for all services so signal, relay and management were updated at the same time, so the update the day before (2025-06-15 ~4 pm) should have pulled the 2 hours earlier released 0.51.0. But I did not check the installed version afterwards.

I also can't say for sure that all peers were already on 0.51.0 as they pull their updates through unattended-upgrades (runs once a day) from your debian repo.

The next day we did the same docker compose pull, so signal, relay and management were updated to 0.51.1 at the same time.

iirc dashboard and coturn did not have an update on either of the two days

Also interesting would be if Netbird is meant for/able to handle deployments of this size and if there are any differences between the self-hosted control plane and the managed version in this regard.

@jr-timme commented on GitHub (Jul 24, 2025): We were using `latest` in our compose file at that point for all services so `signal`, `relay` and `management` were updated at the same time, so the update the day before (2025-06-15 ~4 pm) should have pulled the 2 hours earlier released 0.51.0. But I did not check the installed version afterwards. I also can't say for sure that all peers were already on 0.51.0 as they pull their updates through unattended-upgrades (runs once a day) from your debian repo. The next day we did the same `docker compose pull`, so `signal`, `relay` and `management` were updated to 0.51.1 at the same time. iirc `dashboard` and `coturn` did not have an update on either of the two days ------ Also interesting would be if Netbird is meant for/able to handle deployments of this size and if there are any differences between the self-hosted control plane and the managed version in this regard.

saavagebueno commented

2026-08-05 01:20:01 -04:00

@nazarewk commented on GitHub (Jul 25, 2025):

What you're observing (context deadline exceeded) might have similar causes to our current performance issues. While probably not very practical, it would definitely help if you staggered the reconnection rates to spread those over time until the whole thing stabilizes.

@nazarewk commented on GitHub (Jul 25, 2025): What you're observing (context deadline exceeded) might have similar causes to our current performance issues. While probably not very practical, it would definitely help if you staggered the reconnection rates to spread those over time until the whole thing stabilizes.

saavagebueno commented

2026-08-05 01:20:01 -04:00

@nazarewk commented on GitHub (Jul 25, 2025):

Did you have the same ballpark number of Peers while doing previous updates? While nothing might be failing on the backend, it might be simply too slow to respond to meet timeout requirements on the clients while a lot of those are reconnecting.

@nazarewk commented on GitHub (Jul 25, 2025): Did you have the same ballpark number of Peers while doing previous updates? While nothing might be **failing** on the backend, it might be simply too slow to respond to meet timeout requirements on the clients while a lot of those are reconnecting.

saavagebueno commented

2026-08-05 01:20:01 -04:00

@jr-timme commented on GitHub (Jul 25, 2025):

Ok, good to know, that large scale Deployments are a use case you want to support and that it is on the road map/being worked on. We'll probably pause our tests for now and reevaluate netbird at a later time, maybe closer to the first stable release.

it would definitely help if you staggered the reconnection rates to spread those over time until the whole thing stabilizes.

I don't suppose there is an option for this? Off the top of my head I can only think of a setup, where a script monitors if the management service is reachable, but netbird is not connected and then stops the local netbird service and after a random delay starts it again. But that would be quite difficult to coordinate over such a large number of peers and would mean a lot of peers aren't reachable at all during that time. (Due to regulations we have to access all peers over a secured network, which would be netbird, once we switch over from our current solution)

Did you have the same ballpark number of Peers while doing previous updates? While nothing might be failing on the backend, it might be simply too slow to respond to meet timeout requirements on the clients while a lot of those are reconnecting.

Yes we had the same number of Peers, perhaps a couple less for the last update. We had already added all peers to the network and then did both updates. But as some peers get shutdown and deleted every day and because we don't automatically add newly created peers the number was probably a bit, low 2-digits at most, lower.

What I forgot to mention: The constant reconnects and timeouts lead to OOM events on our management server as the RAM usage keeps increasing over time and after a few hours all RAM (which isn't that much, currently "only" 32 GB, which was more than enough when everything was working) is consumed which then invokes the OOM-Reaper, so just waiting for some peers to connect, which should decrease the number of concurrent reconnect-requests, which then should lead to all peers being connected after a long while is also not an option

@jr-timme commented on GitHub (Jul 25, 2025): Ok, good to know, that large scale Deployments are a use case you want to support and that it is on the road map/being worked on. We'll probably pause our tests for now and reevaluate netbird at a later time, maybe closer to the first stable release. > it would definitely help if you staggered the reconnection rates to spread those over time until the whole thing stabilizes. I don't suppose there is an option for this? Off the top of my head I can only think of a setup, where a script monitors if the management service is reachable, but netbird is not connected and then stops the local netbird service and after a random delay starts it again. But that would be quite difficult to coordinate over such a large number of peers and would mean a lot of peers aren't reachable at all during that time. (Due to regulations we have to access all peers over a secured network, which would be netbird, once we switch over from our current solution) > Did you have the same ballpark number of Peers while doing previous updates? While nothing might be failing on the backend, it might be simply too slow to respond to meet timeout requirements on the clients while a lot of those are reconnecting. Yes we had the same number of Peers, perhaps a couple less for the last update. We had already added all peers to the network and then did both updates. But as some peers get shutdown and deleted every day and because we don't automatically add newly created peers the number was probably a bit, low 2-digits at most, lower. What I forgot to mention: The constant reconnects and timeouts lead to OOM events on our management server as the RAM usage keeps increasing over time and after a few hours all RAM (which isn't that much, currently "only" 32 GB, which was more than enough when everything was working) is consumed which then invokes the OOM-Reaper, so just waiting for some peers to connect, which should decrease the number of concurrent reconnect-requests, which then should lead to all peers being connected after a long while is also not an option

saavagebueno commented

2026-08-05 01:20:01 -04:00

@mlsmaycon commented on GitHub (Jul 25, 2025):

@jr-timme we have accounts with the same number of peers and they run without issues. It could be a matter of different policies or a potential bug.

Would like to jump in a call for us to go over your setup in detail? You can send us an email to support@netbird.io and we will share a calendar link.

@mlsmaycon commented on GitHub (Jul 25, 2025): @jr-timme we have accounts with the same number of peers and they run without issues. It could be a matter of different policies or a potential bug. Would like to jump in a call for us to go over your setup in detail? You can send us an email to support@netbird.io and we will share a calendar link.

saavagebueno commented

2026-08-05 01:20:01 -04:00

@jr-timme commented on GitHub (Aug 6, 2025):

As suggested by @mlsmaycon we scheduled a meeting to analyze our problems further and while during the meeting we were not able to find any problematic configuration or be able to fix it, I also left the meeting with a couple of additional To-Do's which weren't practical to try during our meeting. It took me a while to get to those but in case it is of interest to anyone else having similar problems here are my additional findings:

The setup before the additional tests was the simple docker compose stack using SQLite and Keycloak described in the official documentation.

tl;dr: don't use SQLite for large scale Deployments and switch to PostgreSQL instead. Also don't disable lazy connections if you use consumer grade hardware and have ACLs which allow some users to see/connect to a lot of peers.

Increasing/Specifying NB_PEER_UPDATE_STARTUP_PERIOD_S=300 and NB_PEER_UPDATE_STARTUP_PERIOD_S=3

this did not improve the situation

We provisioned most our peers with non-reusable setup_keys created through the API, but we did not remove the expired keys afterward, which meant there were still ~3000 setup_keys present, which are also loaded during update operations and could lead to issues

removing the expired setup_keys did not help

Disabling lazy connections

as lazy connections are still an experimental feature it was suggested, that we try disabling it.
This did, at first, not change anything. However after we were able to fix the connection issues disabling lazy connections lead to massive problems as a "desktop peer" from a higher level sysadmin which has access to pretty much all peers lead to netbird establishing a connection to every other peer which overloaded the notebook as well as the consumer-grade router in use.

Migrating from SQLite to PostgreSQL

while SQLite theoretically should also be able to handle this amount of peers a migration to MariaDB or PostgreSQL was already on our To-Do List and should improve Performance
the migration process does not work exactly as described in the docs (see also: https://github.com/netbirdio/docs/issues/402) but this did in fact solve all of our problems.

Migrating to a different host system with faster storage (more in regard to IOPS than raw speed)

as the migration to PostgreSQL already fixed our issues and did only cause a short load spike during the initial start we did not test this. We were also able to temporarily scale down our Management node from 16 Cores / 32 GB RAM to 4 Cores / 8 GB RAM while using the same storage backend and everything still worked, albeit the load spike after a restart of all services took quite a bit longer.

For us the issue is resolved, but perhaps the documentation could be expanded to include a notice/warning that the default SQLite backend should not be used for larger setups.

@jr-timme commented on GitHub (Aug 6, 2025): As suggested by @mlsmaycon we scheduled a meeting to analyze our problems further and while during the meeting we were not able to find any problematic configuration or be able to fix it, I also left the meeting with a couple of additional To-Do's which weren't practical to try during our meeting. It took me a while to get to those but in case it is of interest to anyone else having similar problems here are my additional findings: The setup before the additional tests was the simple docker compose stack using SQLite and Keycloak described in the official documentation. tl;dr: don't use SQLite for large scale Deployments and switch to PostgreSQL instead. Also don't disable lazy connections if you use consumer grade hardware and have ACLs which allow some users to see/connect to a lot of peers. 1. Increasing/Specifying `NB_PEER_UPDATE_STARTUP_PERIOD_S=300` and `NB_PEER_UPDATE_STARTUP_PERIOD_S=3` - this did not improve the situation 2. We provisioned most our peers with non-reusable setup_keys created through the API, but we did not remove the expired keys afterward, which meant there were still ~3000 setup_keys present, which are also loaded during update operations and could lead to issues - removing the expired setup_keys did not help 3. Disabling lazy connections - as lazy connections are still an experimental feature it was suggested, that we try disabling it. - This did, at first, not change anything. However after we were able to fix the connection issues disabling lazy connections lead to massive problems as a "desktop peer" from a higher level sysadmin which has access to pretty much all peers lead to netbird establishing a connection to every other peer which overloaded the notebook as well as the consumer-grade router in use. 4. Migrating from SQLite to PostgreSQL - while SQLite theoretically should also be able to handle this amount of peers a migration to MariaDB or PostgreSQL was already on our To-Do List and should improve Performance - the migration process does not work exactly as described in the docs (see also: [https://github.com/netbirdio/docs/issues/402](https://github.com/netbirdio/docs/issues/402)) but this did in fact solve all of our problems. 6. Migrating to a different host system with faster storage (more in regard to IOPS than raw speed) - as the migration to PostgreSQL already fixed our issues and did only cause a short load spike during the initial start we did not test this. We were also able to temporarily scale down our Management node from 16 Cores / 32 GB RAM to 4 Cores / 8 GB RAM while using the same storage backend and everything still worked, albeit the load spike after a restart of all services took quite a bit longer. For us the issue is resolved, but perhaps the documentation could be expanded to include a notice/warning that the default SQLite backend should not be used for larger setups.

Sign in to join this conversation.

Branches Tags

main

fix/wails-go-vendor

fix/update-wails-fork-ref

add-atomic-cache-ops

feat/agent-network-per-account-serving

feat-post_quantum_ml_kem

revert/component-types

wins_nrpt_dns_delegation

embedded-vnc

dependabot/github_actions/actions-a940c7c866

fix/quickstart-subnet-and-domain-alias

notification-localization

ssh-settings-elevation

refactor/peer-event-bus

fix/relay-proxy-redirect-when-ice-active

disambiguate_p2p_metrics

claude/agent-network-test-cases-p743vw

android/gui-integration

ice-stun-wg-demux

dependabot/npm_and_yarn/proxy/web/npm_and_yarn-b39864987c

agent-network-setup-poc

dependabot/go_modules/aws-sdk-8f849ebaed

dependabot/go_modules/otel-e34c790afd

dependabot/go_modules/testcontainers-de325c0dd6

dependabot/go_modules/wireguard-dbd6b95108

dependabot/go_modules/pion-5f703e1eca

dependabot/go_modules/gorm-2271c8195b

fix-login-needed-check

dependabot/go_modules/google.golang.org/grpc-1.82.1

revert/component-types-hookup

feature/ios-ssh

docs/agent-network-docs-update

dependabot/go_modules/github.com/aws/aws-sdk-go-v2/service/s3-1.106.3

dependabot/go_modules/github.com/pion/stun/v3-3.1.5

fix-ssh-authorized-users-multi-rule

peer-acl-multi-source

reverse-proxy-crowdsec-appsec

reverse-proxy-allow-match-or

client-local-metrics

lazy-conn-per-peer

lazy-conn-rosenpass

dependabot/go_modules/github.com/gopacket/gopacket-1.7.0

dependabot/go_modules/goauthentik.io/api/v3-3.2026050.6

dependabot/go_modules/github.com/pires/go-proxyproto-0.15.0

dependabot/go_modules/github.com/jackc/pgx/v5-5.10.0

dependabot/go_modules/github.com/oapi-codegen/runtime-1.6.0

dependabot/go_modules/github.com/eko/gocache/lib/v4-4.2.4

dependabot/go_modules/github.com/pkg/sftp-1.13.11

dependabot/go_modules/github.com/coreos/go-oidc/v3-3.20.0

ssh-windows-privilege-check

fix/explicit-cors-handling

fix/remove-math-rand

test/gui-memory-leak-fix

fix/ui-status-dispatch

install-script-ui-dependencies

fix/grpc-get-network-map

fix/subscribe-status-coalesce

fix/tray-menu-item-leak

fix/windows-tray-race

feature/changeset

worktree-dns-route-qtype-fallthrough

mdm_integration

mlsmaycon-patch-2

feat/agent-network-ollama

proxy-tunnel-cache-ttl-env

coderabbitai/utg/1e5b0a5

grpc-acl

test/battery-drain

components-impl-drop-indexes-use-xids-no-resource-policy-map

fix/nmap-relevant-groups

e2e-guardrail-blocks-unselected-model

fix/lazyconn-cold-start-allowed-ips

vertex-guardrails-model-access-e2e

refactor/relay-foreign-cache

ci/trigger-release-tests

feature/kimi-3-agent-networks-dns-warmup

feature/dns-lazy-conn-warmup

daemon-ipc-acl

feature/ui-translation-key-parity-check

refactor/relay-foreign-cache-tests

fix/lazyconn-idle-keep-wg-peer

dmitri-propagate-auth-grant-types-on-combined

0.74.7-branch

diagnose-empty-vs-corrupt-state

windows-sleep-detector

fix/cli-up-wait-for-daemon

rp_key_persistency

feature/native-grpc

0.74.6-branch

0.74.6-branch-sync

0.74.5-branch-sync

0.74.4-branch

fix/remove-stale-peers-removal

fix/remove-stale-proxy-logic

fix/nsis-preserve-autostart-on-upgrade

dependabot/go_modules/goauthentik.io/api/v3-3.2026050.3

dependabot/go_modules/github.com/pkg/sftp-1.13.10

components-impl-drop-indexes

fix-reset-aggregation-window-flake

dependabot/go_modules/github.com/pion/dtls/v3-3.1.5

0.74.x

fix/relay-states-lock

update-process-pkg

update-gopsutil-v4

fix/relay_states_lock

increase-sysinfo-timeout

dependabot/go_modules/github.com/Azure/go-ntlmssp-0.1.1

dependabot/go_modules/github.com/eko/gocache/store/redis/v4-4.2.6

dependabot/go_modules/github.com/eko/gocache/lib/v4-4.2.3

fix/fail-to-create-upnp-port-mapping-on-opnsense-firewall

0.74.3-branch

fix/routeselector-atomic-exit-node

netmap_progressive_alignment

nmap/components-impl

dependabot/go_modules/github.com/jackc/pgx/v5-5.9.2

dependabot/go_modules/github.com/oapi-codegen/runtime-1.4.2

dependabot/go_modules/github.com/gopacket/gopacket-1.6.1

dependabot/go_modules/github.com/coreos/go-oidc/v3-3.19.0

dependabot/go_modules/github.com/pires/go-proxyproto-0.12.0

fix/signal-watchdog-sync-stop

docs/agent-network

test/affected-logic

fix/revert-ice-filter

refactor/simplify-affected-peers

pascal-filter-policies-by-direction

claude/lock-contention-peer-connect-g8t6au

dmitri-filter-policies-by-direction

refactor/migrate-profiles-to-go

profile-bindings-ios

fix/skip-restart-unchanged-route

fix/mgmt-cache-async-resolve

refactor/wails-update-105

client_lifetime_serialization_refactor

fix/browser-ssh-2

fix/ipv6-and-netstack-accept-loop

fix/browser-ssh

profile-id-name-test

refactor/mgmt-bootstrap

feat/getting-started-unified-wizard

socket-grpc-permissions

fix/mysql-index-migration

windows-dns-firewall

tests/enable-race-on-tests

ui-refactor-gtk3

feature/affected-peers-grpc

profile-id

lazyconn-first-packet-fix-v2

claude/focused-gates-VMTgb

ui-tray-linux-leftclick

fix/ctx-enrichment

daemon-owner

feature/android-client-ssh

worktree-accept-ra-forwarding

nmap/combined-deploy

task/align_protobuff_toolset

feature/session-extend

add-json-yaml-flags

refactor/ephemeral-cleanup

claude/webtransport-relay-wasm-mUjY9

claude/vnc-udp-feasibility-6KB1U

fix/wgport-config

e2e-windows-dns-combined

fix/login-cmd-root-flags

feat/reseller-openapi-spec

github-issue-resolver

add-steamos-support

fix-darwin-uninstaller

flutter-test

ci/freebsd-pkg-bootstrap

cached-serial-check-on-sync

fix-mgmt-cache-bypass-overlay

revert-easyjson-5938

revert-ice-5820

revert-firewalld-5928

refactor/permissions-manager

revert-dns-5935-systemd-resolved

revert-dns-5935-5945

revert-dns-5945-mgmt-cache

feature/log-most-busy-peers

prototype/ui-wails

coderabbitai/utg/8ae8f20

feature/use-peer-fqdn-on-https

release/0.68.3

add-slack-channel

claude/rdp-token-passthrough-eNcqW

transparent-proxy

fix/macos-stale-route-eexist

crowdsec-selfhosted

fix/remove-otel-units

entire/checkpoints/v1

fix/getting-started

feat/static-connectors-combined-server

feature/use-local-keys-embedded

feature/fleetdm

set-env-only-if-not-fork

feature/expose-has-channel

fix/connection-status-race

fix/filter-cgnat-cni-ice-candidates

feature/check-cert-locker-before-acme

test/proxy-fixes

test/proxy-mtu

prototype/ui-tauri

test/proxy-speed

fix-reused-ports

feat/migrate-to-embedded-idp

feature/add-serial-to-proxy-merged

deploy/proxy-serial

test/connection

feature/disable-legacy-port

feature/flag-to-disable-legacy-port

test/perftest

fix/http-redirect

poc-token-command

dn-reverse-proxy

prototype/reverse-proxy-rename

prototype/reverse-proxy-logs-pagination

feature/client-metrics

prototype/reverse-proxy-clusters

debug-dns-route

fix/win-dns-batch

add-extra-route-logs

job-stream-notify-disconnection-eof

deploy/secrets-manager

trigger-proxy-update

bug/update-ios-client-code-build-tags

sync-client-netmap-serial

log/conn-disconn

nmap/compaction-deploy

ci-win-test

feature/disk-encryption-check

wasm-debug

swap-dns-prio

fix/dex-config

feature/migrate-auto-groups-to-table

nmap/compaction

dex-nocgo-stub

feature/exclude-terraform-from-rate-limiting

test-freebsd

retries-refactor

coderabbitai/docstrings/b7e98ac

feat/integrate-zitadel

bug/ios-hanging-reconection

zitadel-idp

feat/network-map-serial

refactor/get-account-no-users

feat/auto-upgrade

feature/report-high-pat-id

feature/temporary-access-for-resource

fix/nmap-fwrules

dont-restart-dns

prototype/ui

update-gomobile

go-dns-for-ice

wasm-ldflags

test-ldflags

wasmbuild-test

feature/networks-s2s

vk/compare-nmaps

dbg/bothmaps

reorder-dns-shutdown

fix/relay-reconnection-race

fix/nmap-exitnodes

vk/debug/nmap-both

move-licensed-code

feat/better-daemon-connection-lost-message

feat/auto-update-2

test/timings

refactor/getaccount-raw

tests/nmap-getaccount

refactor/nmap

refactor/nmap-limit-buffer

feature/detect-mac-wakeup

feature/extract-modules

quick-setings

feat/sync-limiter

feature/store-cache-impl

fix-install-version

feature/store-metrics

feature/metrics-on-store

feature/use-gorm-cache

loadtest-signal

unsymmetrical-squash

refactor/reducate-signaling

test/update-reduce

feature/store-cache

feature/remote-debug

cli-ws-proxy-backend-addr

feat/mgmt-map-serial

snyk-fix-d9d0081a4c7f9137bdb59d0d50a141a2

snyk-fix-7415cea5a11acd66753540ca2c598c63

job-yml-update

feature/android-allow-selecting-routes

fix/up-sequence

fix/dns-hash-update

snyk-fix-967adae9863f17f108ce8948d9117b8d

log/getaccount-by-peer

signal-suppressor

dns-exit-node

feature/auto-updates

feature/cache-srv-key

merged-fixes

fix/missed-offers-and-debug

debug-and-fixes

poc-wasm-clean-backend-s2s

test/remote-debug

debug-api

fix/remove-gpo-if-empty

fix/test-freebsd

fix/mysql-setup

fix/remove-logout-btn

handle-existing-domain-user

chore/unify-domain-validation

snyk-fix-c5fafc8a50ce1f29046e25a1fc346185

feat/profile-edit-btn

snyk-fix-a54966211e18d4cf67e5a2757cc006d1

log-short-id

feat/logout-ephemeral

log-checks

batch-wg-ops

nb-interface-default

feat/aws-integration

add/race-test

feature/relay-feature-versioning

fix/systemd-service-logs

poc/preprocessed-map

add-account-onboarding

bind-ipv6

fix/merge-main

logs/peerlogs-addpeer

feature/net-297-network-migration

feature/support-skip-auto-apply-exit-node-routes

set-cmd

set-command-with-cursor

feature/limit-update-channel

stop-using-locking-share

feature/poc-lazy-detection

feature/net-248-removal-of-sync-mutex-locks

test/multiple-peer-logging

preresolve

add-ns-punnycode-support

apply-routes-early

windows-search-domains

fix/connecting-route-filter

feature/management/rest-client/impersonate

debug-local-records

resource-fields-snake-case

test/grpc-rate-limit

traffic-correlation-policy

feature/rest-client-options

feat/events-metrics

feature/buf-cli

test/add-ratelimiter

test/remove-write-lock-on-add-peer

fix/add-peer-semaphore

feature/users-roles-endpoint

mlsmaycon-patch-1

debug-user-role

chore/primary-key-on-networks

feature/update-account-peers-buffer-startup

remove-ubuntu2004-runners

refactor/permissions-no-pat-allowed

ref/logrus-factory

use-conntrack-zone

deploy/permissions-account

feature/lazy-connection-idle

ref/improve-test-cov

restore-pr-3440

test/increase-grpc-timeouts

feat/buffer-account-peers-update

test/networkmapgeneration-changes

feature/base-manager

feature/flow-receiver

chore/benchmark-with-large-runner

refactor/handshake-initiator

client/ui-update-systray-icons

userspace-router

wgwatcher-test

output-if-key-already-exists

fix/relay-reconnection

feature/port-forwarding-client-codecleaning

detached2

test/callbacks-nil-iceconninfo

refactor/optimize-peer-expiration

enable-udp-port-for-docker-template

fix/relay-update

feature/apply-posture-netmap

fix/group-update-existing-resource

conntrack-stats

upgrade-okta-sdk

multi-price

test/conn-stat

set-min-parallel-tests-for-management

dns-interceptor

debug-dns

router-dns

add-static-system-info

debug-0.29.4

debug-0.33.0

account-refactoring

relay/2800_quic

route-get-account-refactoring

test/seed-random-routes

feature/get-account-refactoring

test/reconnect-race-condition

refactor/get-account-usage

feature/add-session-id-to-update-channel

improve-ipv4conn

fix/async-pion-event-handling

debug

add-offload

feature/validate-group-association-debug

fix/limit-conn-for-sqlite

test/engine-iface

test/transaction-for-jwt-sync

fix/engine-stop-in-foreground

feature/add-mysql-support

test-migration

refactor/header-size-values

relay/eliminate-gob

test/signal-dispatcher-with-relay

relay/debug

validate-icon

feature/ipv6-support

use-pre-expanded-peers-map

feature/use-signal-dispatcher

validate/peer-status

add-read-write-times

fix/sync-peer-race

feature/relay-status

netmap

evaluate/network-map-hash

fix/lower-dns-resolve-interval-on-fail

feature/relay

fix/go-mod-version

upgrade-nftables

synology-userspace-mode

fix/use-ip-for-default-routes-on-darwin

fix/proxy_close

enable-release-workflow-on-pr

deploy/peer-performance

feature/permanent-turn

feature/permanent-turn-proxy

deploy/posture-check-sqlite

feature/optimize_sqlite_save

debug-ios-behavior

fix/delete-route-only-after-adding

tshoot/windows-logger

remove-new-routing

refactor/eliminate-repo-dependency

add-arm-to-ci

refactor-demo-account-object

test/abc2

test/abc

send-ssh-rosenpass-config-meta

refactor-demo

ensure-schedule-never-runs-non-positive

feature/peer-validator-groupmgm

feature/peer-validator-fix

fix/include-active-dashboard-users

fix/handle-canceling-schedule

fix/geo-download

debug-google-workspace

yury/resolve-ip-to-location

feature/extend-sysinfo

sqlite-async-peer-status

yury/add-postgresql-store

fix/route

test-build

posture-checks-poc

debug-keycloak-idp

poc/netstack

for-pascal-tmp

peer-logout-management

manual-peer-logout

detached

chore/refactor-management

test/dns-bind

fix/enforce-acl-for-containers

yury/use-sync-map-in-updatechannel

fix/events-key-handling

filter-cache-on-load-account

fix/user-expiration

handle-user-context-cancellation

nb-client-k8s-statefulset

fake-addr

fix/iptables_in_docker

ebpf-debug

update-getting-started-flow-use-postgres

fix/peer_list_notification

feature/device-authentication-with-client-secret

feature/keep_alive

feat-groups-from-jwt

separate_proxy_from_wgconfig

fix/wg_conn

wg_conn_fix

wg_bind_parallel_processing

fix-rollback-get-acls

proxy_cfg_cleanup

performance-improvement-rego

update-lock-log-level

feat-client-side-acl

refactor/move_grpcserver_logic_to_account_manager

feature/event-storage

feature/update-idp-redeeming-invite

feature/api-peer-info

return-groupminimum-setupkey

feature/interface-bind

documentation_enhancement

fix-peer-registration

ssh

users_cache

pass-client-caller

client_caller_type

revert-283-feat-fix-windows-installer

periodic-peer-updates

ebpf

braginini/wasm

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: DYNR/netbird#8909

[GH-ISSUE #4212] Large Netbird Setup: Peers can't connect after netbird >=0.51.1, DeadlineExceeded desc = context deadline exceeded #8909

[GH-ISSUE #4212] Large Netbird Setup: Peers can't connect after netbird `>=0.51.1`, `DeadlineExceeded desc = context deadline exceeded` #8909