Question: Nginx or HAProxy as a reverse proxy? I’ve tested both. In some cases, I still need nginx, while in others, after a closer look, it’s not necessary.
Performance, etc.
Opinions from those who use/have used both?

to sum up what I figured out last night:

Wireguard point-to-point links are as easy to set up as the reverse-proxy apps ('frp' and 'rathole') I've used in the past, and likely more reliable, performant, and secure.

I used this guide to set up such a link: https://docs.vultr.com/how-to-install-wireguard-vpn-on-debian-12

I'm going to replace my existing setups with this, and I'm pleased that upon finally taking the time to look into it, #Wireguard proved very simple to use.

as for my claims of its likely superiority:

* more reliable due to more highly proficient eyes on the codebase and a bigger userbase smoking out bugs

* more performant due to less copying bytes to/from userspace

* more secure because one point of Wireguard is to have as small a codebase as possible, and again (being in the kernel in part) it has more smart sets of eyes on it; further, it makes use of existing IP networking security practices.

this is a major step forward for Surfhosting. I had a big mental block on deploying Wireguard for quite a while, and now I'm past it.

@brigrammer@poa.st

no fucking clue.

I'm using misskey, outta the box. It's got almost no English-language documentation. Takes a little bit of brainpower (and practice) just to run the bash installer.

#Misskey is a #Node #Typescript application, running on port 3000, and uses #postgresql and #redis for data backend. I'm assuming that the redis does fast cacheing of some sort, not sure what all is there. Also has #nginx set up as a #reverseproxy on port 80, even though the the documentation tells us to expose port 3000 to the world.

That's what I did. I'm assuming that most federation would still work even with port 3000 closed, but it's not worth taking the chance.

The entire application is very fast running and very snazzy looking when it's running all on one box with a good deal of hardware available.

I know that misskey works, and it's a good program, but I want it to be slightly budget-optimized and somewhat containerized so that I can tinker with other containerized applications with the #VPS I already have running.

River looks like an interesting project. Might allow me to replace all of hitch, varnish, lego, and nginx in my personal infra when it's production ready. https://www.memorysafety.org/blog/river-release/

Friends of the #BSDCafe and of the #Fediverse,
initially, for just over a year, BSD Cafe's media was stored in a FreeBSD physical server jail with an outgoing bandwidth of 250 Mbit/sec. To address bandwidth congestion, I had integrated Cloudflare with a tunnel, serving media (and only media) through Cloudflare.

In line with the principles of self-hosting and data ownership, I’ve decided to remove Cloudflare. This has led to some bandwidth congestion when media was posted and slower download speeds for users, particularly during peak times. This is because as soon as content is published and federated servers are notified, they will rush (depending on how full their queues are) to download the newly published content - media included.

I’ve now revised the setup (currently in beta) by moving DNS management to two personal nameservers run with PowerDNS. The media server remains the same, but I’ve added two reverse proxies, one in the USA and one in Germany (the media server is in Poland). They're connected to the Media server via WireGuard.
I’ve installed the excellent Varnish and created a custom VCL. Media requests will be directed by the PowerDNS LUA scripts to the caller's closest reverse proxy. Nginx will pass requests to Varnish, which will serve data from the cache if available. If not, it will fetch from the original server, but request volume has decreased significantly.

I’m analyzing the results, and they look very promising. I may expand this home-made CDN by adding more VPSs, potentially closer to Asia and Oceania.

A detailed blog post will follow.

Stay tuned!

gonna mention this again after looking at the releases page..

"rathole, like frp and ngrok, can help to expose the service on the device behind the NAT to the Internet, via a server with a public IP."

https://github.com/rapiz1/rathole