Daniel Quinn

I’ve been self-hosting my blog for 21years if you can believe it, much of it has been done on a server in my house. I’ve hosted it on everything from a dusty old Pentium 200Mhz with 16MB of RAM (that’s MB, not GB!) to a shared web host (Webfaction), to a proper VPS (Hetzner), to a Raspberry Pi Kubernetes cluster, which is where it is now.

The site is currently running Python/Django on a few Kubernetes pods on a few Raspberry Pi 4’s, so the total power consumption is tiny, and since they’re fanless, it’s all very quiet in my office upstairs.

In terms of safety, there’s always a risk since you’re opening a port to the world for someone to talk directly to software running in your home. You can mitigate that by (a) keeping your software up to date, and (b) ensuring that if you’re maintaining the software yourself (like I am) keeping on top of any dependencies that may have known exploits. Like, don’t just stand up an instance of Wordpress and forget about it. That shit’s going to get compromised :-)

The safest option is probably to use a static site generator like Hugo, since then your attack surface is limited to whatever you’re using to serve the static sites (probably Nginx), while if you’re running a full-blown application that does publishing etc., then that’s a lot of stuff that could have holes you don’t know about. You may also want to setup something like Cloudflare in front of your site to prevent a DOS attack or something from crippling your home internet, though that may be overkill.

But yeah, the bandwidth requirements to running a blog are negligible, and the experience of running your own stuff on your own hardware in your own house is pretty great. I recommend it :-)

At the firewall level, port forwarding forwards traffic bound for one port to another machine on your network on an arbitrary port, but the UI built on top of it in your router may not include this.

If it’s not an option in your Fritzbox, your options are:

• Make the service running on your internal network listen on one of those high-number ports instead.
• Introduce another machine on the network that also performs NAT between your router and your machine
• Try to access the underlying firewall in your router to tweak the rules manually. Some routers have an admin console accessible via telnet or SSH that may allow this.
• Get a new router.

The first and last options on this list are probably the best.

It would be absolutely bizarre if you couldn’t connect with WireGuard port and Wireguard obfuscation set to Automatic. Things to try first:

1. Connect without your VPN and try to access a single website like the theguardian.com
2. Once that’s working, enable your VPN and that should do it.
3. If you still can’t get connected, try switching out different countries. Each country listed corresponds to an IP to which your machine will try to connect over a benign port like 443 – so blocking that sort of traffic would be mad unless the IP is explicitly blocked. Therefore, driving to different country targets offers a different IP every time. They’d have to know Mulvad’s whole list and block them all.

If the above somehow doesn’t work, Mulvad offers support through which you can get a temporary Server IP override. You can enter that in the bottom portion of your app’s settings.

Thanks for posting this! I have the same router.

• Kubernetes Cluster
  • pi-left
  • pi-right
  • pi-centre
• Other Servers
  • pi-katamari (file server & database)
  • pi-athens (DHCP, DNS, pi-hole)
  • Alexandria (Synology)
• Desktops
  • Berlin
• Laptops
  • London
  • Brighton
  • Brussels
  • Cambridge
  • Toronto
• Phones
  • Laconia
  • Vulcan
  • Bajor

You might want to consider just Dockerising everything. That way, the underlying OS really doesn’t matter to the applications running.

I’ve got a few Raspberry Pi’s running Debian, and on top of that, they’re running a kubernetes cluster with K3s. I host a bunch of different services, all in their own containers (effectively their own OS) and I don’t have to care. If I want to change the underlying OS, the containers don’t know either. It’s pretty great.

What about blog spam though? Surely this would relinquish controls like moderation for your site?

There have been some great answers on this so far, but I want to highlight my favourite part of Docker: the disposability.

When you have a running Docker container, you can hop in, fuck about with files, break stuff as you try to figure something out, and then kill the container and all of the mess you’ve created is gone. Now tweak your config and spin up a fresh one exactly the way you need it.

You’ve been running a service for 6 months and there’s a new upgrade. Delete your instance and just start up the new one. Worried that there might be some cruft left over from before? Don’t be! Every new instance is a clean slate. Regular, reproducible deployments are the norm now.

As a developer it’s even better: the thing you develop locally is identical to the thing that’s built, tested, and deployed in CI.

I <3 Docker!

Upon a cursory read, it sounds like you host a server and then relay all of your data through their centrally controlled system all while also pushing your account data to them.

I’m not sure they understand what “federated” means. Or rather, they know, but they’re hoping we don’t care.

Aww! Thank you! It was fun ❤️

Thanks! The crazy thing is that it’s really not that complicated. I’d say the hardest work was in writing the docs :-). It’s awesome to hear that people still use it and love it though.

Actually, I stepped away from the project 'cause I stopped using it altogether. I started the project to satisfy the British government with their ridiculous requirements for proof of my relationship with my wife so I could live here. Once I was settled though and didn’t need to be able to bring up flight itineraries from 5 years ago, it stopped being something I needed.

Well that, and lemme tell you, maintaining a popular Free software project is HARD. Everyone has an idea of where stuff should go, but most of the contributions come in piecemeal, so you’re left mostly acting as the one trying to wrangle different styles and architectures into something cohesive… while you’re also holding down a day job. It was stressful to say the least, and with a kid on the way, something had to give.

But every once in a while I consider installing paperless-ngx just to see how it’s come along, and how much has changed. I’m absolutely delighted that it’s been running and growing in my absence, and from the screenshots alone, I see that a lot of the ideas people had when I was helming made it in in the end.

Ha! I wrote it! Well the original anyway. It’s been forked a few times since I stepped away.

So yeah, I think it’s pretty cool 😆

Nope. It’s definitely not. The idea is just to make it safe® to share files within an organisation. The assumption is that for direct P2P sharing you’ll want something simpler like Croc.

Not really. It’s async in the sense that you can send a file now, and the server will hold it in an encrypted state until your recipient comes to collect it.

I was recently introduced to Croc which is great for point-to-point immediate shares. If you want something async, I wrote Korra some years ago. It might do the job for you.