My team is looking at running our own standalone, on-prem DERP relay servers for Coder using the documented custom relay support:

https://coder.com/docs/admin/networking#custom-relays

One thing we are trying to figure out is how to avoid making those relays usable by any non-Coder DERP-speaking client that can reach them on our internal network.

Tailscale's derper has a useful-looking option for this:

--verify-client-url

That option posts a request containing the connecting client's DERP node public key and source IP, and expects a response like:

{ "Allow": true }

The challenge is that Coder is the system that knows whether a given DERP node key belongs to an active Coder tailnet participant. derper --verify-clients does not seem like a fit because it verifies clients through a local tailscaled instance and a Tailscale tailnet, while Coder manages its own tailnet state.

Would you consider exposing a Coder endpoint that could be used directly as the --verify-client-url target for standalone derper instances?

For example, something along these lines:

POST /api/v2/tailnet/derp/admit-client

Where derper could send the normal Tailscale admission request, and Coder would respond with whether that node key is currently an active/authorized Coder tailnet peer.

A rough usage example might look like:

derper \
  --derp=true \
  --stun=false \
  --verify-client-url="https://coder.example.com/api/v2/tailnet/derp/admit-client?token=..." \
  --verify-client-url-fail-open=false

This would let operators run regional standalone DERP relays while still plumbing relay admission back to Coder's own tailnet membership, instead of relying only on network perimeter controls.

Thanks for your time! 🙏