Self hosting in 2023
grifel.dev
grifel.dev
I host a lot of weird crap on my living room server including a publicly available Internet search engine, and server administration wise it's not a lot of work at all. The search engine requires a fair deal of babysitting, but that's on me for building shitty admin tools.
It's also great to have a beefy always-on computer to run compute jobs flooring all cores of the CPU for 200 hours on and not have to worry about bills later. Like I can't recommend this enough. There's so many cool projects gated behind taking more than a few hours to process.
What does give me a hassle is hosting stuff I didn't build myself though. Like gitea. Got a bunch of bots signing up creating spam profiles. I think as a rule I'd recommend against hosting anything that offers comments or sign ups. Cloudflare helps, but only just.
It is not a lot of work at all, I update the Gitea lib a few times every year and its as simple as replacing one binary file.
[1] For example, distro upgrades. Have a distro that somehow promises no breakage? Good! Now I can spend hours to migrate to that distro and learn all its quirks only to find that the promise didn't actually hold.
I also think it's perfectly fine if my site is down for a day or so because I'm away on travel and it's gone offline. 89.9999% has five nines as well.
I think this is the key takeaway: host at home unless you want good uptime.
I don't host from home when I want the page to be available even if:
1. There's a power outage at my home
2. I need to e.g. change a lightbulb, so I have to turn off the power (and therefore my router and server)
3. Someone accidentally switches off either the router or server
It doesn't even really take much to get 99.999% uptime from a home server. I have my server, cable modem, router, and firewall plugged into a small UPS that can keep everything going for about 30 minutes if the power goes. I've never had downtime due to power interruptions.
If I lived in an area where the power was less reliable, I'd use a bigger UPS.
In order for someone to accidentally switch off a critical piece of equipment, they'd have to go to my closet and remove all of the boxes and other crap I have stacked in front of it in there. Not likely to happen by accident.
To me they are definitely pets and I love them for it.
For me it's now more about always having it in the back of my mind that I should do regular updates, make sure the disks are fine and everything is healthy. If something goes wrong the first thought will be "something broke" and not "oh I guess the provider has some issues, let's try again later". Or if in a few years I don't want to do it anymore I know I'll always postpone moving it to a provider because it'll be a hassle.
There's just so many other things to worry about or work on that I don't want to also add time to make sure my email server is running.
I wonder if this might not cause some enthusiasts to go for far more complicated set-ups than they really need, which in turn causes a bit of a hang-over when they have less time for the "hobby".
> There's just so many other things to worry about or work on that I don't want to also add time to make sure my email server is running.
I'd argue that of all the things you could self-host, email is probably among the ones where the juice is least worthy of the squeeze. It legitimately is a constant pain in the ass from set-up to the daily operations.
All of that can be easily automated. If my system starts getting flaky, I get an email telling me well before it actually fails. Theoretically, if an automated update fails, I'll be notified of that as well, but that hasn't happened in 15 year or so, so it's been a while since it was tested.
Security, as well, is a very deep rabbit hole that can be hard to really get your head around unless you have specific training in it. I "self" host some stuff on a public-facing VPS but there are a couple of services I have moved back to third-party hosting because I had persistent anxiety about unexpected downtime or data breaches.
> It's also great to have a beefy always-on computer to run compute jobs flooring all cores of the CPU for 200 hours on and not have to worry about bills later.
What do you mean not having to worry about bills? Presumably flooring your CPU for 200 hours would generate a hefty enough electricity bill or am I misunderstanding?
Not as much as you'd think. Looking at my power bills, the difference between a month with a relatively idle server, and a month with a very busy server somewhere around 30 KWh. As a year average, the server has added about 60 KWh to my consumption.
[1] https://www.statista.com/statistics/1338657/average-internet...
Did they have CGNAT in 2003? Because that breaks everything.
Of course, IPv6 is its own can of worms, but (cross my fingers) it's working for me.
For me it broke online gaming. Luckily my ISP simply gives a static-ish IP to anyone who has an issue with CGNAT. But some ISPs force you to pay for a static IP, and some don’t even offer static IPs. I mean, I’d pay, but soon that won’t even be an option. It’s scary.
Even better if you have e.g. a Linode or any server with a public IP that can run Wireguard or OpenVPN. Then you can run your own VPN server, configure your DNS, and connect to anything from anywhere.
Yggdrasil (https://yggdrasil-network.github.io/) is also another interesting IPv6-based solution - I have played with it a bit, but I still prefer to use my VPN, and do nginx reverse proxy from my Linode to my network over VPN when needed.
Web servers like Caddy automate this for you: you just indicate that you want HTTPS for a particular site and the rest is taken care of for you (in the case of public sites and HTTP-01 challenges, at least). Link: https://caddyserver.com/docs/quick-starts/https
Even Apache2 has mod_md which does pretty much the same thing (sans DNS-01 provider integrations, at least out of the box), so it's going to be good enough for most cases and similarly easy to Caddy. Link: https://httpd.apache.org/docs/2.4/mod/mod_md.html#mdomain
Nginx integrates well with certbot, which does take a bit more work and configuration, but even that is passable: https://certbot.eff.org/
Things can get a bit tricky when you want to run your own CA or ensure mTLS, but in most cases neither will be necessary.
As for whether you even need HTTPS in the first place, I'd say that it won't hurt in most cases and will guard against MitM, the ISP included.
example.com {
tls {
issuer acme {
disable_http_challenge
}
}
file_server
}
[0] https://caddyserver.com/docs/caddyfile/directives/tls#acmeMy ISP also put me behind CGNAT, which effectively meant that all of the inbound traffic got dropped. I worked around that by getting the cheapest VPSes that I could find and then setting up WireGuard and simply forwarding the traffic to my homelab servers. So I got all of the compute that I have available locally, all of the RAM and all of the cheap HDD storage, but a static IP address.
I actually wrote about the process a few years ago: https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
(note that you probably would only want to forward 80 and 443 ports in most cases, not everything; outside of testing boxes)
Personally, I opted for Time4VPS in the end, which I use for the rest of my hosting as well: https://www.time4vps.com/linux-vps/?affid=5294#annually (affiliate link, they do have good discounts at the moment for yearly billing, though)
Then again, something like Scaleway Stardust instances could also be a really good fit, when they are available: https://www.scaleway.com/en/stardust-instances/
For those not chasing after the savings of a few Euros, Hetzner is also going to be more than enough: https://www.hetzner.com/cloud (or DigitalOcean, or Vultr, or any other VPS provider out there)
Also, if I have a VPS, why not just serve from the VPS?
Took me 15 minutes.
https://developers.cloudflare.com/cloudflare-one/connections...
An ISP I've used in the past hasn't allowed self hosting on a standard plan but has allowed on a plan you need to ask for specifically.
In Taiwan I get 1gbps down, no caps, and a bunch of weird networky config stuff I don't quite understand but apparently you don't get in the usa, for like 30 usd/month. It's awesome.
Plus I'm torrenting basically 24/7 and my isp just doesn't give a fuck. When I did that in the usa Comcast sent me an email for every single torrent lol. My download is in the tens of terabytes a month and uploads are at least a terabyte a month. ISP doesn't care. Love it.
I would also say that if you only want a static site the OPs setup is almost overkill. Just install caddy and a dyndns service. Takes care of the certificate for you and is super simple to setup.
Also, for those that don't know, Caddy also automates SSL certs (unlike nginx) and can render markdown files using templates [0].
[0]: https://caddyserver.com/docs/caddyfile/directives/templates
I also use a VPS for services intended for the general public.
Is it common for EU countries to not have symmetric gigabit fiber?
For example, at my last house (Melbourne), a 100/40 FTTC connection... the NBN company kept on having multi-hour outages (booked ahead of time) every 2-3 months. Note that's not my ISP, it's the NBN itself. For "upgrades" in the area and similar.
So very much "not business grade". Not even startup grade really. :(
Yup. I have a gigabit fibre right up to my home, but the best speed available to me as an individual is 400/40. Gets really annoying from time to time when I need to upload like a couple of gigabytes.
On the bright side it's like €30/month, which also gets me cable and some streaming service subscriptions (HBO Max, Tidal, shit like that), which from what I can tell is a pretty good deal compared to more western countries.
I'm in the US and have never not had something or other being served on public facing ports
It's trivial to host a static site on someone else's infrastructure for very cheap or free, and you get to benefit from CDNs if you need it. I don't see what you would gain from doing this from your home network.
edit: this way, you get a free IPv4 (static) address as well, as well as security and avoiding DDoS on your home connection.
What's a bit iffy is the privacy aspects. If you host anything that can identify you, your identity is just a HTTP request away for anyone who sees traffic from your IP address.
But these concerns can be somewhat mitigated by making the server drop connections unless a known Host header or SNI is sent.
Wholly recommended if you host stuff on your hope IP!
Easily done with nginx by ensuring all server {} blocks have a proper server_name and a separate default server {} block just having return 444. So unless someone already knows the domain name of your home server, they'll not be able to access it with just an IP address. You'll stop many bots this way, too.
run it behind Cloudflare
DDoS is probably mitigated at residential ISP level. At least I never had to deal with it with the current ISP I had for 14 years, and I had like 10 MBit/s upstream bandwidth most of that time.
The security aspect is a struggle. Something like shellshock [1] needs to be patched immediately, which really requires automation. With shellshock, even self-hosted static hosting could be impacted. Similar vulnerabilities be discovered in the future.
I'd want to isolate anything external facing from the rest of my home network for that reason.
[1] https://en.m.wikipedia.org/wiki/Shellshock_(software_bug)
Or if it's a static rendered website you can publish on GitHub Pages for free and use a CNAME to use a custom domain which is what we do for our docs https://docs.servicestack.net created with https://vitepress.vuejs.org that uses GitHub Actions to automatically build and publish the site on commit.
That's not to say that a VPS in addition isn't useful or fun. https://indieweb.org/POSSE and all. It just isn't at all required.
In most case the main factors to choose self hosting are independence, fun and learning by tinkering. That’s three items that GitHub Pages doesn’t provide.
Renting slices of someone else's shared HW hardly compares in terms of price to owning the full machine. Expected lifetime of some cheap SBC you'd use for hosting your personal projects is ~10 years. It can cost say EUR 50-100 to run it that long these days. 10 years of that hetzner VM is EUR 577. That's 500 EUR I can do something else with per machine.
Whenever I try calculating HW ownership vs renting in the "cloud" for personal usecases it at worst comes up to paying off in a year, and usually sooner.
There are also many other benefits of having physical access to the HW.
Just right now about 7 SBCs I run have total cost of ownership at $20 on average each and I've been running them for 5-7 years...
Reminder that if you are going to do this, then it has to lie within the subset of uses deemed acceptable by the GitHub terms, which forbids hosting on GitHub Pages for e.g. e-commerce or any other business reasons; GitHub Pages is not a 1-to-1 substitute for e.g. Cloudflare Pages or Netlify.
Yeah... I'm not surprised the author gave up on it, but you absolutely do not need to use k8s if you're dockerizing something like a blog. I'm a little baffled at this sentiment.
I don't think this is overkill, I think it's necessary. A UPS is pretty cheap compared to the completely-uncontrollable chance of losing power in the middle of working on something. Sure, there's autosave and most things are relatively recoverable, but this is just such a cheap investment (at least, for most people who will be reading this forum, I understand it isn't for everyone) compared to such a scary reliance on something that is not very reliable (which makes me very upset about income disparity, it's something everyone should be able to have).
My power is extremely unreliable so maybe I'm a little biased - we get brown-outs (power drops for maybe 2 seconds and comes back) maybe 3-4 times a year, which is wild imo for what should be a very well-developed area (relatively wealthy suburb of Chicago) but it's a pretty old building so not too surprising I guess. That said I will NEVER have a desktop setup with a UPS, and I encourage absolutely everyone to do the same.
I also have a wireless card so that in an emergency I could tether my pc to my phone for internet if need be, and I highly recommend this as well. It's enough to reconnect and send a couple Slack messages quickly and then disconnect again and wait out an outage, without driving up your data bill. (Just use your phone? Maybe, but I don't have everything installed, and I can't type for shit on my phone keyboard anyway)
Our little town of 6,000 or so loses power 3-4 times a year. One road with lots of ash trees loses power 10x a year.
People are beyond UPS here and into generators.
I'm using a laptop as a server and will buy a UPS for my modem/wifi. That combo will offer many hours of uptime without power.
I use a UPS and log2ram (which moves the most active directories to a RAM-disk) and have found the Pis to be perfectly fine home servers:)
If you have a beefy enough one (we're talking $200+ UPSs here), you can use it to power a modest refrigerator for a bit, getting temps back down to proper levels to prevent food spoilage if you end up with a long term outage that spans 48-72 hours. Most fridges only pull 120-180W when they run, and depending on the temp and time of year, only run the compressor for 15 to 20 minutes at a time. Plugging the fridge into it once or twice on the 2nd and 3rd day of an outage can save you a TON of grief and food spoilage.
However, those lead acid batteries don't last forever, and when they fail you're worse off than using a dumb regular surge protector. Now you have to replace and responsibly recycle the battery.
For me that e-waste became impossible to justify. A couple of power outages a year is completely acceptable for most home servers.
Why txt? Because I only have 600kB down & 200kB up, and even if I can share websites with images (webp) and other files (fonts, css...), my connection is too bad to be able to share this kind of content to hundreds of visitors, like the hundreds of visitors HN is bringing to my website when I share a post and it reach the front page (with a peak of 75k unique visits on a txt file in one day, that's nearly 1 visit per second, if 2 or 3 people are visiting some of my bigger pages, then my upstream connection is all taken by the visitors).
On top of that, robots that are crawling my websites are a real pain; out of the 7k requests I got yesterday on all my websites, nearly 6k are from crawlers (and 500 from bots trying to break my websites), that's ~75MB of data. Some of them are spamming my websites with 1 request per second for hours, so I created a new rule to ban them using fail2ban.
But even with all of this, selfhosting feel liberating ; I own my data, all of it is saved here in my house, I control my server (an old refurbished dell optiplex fx160 with 3 gigs or ram, an intel atom 220, and an old hdd of 500GB), and my websites are still faster than the vast majority of the web.
I found it's really nice to store those text data in txt files instead of a database.
The point of the txt thing (at first) was to show a friend that you can start a blog right away with only some txt files (he wanted to start a blog, but he started right away to worry about the time to setup something). In the end I used this txt thing to share posts to a broad audience without clogging my connection too much.
Self hosting is rarely complicated. It's also easy to achieve better performance and lower cost in many situations.
https://www.reddit.com/r/selfhosted/
Setting up your own DNS like pihole and a personal vpn to enable you into your home network when outside is usually a good starting point. Or even simpler and potentially useful setup your own gitea instance, it's easy just use the sqlite backend.
I'm fortunate in that I have a static IP. Initially I was using NOIP and it worked great but then noticed my IP address never changes. Also, NOIP still exposes your actually IP which I didn't care for.
Now instead of NOIP I rent a cheap $4/month VPS with nginx to reverse proxy to my home. This does require me to open a port, which again I'm not a huge fan but it is what it is.
My next iteration will be where I close the port and do updates via SSH. I'm the only one who uses my website so it is more of a playground for me than anything.
Finally, I feel setting up a server - or just interacting with a remote computer, be it across town, across the country or in the other bedroom, is a good skill to have. When I got my 1st remote job that gave me access to a server I was more than comfortable to do what I needed to do.
And you are absolutely right about the laptops and I have 2 right now that are just collecting dust. But currently I have no reason to change to a laptop. It is kind of like driving a nail in the wall with a sledge hammer, sad to say a laptop is more than I need in a server at this moment. The only benefit I get from a laptop for my current needs is a built in battery backup.
Avoids punching a hole in your local network, avoids issues when your home IP changes, and ensures nothing ends up going over the internet in the clear.
The last you want is for your setup to be compromised, be used to send spam/botnets and then getting perma-banned from your ISP.
I would argue it's a lot less risky just to put your static site on S3/Github etc.
Really easy to setup/use and means you don't have to open up ports like 22 which are constantly being port scanned.
You can also do things like firewalld off (or with hosts.allow) 22 to just an ssh bastion/jumphost src (or your house IP), but I find that’s usually not necessary (although an excellent further step if you are a bit paranoid) as long you do what was mentioned in first paragraph.
While you shouldn't skip on other security measures, there's no real downside to changing your SSH port and getting off the target list for a lot of botnets.
(As opposed to e.g. port knocking, which is stronger but makes it easy to lock yourself out and may create issues with some SSH clients.)
This was merely weeks after telling him to switch to Tailscale, but it was a great learning experience.
Very hard to do and finicky to setup but at the time was suitable for my needs
And are basically free.
they just have more staff on hand to respond, run updates, and do the due diligence of checking and implementing patches.
Far more people (at least 2 orders of magnitude) end up infected with malware and become members of botnets from just clicking dumb shit. They don’t get banned from the ISP either.
I know of friends who have been banned for doing exactly this.
I've been running servers used by family and friends from my home for about 20 years now. It's never been an issue at all.
> I’ve been using Next.js for a while and hosting the apps built with it on AWS with custom express servers. One day I’ve noticed that my servers are getting red-hot while doing almost nothing, and response times got huge.
OP mentions they're hosting a static website now but must have previously been rendering a server-rendered page. It's not clear whether they explored the static-site generation support in Next.js, which would have avoided any regressions in server-rendering performance, making this a non-issue.
> Long story short the library introduced a huge performance downgrade that was not caught by existing tests. > Because benchmarks were using only Vercel’s (creators of NextJS) “Edge” infrastructure. And the bug was happening everywhere but not there.
Indeed, there was a regression, but it was not due to lack of tests as a whole. The linked threads point to issues both self-hosting (serverful) as well as on Vercel (serverless). There was a week between a fix being reported through the opened issue and a fix being placed on a canary release. Regressions will happen – the best thing is ensuring more tests are added and things are fixed quickly.
> We need alternative independent hosting to ensure that the community does not get stuck with a single provider.
You can (and will always be able to) host Next.js, both completely static (drop files in an S3 bucket) or on a server (Docker, EC2, whatever you want).
Just wanted to clarify those things. Your new site looks great, nice work.
Before anything I wanted to say that I love Next.js and I'm using it in my projects daily. It's definitely the best solution right now at the market for the project types me and my company is producing :).
In regards to the inconsistencies in the article. Yes it was a server rendered page, not this particular blog. A much more complicated project.
Also I didn't want to sound as if the regression was handled badly. Quite the opposite, as soon as I've pinpointed the issue and was able to create a good Issue in the tracker the response was very swift!
And I understand that the regressions will keep on happening. I've been building apps for long enough to see waaaaay bigger problems slip into production. So no hard feelings!
Where I live, both the electric grid and Fibre connections are unreliable, and the ISP charges about $3/month for a static IP. Assuming 2.5W for a RPi, it takes 1.8kWh a month, costing around $0.25 for electricity. This also has the downside of using residential IPs, having to deal with CGNAT/NAT if the ISP has no static IPs, exposing your home IP, slow disk speeds in SBCs, etc.
Services like Hetzner have private servers for almost the same amount, which gives you faster storage, server IP addresses (for email reputation), DDoS protection, and a whole lot more to sweeten the deal.
The only thing I self host today is a script that runs on my OpenWRT router, that uploads the probed data from my inverter and BMS to monitor my PV setup. I look forward to get rid of it too, once I get better BMS/Inverter.
I've been running a few web bootcamps in the past. Explaining the hardware part through cloud admin panels is extremely hard. Having a physical thing right in front of you is spoko simple. Much easier for people to *click.
For production purposes, a public cloud has many benefits you can't get at home. But for hobby purposes, keeping the cost low is most important for me.
1. https://forums.servethehome.com/index.php?threads/lenovo-thi...
This is why I do the portion I host at home. That, and keeping the data on machines I actually own and control.
I deployed a GRE tunnel to a small box I rent from Hivelocity that has a /26 routed to it, to work around lack of proper connectivity from a "business" HFC connection to said garage.
OTOH, if you have to deal with double NAT, good luck with that hot garbage.
Anyway I'm not paying in/out costs or costs for static hosting. Looking at hetzner's offerings it apears to be 536.58 euros/month for 10tb of storage? That's block storage on SSD, maybe they have cheaper HDD storage somewhere?
Point is I think my server setup may have "paid for itself" (not that it makes me money) after one month. And that's for 38TB total of RAIDZ1 space, I'm only filling 20TB so far of it. In actually it's like 60 something TB of space lol I just wanted RAID so I could lose a drive. I've got plenty of room to grow and swap components as needed.
Note that it's virtually free in winter (or cheaper if you have a heat pump or only heat during off-peak hours) as the energy used by the RPi is that much energy not consumed by heaters
I don't host my pages myself, but the server(s) I have power the invisible infrastructure which accelerates my life a lot.
The resulting infra is hidden, because it doesn't flow through any popular services or something. You can argue that Syncthing is using public discovery servers, but you can put it on a small VPS, and you'll have a complete off-the-grid installation of it, too.
I host it on an OrangePi zero, so it's unobtrusively small. It just vanishes somewhere at home.
Does anyone know if that is accurate? What could possibly be taking up that 30 GB if all I want to do is host a static site and maybe Deno or Node? I'm fairly certain I set something similar up in the past on a much smaller MicroSD card...
Stories like these just go to show me how much fat there is in Tech. The sector is in for a sharp reality check. You don't need 10s of gigs of RAM and 20 cores to host your blog or small business e-commerce site. But if you use the latest bullshit framework then maybe you do...
(developer of Coolify here)
The blog that you are currently reading has a perfect
PageSpeed score 100 / 100.
Unfortunately, no it doesn't. The page that has this blog post scored 95 in performance for mobile in one run and 86 in the next. It scored 91 for desktop.They'd get a higher score by adding text compression and by serving static assets (all of them?) with an efficient cache policy.
PS I get 100 consistently for your home page, so maybe you have an optimization there that can be replicated?
You can still use NextJS - just get it to prerender the entire site statically. Then you get the plus sides of using NextJS, but can take your static ZIP file of files to any host you like, or self host.
You then get, for example, an HTML file, with all the elements ready on page load, which can be 'rehydrated' when React kicks in for deep functionality and interactivity.
I have a netxjs based discussion forum in development. Is it as straightforward as issuing a command to pre-render and then the site re-hydrates via Apollo on it's own ?
For HN for example, you could prerender much of the content including latest comments and get Next to keep it up to date, cache invalidating as necessary. Basically have it rebuild static pages as posts are made. Then use fetch calls or maybe sockets to get the very latest posts and keep it up to date, even live updates if you wish.
ISR is the jargon here: https://nextjs.org/docs/basic-features/data-fetching/increme...
It is a bit like a mirror of what HN does. HN will use caching so that if you are logged out you get fast renders of pages. Instead of caching, you are pregenerating and keeping it up to date.
Say you have a useEffect that calls an API: maybe firebase or parse. That useEffect only gets run on the client. For the server side render: it runs the react code based on the initial props and takes that first rendering and creates the static html from that. When that static html is run on the browser it will run react and subsequent renders can update the dom.
Hopefully I didn't just miss it in the article, but... how?
https://tuxcare.com/patch-raspberry-pi-systems-without-a-reb...
Also I think you can use Ubuntu PRO on the pi, which includes Livepatch.
Also, I think that the base Linux kpatch tools are open source, but the infrastructure that RedHat/SUSE/Canonical/etc use to provide them are not. However, I think the Gentoo folks do have some open infra code.
https://github.com/dynup/kpatch https://wiki.gentoo.org/wiki/Elivepatch https://wiki.gentoo.org/wiki/Live_patching https://github.com/gentoo/elivepatch-server https://github.com/gentoo/elivepatch-client
I use
Fujitsu D3417-B1
Xeon e3-1225v5
32GB DDR4 ECC
Samsung 980 Pro 2TB (with up-to-date firmware)
Pico PSU 150w
and it is using 9.3W in Idle and about 12W running my daily services. It can even run a macOS VM for experimenting / software development, USB-Passthrough, Replication, etc. etc.It is rock solid stable, not too power hungry, can run nearly ANYTHING and I never looked back.
We ended up using the REST API for automated provision management and there are certainly warts. It's a far cry from being a turn-key solution, which I'd argue is preferred by a large enterprise.
It's great for click-ops if that's your use case, but that also wouldn't qualify as an enterprise use case.
Not to mention that most “dynamic” IPs change only while the router is offline and your lease is up. So as long you don’t power it off, it may not change for large intervals of time.
I think a design where you rent a cheap $5-$10 vps with a static IP that forwards SMTP messages both ways through a secure tunnel to your personal mail server in your home would be a good starting point for self hosting.
Impossible! I'm reliably informed that frameworks are "battle-tested" and I'm being cavalier by doing something simpler that's sufficient for my use case.
An easy workaround is setting up a $5/mo VPS to act as a bastion host and relaying all your traffic through that.
My setup has nginx config files for each of the subdomains, each of which does a proxy_pass to some port for whatever the service is. Then my server box hosts like 20 different services, all of which right now I just point to from google domains using dynamic dns.
So instead I would have requests go to... what, an nginx I host on cloudflare?
If you don't want to rely on Cloudflare you can also rent a cheap VPS which you could use as a public reverse proxy which points to your internal reverse proxy through a vpn like a self-hosted wireguard or a service like tailscale. I just did this same exact setup and only had to add some nginx config to get the real IP address of the client instead of the public reverse proxy's.
Either way your own network is safe and hidden from the public.
So I threw a 32 core xeon server in there. It's isolated enough that the fan noise doesn't carry, and nothing I can do will make the core temps go over 28C. Free cooling during the summer, and in the winter, waste heat from the server helps keep the cold from leeching into the rest of the basement. It's really a beautiful solution.
The server itself runs proxmox, and I've got four or five services exposed to the internet behind an nginx proxy. Most of the time I don't ever have to touch it.
The -only- thing I don't host at home is my email server. Mostly because it's very old and I don't want to upset it, but also email behind a residential IP can be painful.
Everything I host is just for my personal use, and it's been a pretty worthwhile experience. It doesn't take too much of my time, I get to learn new skills, and at the end of it, I get a service I was going to use anyway, but I have absolute certainty that my data is under my control and no one else need be involved. It's nice.
I still need to figure out long term backups, but for now I periodically dump to an external drive and store it in a fireproof safe in the same room. That's as secure as I can get in this environment and I think it's good enough.
It's just one command.
What are the cheap options for RPI? I'v read that powerbanks are not designed as UPS and have no passthrough charging: https://goughlui.com/2021/09/03/note-potential-issues-of-usi...
It's not a hassle. Setup once and then forget about it. It's dead simple, easy and there's a million tutorials on it online.
But it's boring (this is where I'm going to old-man-ramble about things, so better stop reading now). Imo, that's why we have so much bloat, complexity and overkill use of containerization that requires orchestration in software and devops. We don't go the easiest possible route, but the one that seems interesting and most fun.
I totally get playing with new stuff and going totally over board just to host a static html file for a personal project, with the goal to learn something new. But it's not just personal projects, it's whole companies that adopt this kind of approach, not even thinking 2 years ahead, when the "cool new software" you used is now not only not cool and new anymore, but abandoned and unmaintained.
I get that this is just a random "i did a thing" blog post, but this just annoys me :(
Honestly I thought only friends and family would read it and I didn't spend enough time polishing the nuances in the writing. I didn't expect it to blow up so much :D.
But going back to the point I fully understand your frustration about the overcomplicated approach. Though for my defense I'm planning on hosting many more apps using this setup. In fact I already am but didn't want to overcomplicate the post.
I left it for part 2. Subscribe RSS for followup xD. I feel like a YouTuber after saying that.
Honestly I just feel awesome seeing those blinking lights in my room and thinking it's sending packets to other people.
In my experience it's not much harder than navigating the AWS interface, where I often feel very lost. But of course YMMV.
> There is no real privacy gained
Why not? Other than I can't be sure that my device and browser doesn't spy on me I don't see your point?
Not my reason to self host (static) but more a welcome side effect.
Moreover, no one can seize or examine your data without being a criminal. On the other hand, Google et al do this every day.
You may not care but these are real privacy gains
I run everything in Docker images with a single docker-compose.yml. For 99% of the folks more than sufficient and way less complex than Kubernetes. I use Caddy as a reverse proxy. Configuration is dead simple and it has auto SSL certificate renewal. Certificates are just there, you don't even need to think about it. I run it together with Authelia so that I can shield web services behind a 2FA SSO login portal. Now I can securely access my personal web services without the need for VPN.
Some things I selfhost: Nextcloud, Adguard, Gitea, Drone (local CI/CD runner, love it), VPN, Samba server, Jellyfin, a few websites, etc.
I guess IPv6 could/would solve this one day?
The solution is a tunnel between your machine and an external server with a static IP address. The external server will forward requests to your machine.
Cloudflare tunnel is an option (thanks watchdogtimer), and there's also a service called Ngrok. I took the most complicated option: setting up a reverse ssh tunnel to a VPN that I already had.
When I need to host dynamic content, another good option is CloudFlare Tunnels (I promise I'm not sponsored by them, their products are good is all :)), so you don't have to do shenanigans updating DNS records on the fly, and more importantly you don't have to compromise your network opening up and forwarding ports.
if all you want is a simple static blog, i find little to no reason behind going beyond github pages.
for self-hosting some cloud services, go for self-hosting BUT don't expose it to the internet willy-nilly. rather use tailscale or something and access it behind a vpn. if you really want to offer a public utility to others by running it in your household, it is often not worth the tradeoffs with making it secure enough.
Went from a PowerEdge 2650 in the spare room to a way smaller optiplex 3060. SO much quieter and friendlier to the power bill. Also, a lot faster too. :)
I haven't had this issue with my setup. There is a couple of minutes of downtime every few months, but when it happens, it usually happens late at night when nobody's using it anyway. It's yet to cause anyone to not be able to reach the server when they've wanted to.
This certainly depends on what ISP you're using, though.
> you’ll be blocked for hosting a web server
Again, depends on your ISP. Mine won't block you for this.
If this whole infrastructure is built just to render a static page, I can guarantee that from the point of view of someone reaching it out from Indonesia, then the PageSpeed wouldn't matter. It would be super slow.
In fact https://gtmetrix.com/reports/grifel.dev/KDVSwSmr/ shows that render time of your page is 1.8s and TTI is 1.2 sec. Which is 4X times of what PageSpeed shows.
I host my blog on CF Pages, and my front pages loads is subsecond time (around ~725 ms actually). This incurs no electricity bills or any additional costs to me. And it's aggressively cached, compressed and also distributed on Edge Cache. Which is literally impossible with RPI at home.
I don't see why it's a weird post.
They will also flush everything connected to your Google account down the drain the moment their AI decides you violated some of their terms of service. With no possibilty to restore or recover.
Why bother self hosting at home when you can just do it for real by paying the same price as an internet connection?
Just used 10mins of my lunch break to go from 9x to 100 myself. Thanks for the reminder ;)
(Developer of Coolify here )
- Mileage may vary. I see plenty of people self-hosting their SearX(NG), Miniflux, Wallabag, Grafana, PiHole instance on a RPi at home. And that works perfectly fine: those services are relatively lightweight, they don't take more than a few tens of MBs of RAM, installing them is usually as easy as a docker pull, and they aren't too bandwidth-hungry for a decent home connection. Jellyfin? Sure, but streaming high resolution content may warm up the RPi quite a bit. NextCloud? Hmm, it starts to be a bit borderline for a RPi at home - especially if you don't add some decent fast external disks. Matrix? Hmm, that starts to be a heavy beast - and if you decide to federate your server it may eat a lot of bandwidth and disk space. Mastodon, or anything involving federation on scale? Unless you're ready to add a few GB of storage every couple of weeks and can receive and content very fast, it may be a problem (and it also takes 1.5 GB of RAM to run a small instance of my server). Keycloak, ElasticSearch, Kafka or any fat beast running on a fat JVM? At least 1 GB of RAM goes to run each of these beasts. Bitwarden? The latest versions will freeze everything unless MSSQL can allocate at least 2 GB of RAM at startup. So do you want to run your personal website or a few small services on your RPi at home? You can probably do it. But self-hosting other popular services will require you either more CPU power (and, in most of the cases, still an x86 architecture), more memory, more/faster disks, more bandwidth, or all of them.
- I've reached a balance where I run my small services (SearXNG, Miniflux, Wallabag, PiHole, Gitea, Grafana etc.) on a RPi. The medium ones (Jellyfin, NextCloud, Matrix, Keycloak etc.) on a Celeron mini-PC with SSD disk and ~10 TB of storage attached. Those that take >1.5 GB of RAM (like Bitwarden and Mastodon), or need to be accessible even if my house goes on fire (like Bitwarden itself, the main node of my VPN and the git server with all of my synchronized configurations), or eat up more bandwidth than my house could handle (like Jitsi), are running on a couple of Linode servers outside of my network. And, as the traffic for some of those services starts to increase, I'm even considering using Cloudflare.
- I agree with what other people mentioned in this topic: you don't need Kubernetes for everything. Sometimes Docker/Podman containers managed by systemd services are more than enough. I personally like to run Arch whenever I can - there's an AUR package literally for everything, and a wiki page for nearly everything. Then you don't need to waste extra disk space to host a lot of Docker images. All the configuration files are stored on an external git server connected over VPN. So bootstaping a system or moving/copying services is usually as simple as running a git clone and running a couple of Ansible playbooks to automate the deployment. Sure, Kubernetes can help, but it's just one among the possible tools that you have in your box.
In my experience, self hosting usually falls into two categories, people that "just want to host a simple static website", and "host all the things", and both are usually served better by using the cloud.
Most are in the category "i want to learn about self hosting", meaning they have (close to) zero experience, and while self hosting by itself isn't hard, maintaining a secure environment is, and that's where many people fail.
For the "simple static website", you can host it for free pretty much everywhere you like. Github pages, Azure static web apps, and countless others all offer stable, professional cloud servies for free, without the risk of exposing your network to the internet.
For the "host all the things", you see people attempting to mimic and entire data center at home, complete with monitoring, CI/CD and everything, and while i appreciate the learning experience, most people are blissfully unaware of the chore it is to maintain such a thing. Most of these services are better off being in the cloud.
- email is a likely thing people will want to self host, which is also perhaps the most stupid thing to do. First of all, it is a chore to keep your server off of various block lists, and you gain nothing but pain by self hosting it. Email is insecure by design. Every email has at least 2 parties, the sender and the receiver, and with >50% of the worlds recipients running on Google/Microsoft/Yahoo/whatever, your email will get indexed. A much better alternative is letting someone who knows what they're doing host your email, and use a personal domain. That way you can move your MX records if need be, still maintain your email address if changing provider, and let someone else deal with the problems of running the service. If it's privacy you want, use something else, or use encryption. In both cases, self hosting gives you nothing additional.
- cloud storage is another contender, and the most common "excuse" is that cloud hosting is too expensive, and yes, if you plan to store 200TB in the cloud then it is, but maybe instead you need to look at which files are needed when away from home, and use the cloud for those, and leave the rest at home, accessible by VPN if need be. If you need privacy with cloud file hosting, something like Cryptomator (https://cryptomator.org/) is much easier/better than maintaining your own server. (as a side note, you can get around 20TB of cloud storage for €20/month, or roughly the price of the electricity required to run a 4 drive NAS for the same time, but not including cost of hardware).
Not matter your setup at home, you will never create something as resilient as the major cloud datacenters. i.e. OneDrive (paid version) stores your files across multiple geographically separated data centers, using erasure coding, so if one data center dies, your files are still available in another center, and hastily being replicated to a third center. It uses atomic writes (like CoW filesystems, ZFS, Btrfs, APFS, etc) to ensure data written is correct, and has checksumming (inherent in the erasure coding), as well as versioning of files (OneDrive has unlimited file versioning for 30 days rolling), meaning you get at least some ransomware protection.
So in the end, most people are way better served by putting their stuff in the cloud and encrypting it, than they are exposing insecure services from home.
By all means, build the cluster at home as a learning experience, but save yourself some trouble and keep it within your LAN. If you need to access it externally, use a VPN instead. With modern VPNs like wireguard, there is very little overhead, and your data will thank you for it (as will your family as you suddenly have a lot more time to spend with them!).
> Not matter your setup at home, you will never create something as resilient as the major cloud datacenters
That's true for hardware failures, but there are weekly stories on HN about major cloud providers randomly deleting people's accounts; so you need to setup off-site backups yourself either way.
But what would you gain from it ? You gain no privacy, no improvement of service, no added resilience (probably less). All you gain is additional work maintaining your services.
> so you need to setup off-site backups yourself either way
You will always need backups regardless if self hosting or cloud hosting it, but by not opening up your firewall, you will have a much more secure home network, especially if you're not a security expert, which many people are not.
My personal mail backup consists of running a local dovecot instance that is synchronized every x hours using imapsync, and the dovecot mailstore is then backed up by my normal backup jobs every x hours. My provider does support an API for downloading a backup, but it's slower and more error prone than simply just synchronizing the email locally, and if need be, i can access my mailbox locally.
Restoring it in case of data loss or changing provider is also "easy", as i can simply reverse the imapsync.
You do:
1. You don't reply to many incoming emails, so they would never be seen by the MTA
2. Even when replying, you don't necessarily include the whole original email in your response (though that's only a very minor improvement)
3. MTAs normally don't store emails, and it would be expensive for them to do so as you aren't paying them for storage. This protects your past and present emails from the MTA turning evil (or being hacked) in the future.
> by not opening up your firewall, you will have a much more secure home network, especially if you're not a security expert, which many people are not.
Even consumer-grade routers support DMZs. With the right instructions, it's possible to only open the firewall to the server and keep it out of the home network.
Every email has a sender and a receiver, and if either of those parties are on cloud hosted email, your email will be seen by an MTA, and you can bet your life that Google/Microsoft/whatever will snatch your recipient email and catalog it.
As i said, if you want privacy use something else, like Signal for instance, or use encryption, in which case it doesn't matter where you store your emails as any information you expose is already exposed by the protocol itself (sender/recipient/topic/date/source ip/destination ip/etc).
> MTAs normally don't store emails, and it would be expensive for them to do so as you aren't paying them for storage. This protects your past and present emails from the MTA turning evil (or being hacked) in the future.
So do backups, but with much lower maintenance, and more security/resilience, simply by being "offline".
> Even consumer-grade routers support DMZs. With the right instructions, it's possible to only open the firewall to the server and keep it out of the home network.
Ask your friends what a DMZ is. I'm certain that most people on HN will know what it is, and a large share will probably also know how to set it up, but then the issues with hairpin nat, name resolution, and other stuff starts cropping up, which is where some people just give up and instead expose it from the LAN so that they may access it from home as well.
Expand the scope to also include VLANs and you have an even smaller group.
Next up is that many people will happily use the same server for exposing services to the internet as well as internal stuff, so now you're just one CVE away from having everything on your server encrypted/deleted/leaked. You can partially mitigate that by using jails/containers, but thats another layer you need to familiarize yourself with, with the risk of once again getting it wrong.
Most people would be much better off just setting up a VPN and using that to access their home network, and letting professionals worry about securing services.
Edit: I should add that i'm not against people setting up servers at home for experimenting/learning, it's only when they expose those services to the internet it bothers me.
There is certainly value in experimenting with stuff in a homelab, but when there are so many free servies available that does stuff better than almost any reasonable homelab can hope to, there is very little point in accepting the additional risk.
In the case of a "static webpage" use case, you can publish that for free with GitHub, or you can chose to expose it from home, opening up your firewall, as well as ports to your server. Congratulations, you're now a network and system administrator, as well as responsible for maintaining SSL/TLS certificates, ensuring uptime (if the webpage has value, otherwise why bother publishing it in the first place).
In the "free" package you get resilient infrastructure with redundancy on every level (power/internet, hardware, software, services), you get a professional staff that babysits services, and you don't have to worry about anything expect creating the content you want to publish.
It sucked. Cost a lot of time, and really, fiddling with firewalls and Apache configuration didn't teach me much.
All hail PaaS and the like. I'm not looking back.
One file and I can recreate my multi box self hosting setup. Why would I bother with a platform with a bunch of state?
Most PaaS type offerings for Web dev separate state and code. I can destroy and redeploy a whole cluster in two commands