Self-Hosting for Fun and Personal Freedom
These days, everything is in the cloud. This is fantastic as far as accessibility goes, but it comes at a cost of, well, freedom. Freedom, in this case, refers to the ability to control and access your data when and how you choose.
For example, imagine inadvertent or mis-applied suspension of your Google account that you use for password recovery. Plenty of services even use email as a primary means of confirming legitimate access when logging in.
It's no stretch to come up with reasons to take control of your data. One way to take control is self-hosting. And with many popular services having a viable open source or self-hosted alternative, the question is: should you self-host?
For me, the answer is, "yes, sometimes." Before you jump on board, too, there's a few things you might want to consider.
Control and freedom. Your data is yours to do with as you please, with no one to control it. However, be aware that there may still be certain ways that your own self-hosted deployment can be limited through control by the publisher. For example, Bitwarden only supports two-factor authentication (2fa) if you pay for a license. If you don't pay, you can't access your 2fa— even if you self-host.
Another part of control is availability. If GitHub is down, well that's out of your control. But if your GitLab server is down, it's on you to fix it. Congrats! You're in control.
Learning, or fun. Figuring out how some program works and how to deploy it and use it to your fancy is a challenging but worthwhile experience.
Simplicity. Usually, self-hosted products are simpler and less feature-packed which can lead to a less complicated workflow overall. As an example, Gitea has a lot less features than GitHub or GitLab, but is a breeze to get setup and running. I find even the code is more accessible, but that may be personal bias toward Golang showing.
Security is probably the most imporant consideration. Study up on basic server hardening. Some basic necessities include (by no means exhaustive): blocking all traffic that isn't explicitly necessary, securing sshd (no root login, no password login), running fail2ban, using strong sudo passwords, running services as non-root users, and keeping systems up to date.
Maintenance is the next potential nightmare. Many self-hosted products don't really provide a lot of support, so figuring out why your particular setup is broken can be a challenge. Learning to comb through logs is a key skill that must be developed. Keeping your own documentation is also key to massively reducing the overall headache of maintenance.
Availability appears as a drawback, too, as it can be difficult to achieve. Deploying a redundant, always available service is not exactly an easy feat. If your service is crucial (e.g. a password manager) then it can be a big problem if your server goes down.
Cost is also a factor to consider. Your self-hosted service has to run on some server somewhere and you'll probably need to pay for that. This can quickly balloon if you're not careful, but I find that services like Linode or DigitalOcean are fantastic options when it comes to deploying your own infrastructure.
The drawbacks are considerable, but the payoff might be worth it for you, for certain services.
What do you self-host? How do you tackle the mentioned drawbacks?
- November 2022
- Incremental Progress
- August 2021
- Self-Hosting for Fun and Personal Freedom
- July 2019
- Closing Channels Twice in Go
- May 2019
- March 2018
- Refactoring, Now With Generics!
- November 2017
- Packages 3.2 released!
- September 2017
- Introducing the MOTKI CLI
- July 2017
- Decoupling Yourself From Dependencies
- May 2017
- Model Rocketry Update
- April 2017
- Dynamic DNS with homedns