It's just a normal linode running archlinux. There are very minimal tweaks to handle the new connection load.
I should write a blog post about it. It has steadily gained more traffic over the years and hasn't need much care and feeding.
The go code can be found here if you're interested, though it some of the ugliest code I've written. I made it when ifconfig.me was having load issues many years ago.
I love the simplicity. I'm sure I could find similar source code for similar services that is way over engineered and doesn't perform nearly as well. Do you serve this with a reverse proxy in front, or just as is? I'm assuming as is since you have the TLS configured right in the code, but I figure I'd ask.
Having a reverse proxy on the same machine effectively doubles the amount of connections and requires coping the request around. There is no practical benefit to a reverse proxy for this use case. So the go program is listening directly on the internet.
I do have the service behind CloudFlare, which is essentially a reverse proxy. The reason is for CloudFlare is non-obvious; it is deserves a blog post, and that is connection pooling.
If I have all the requests go back to the origin, the bottle neck is not the go code, but Linux opening and closing all those single use TCP sessions. CloudFlare creates around 100k persistent connections to the backend, but then just keeps them open. This makes Linux much happier.
I should write a blog post about it. It has steadily gained more traffic over the years and hasn't need much care and feeding.
The go code can be found here if you're interested, though it some of the ugliest code I've written. I made it when ifconfig.me was having load issues many years ago.
https://github.com/georgyo/ifconfig.io