Live data from Hacker News

Why Self-Host?

romanzipp.com

161–170 of 269 posts

Re: Why Self-Host?

#161

Earlier quoted context omitted.

The main thing that gives me anxiety about this is the security surface area associated with "managing" a whole OS— kernel, userland, all of it. Like did I get the firewall configured correctly, am I staying on top of the latest CVEs, etc. For that reason alone I'd be tempted to do GHA workflow -> build container image and push to private registry -> trivial k8s config that deploys that container with the proper port…

I used digital ocean for hosting a wordpress blog. It got attacked pretty regularly. I would never host an open server from my own home network for sure. This is the main value add I see in cloud deployments -> os patching, security, trivial stuff I don't want to have to deal with on the regular but it's super important.

Wordpress is just low-hanging fruit for attackers. Ideally the default behavior should be to expose /wp-admin on a completely separate network, behind a VPN, but no one does that, so you have to run fail2ban or similar to stop the flood of /wp-admin/admin.php requests in your logs, and deal with Wordpress CVEs and updates.

More ideal: don't run Wordpress. A static site doesn't execute code on your server and can't be used as an attack vector. They are also perfectly cacheable via your CDN of choice (Cloudflare, whatever).

Re: Why Self-Host?

#162
post #46

Earlier quoted context omitted.

Self hosting involves 3 steps in my life. 1) Find the docker compose file. 2) Change the expose line to make it specific 10.0.10.1:9000 instead of the default 0.0.0.0:9000 . 3) Connect via wireguard. (Answers the "security" point a sister comment brought up too)

and goodbye security...

Yes. It's implicit. Goodbye security indeed.

Re: Why Self-Host?

#163
post #72
post #46

Earlier quoted context omitted.

Self hosting involves 3 steps in my life. 1) Find the docker compose file. 2) Change the expose line to make it specific 10.0.10.1:9000 instead of the default 0.0.0.0:9000 . 3) Connect via wireguard. (Answers the "security" point a sister comment brought up too)

Not to mention the 100 steps you have to do to get their, of course...

Yes of course. The first time you try to get wireguard working you will not get it to ping the other side right away. It is a process. The next few times it'll be much quicker. Then it will keep running forever. Or maybe mine isn't working but I never noticed.

I had this wireguard setup in place long before I even ran my first docker container. It's all building on top of things already there.

Re: Why Self-Host?

#164
post #63

Earlier quoted context omitted.

Issue is network saturation. Most VPSs have limited bandwidth (1Gbps), even if their CPUs could serve tens of thousands of req/s.

You can always host your stuff on a few machines and then create a few DNS A records to load balance it on the DNS level :)

This sometimes works, sometimes not. Because of how DNS resolution works, you're totally at the mercy of how your DNS resolver and/or application behave.

Re: Why Self-Host?

#165

"start self-hosting more of your personal services." I would make the case that you should also self host more as a small Software/SAAS business and it is not quite the boogeyman that a lot of cloud vendors want you to think. Here is why. Most software projects/businesses don't require the scale and complexity for which you truly need the cloud vendors and their expertise. For example, you don't need Vercel to deploy…

The main thing that gives me anxiety about this is the security surface area associated with "managing" a whole OS— kernel, userland, all of it. Like did I get the firewall configured correctly, am I staying on top of the latest CVEs, etc. For that reason alone I'd be tempted to do GHA workflow -> build container image and push to private registry -> trivial k8s config that deploys that container with the proper port…

> Run that on someone else's managed k8s setup ... this way I'm only responsible for my application and its interface.

It's the eternal trade-off of security vs. convenience. The downside of this approach is that if there is a vulnerability, you will need to wait on someone else to get the fix out. Probably fine nearly always, but you are giving up some flexibility.

Another way to get a reasonable handle on the "managing a whole OS ..." complexity is to use some tools that make it easier for you, even if it's still "manually" done.

Personally, I like FreeBSD + ZFS-on-root, which gives "boot environments"[1], which lets you do OS upgrades worry-free, since you can always rollback to the old working BE.

But also I'm just an old fart who runs stuff on bare metal in my basement and hasn't gotten into k8s, so YMMV (:

[1] eg: https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-wi... (though I do note that BEs can be accomplished without ZFS, just not quite as featureful. See: https://forums.freebsd.org/threads/ufs-boot-environments.796...)

Re: Why Self-Host?

#166

Earlier quoted context omitted.

The main thing that gives me anxiety about this is the security surface area associated with "managing" a whole OS— kernel, userland, all of it. Like did I get the firewall configured correctly, am I staying on top of the latest CVEs, etc. For that reason alone I'd be tempted to do GHA workflow -> build container image and push to private registry -> trivial k8s config that deploys that container with the proper port…

I used digital ocean for hosting a wordpress blog. It got attacked pretty regularly. I would never host an open server from my own home network for sure. This is the main value add I see in cloud deployments -> os patching, security, trivial stuff I don't want to have to deal with on the regular but it's super important.

The thing with WordPress is that it increases the attack area using shitty plugins. If I have a WP site, I change wp-config.php with this line:

    define( 'DISALLOW_FILE_EDIT', true );
This one config will save you lot of headaches. It will disable any theme/plugin changes from the admin dashboard and ensures that no one can write to the codebase directly unless you have access to the actual server.

Re: Why Self-Host?

#167
post #28
post #14

Earlier quoted context omitted.

Why not also do the sending? Deliverability concerns?

Not OP, but yes. For personal use, you don't have enough traffic to establish reputation, so you get constantly blocked regardless of DKIM/DMARC/SPF/rDNS. Receiving mail is reliable though, so you can do that yourself and outsource just sending to things like Amazon SES or SMTP relays.

> For personal use, you don't have enough traffic to establish reputation, so you get constantly blocked regardless of DKIM/DMARC/SPF/rDNS.

Been selfhosting personal low traffic email since the 1990's, I don't have that problem.

Re: Why Self-Host?

#168

"start self-hosting more of your personal services." I would make the case that you should also self host more as a small Software/SAAS business and it is not quite the boogeyman that a lot of cloud vendors want you to think. Here is why. Most software projects/businesses don't require the scale and complexity for which you truly need the cloud vendors and their expertise. For example, you don't need Vercel to deploy…

Mostly agreed, and thanks for sharing your POV. One slight disagreement:

"No need for CDN etc unless you are talking about millions of requests per day."

A CDN isn't just for scale (offloading requests to origin), it's also for user-perceived latency. Speed is arguably the most important feature. Yes, beware premature optimization... but IMHO delivering static assets from the edge, close as possible to the user, is borderline table stakes and has been for at least a decade.

Re: Why Self-Host?

#169

"start self-hosting more of your personal services." I would make the case that you should also self host more as a small Software/SAAS business and it is not quite the boogeyman that a lot of cloud vendors want you to think. Here is why. Most software projects/businesses don't require the scale and complexity for which you truly need the cloud vendors and their expertise. For example, you don't need Vercel to deploy…

Oh you can go a lot simpler than that.

For 20 years I ran a web dev company that hosted bespoke web sites for theatre companies and restaurants. We ran FreeBSD, postgreSQL and nginx or H2O-server with sendmail.

Never an issue and had fun doing it.

Re: Why Self-Host?

#170
post #81

Earlier quoted context omitted.

This is why I built https://canine.sh -- to make installing all that stuff a single step. I was the cofounder of a small SaaS that was blowing >$500k / year on our cloud stack Within the first few weeks, you'll realize you also need sentry, otherwise, errors in production just become digging through logs. Thats a +$40 / m cloud service. Then you'll want something like datadog because someone is reporting somewhere th…

This assumes you're building a SAAS with customers though. When I started my career it was common for companies to build their own apps for themselves, not for all companies to be split between SAAS builders and SAAS users.

I enjoy the flipside... working for a company that does provides SAAS, sometimes I find myself reminding people that we don't necessarily need a full multi-datacenter redundant deploy with logging and metrics and alerting and all this other modern stuff for a convenience service, used strictly internally, infrequently (but enough to be worth having), with effectively zero immediate consequences if it goes down for a bit.

You can take that too far, of course, and if you've got the procedures all set up you often might as well take them, but at the same time, you can blow a thousands and thousands of dollars really quickly to save yourself a minor inconvenience or two over the course of five years.

Post reply on HN