We're likely going to move off of them. Last year we were using their Wireguard "peering" feature to connect our RDS DB (as recommended by their blog)[0].
This feature had a multi-hour outage, and when we wrote in for support, we were told "[t]he Wireguard peers are intended to get you development access to your network. We didn't really build them to handle inter service communication that affects uptime. The gateways we run wireguard peers on are not redundant."
We stopped using the feature (using Tailscale instead), but in my opinion, that directly contradicts the spirit of their blog and docs, and it really left a bad taste in our mouth. We're probably going to move to Render or something similar soon.
"[t]he Wireguard peers are intended to get you development access to your network. We didn't really build them to handle inter service communication that affects uptime"
Huh, such a strange response, shouldn't matter what my use case is (development vs service communication), if it's running it should be up.
Also, losing development access to your network seems like a weird thing to be OK with losing. Even if you just used it for development, wouldn't you want it to be accessible?
This feature had a multi-hour outage, and when we wrote in for support, we were told "[t]he Wireguard peers are intended to get you development access to your network. We didn't really build them to handle inter service communication that affects uptime. The gateways we run wireguard peers on are not redundant."
We stopped using the feature (using Tailscale instead), but in my opinion, that directly contradicts the spirit of their blog and docs, and it really left a bad taste in our mouth. We're probably going to move to Render or something similar soon.
[0]: https://fly.io/blog/ipv6-wireguard-peering/#wireguard-peerin...