11 ms·

"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

"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 NextJS or whatever static website or even netlify. You can setup Nginx or Caddy (my favorite) on a simple VPS with Ubuntu etc and boom. For majority of projects, that will do. 90%+ of projects can be self hosted with the following: - A well hardened VPS server with good security controls. Plenty of good articles online on how to do the most important things (remove root login, ssh should only be key based etc). - Setup a reverse proxy like Caddy (my favorite) or Nginx etc. Boom. Static files can now be served. Static websites can be served. No need for CDN etc unless you are talking about millions of requests per day. - Setup your backend/API with something simple like supervisor or even the native systemd. - The same Reverse proxy can also forward requests to backend and other services as needed. Not that hard. - Self host a mysql/postgres database and setup the right security controls. - Most importantly: Setup backups for everything using a script/cron and test them periodically. - IF you really want to feel safe against DOS/DDOS etc, add cloudflare in front of everything. So you end up with: Cloudflare/DNS=>Reverse Proxy (Caddy/Nginx)=>Your App. - You want to deploy ? Git pull should do it for most projects like PHP etc. If you have to rebuild binary, it will be another step but possible. You don't need Docker or containers. They can help but not needed for small to even mid sized projects. Yes, you can claim that a lot of these things are hard and I would say they are not that hard. Majority of projects don't need the web scale or whatever.

isodev 1y ago
And there is an extra perk: Unlike cloud services, system skills and knowledge are portable. Once you learn how systemd or ufw or ssh works, you can apply it to any other system. I’d even go as far as to say that the time/cost required to say learn the quirks of Docker and containers and layering builds is higher than what is needed to learn how to administer a website on a Debian server.
- neoromantique 1y ago
  >I’d even go as far as to say that the time/cost required to say learn the quirks of Docker and containers and layering builds is higher than what is needed to learn how to administer a website on a Debian server. But that is irrelevant as Docker brings more to the table that a simple Debian server cannot by design. One could argue that lxd is sufficient for these, but that is even more hassle than Docker.
  - tracker1 1y ago
    For my home or personal server stuff... I'm pretty much using ProxMox as a VM host, with Ubuntu Server as the main server and mostly Docker configured with Caddy installed on the host. Most apps are stacked in /apps/appname/docker-compose.yaml with data directories mounted underneath. This just tends to simplify most of my backup/restore/migrate etc. I just don't have the need to do a lot of work on the barebones server beyond basic ufw and getting Caddy and Docker running... Caddy will reverse-proxy all the apps running in containers. It really simplifies my setup.
    - neoromantique 1y ago
      That's essentially what I do (with a little extra step of having a dedicated server in Hetzner peered with my homelab with wireguard to use as internet facing proxy + offsite backup server). Ah, also docker is managed with komo.do, but otherwise it is simple GUI over docker-compose
      - tracker1 1y ago
        That's cool... I really should take a next step to bridge my home setup with my OVH server. It's a mixed bag, mostly in that the upgrade to "business" class from home is more than what I pay a month to rent the full server and IP block on OVH... But I've got a relatively big NAS at home I wouldn't mind leveraging more/better. Aside: I really want to like NextCloud, but as much as I like aspects of it, I don't like plenty as well.
bluGill 1y ago
A small business should onlyself host if they are a hosting company. everyone else should pay their local small business self hosting company to host for them. This is not a job for the big guys. You want someone local who will take care of you. They also come when a computer fails, ensuring updates are applied to them. Not by come I mean physically sending a human to you. This will cost some money but you should be running your business not trying to learn computers.
- codegeek 1y ago
  I meant a small software/SAAS business. I would agree with you about a non software business. Edited my comment.
- throwzasdf 1y ago
  > A small business should onlyself host if they are a hosting company. OK that's your opinion, in my view a business should selfhost if they want to maintain data sovereignty. > everyone else should pay their local small business self hosting company to host for them. That assumes all small business have at least one "local small business self hosting company" to choose from.
BinaryIgor 1y ago
Exactly; but I would rather say that you don't need CDN unless you have tens of thousands of requests per second and your user base is global; single powerful machine can easily handle thousands and tens of thousands of requests per second
- codegeek 1y ago
  Agreed. I was being generous to the CDN lovers :). Peope don't know how powerful static file servers like Nginx and Caddy are. You don't need no CDN.
  - indigodaddy 1y ago
    For me, CDN is more valuable for avoidance of huge data transfer bills from the origin host, vs the endpoint getting overwhelmed. Obviously those are related and both could happen without a CDN, but the big bills scare me more at the end of the day.
- dlisboa 1y ago
  Issue is network saturation. Most VPSs have limited bandwidth (1Gbps), even if their CPUs could serve tens of thousands of req/s.
  - BinaryIgor 1y ago
    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 :)
    - jcgl 1y ago
      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.
  - Sohcahtoa82 1y ago
    Even 1 Gbps is plenty to handle 1,000 connections unless you're serving up video. That's 1 Mbps per user. If your web page can't render (ignoring image loading) within a couple seconds even on a connection that slow, you're doing something wrong. Maybe stop using 20 different trackers and shoving several megabytes of JavaScript to the user.
kijin 1y ago
> No need for CDN etc unless you are talking about millions of requests per day. Both caddy and nginx can handle 100s of millions of static requests per day on any off-the-shelf computer without breaking a sweat. You will run into network capacity issues long before you are bottlenecked by the web server software.
- whatevaa 1y ago
  Network capacity and geo-proximity are the issues, not number of requests.
czhu12 1y ago
This is why I built https://canine.sh 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 that a page is taking 10 seconds to load, but you can't replicate it. +$300 / m cloud service. Then, if you ever want to aggregate data into a dashboard to present to customers -- Looker / Tableau / Omni +$20k / year. Data warehouse + replication? +$150k / year This goes on and on and on. The holy grail is to be able to run ALL of these external services in your own infrastructure on a common platform with some level of maintainability. Cloud Sentry -> Self Hosted Sentry Datadog -> Self Hosted Prometheus / Grafana Looker -> Self Hosted Metabase Snowflake -> Self Hosted Clickhouse ETL -> Self Hosted Airbyte Most companies realize this eventually and thats why they eventually move to Kubernetes. I think its also why often indie hackers can't quite understand why the "complexity" of Kubernetes is necessary, and just having everything run on a single VPS isn't enough for everything.
- threetonesun 1y ago
  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.
  - jerf 1y ago
    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.
mikepurvis 1y ago
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 ports exposed. Run that on someone else's managed k8s setup (or Talos if I'm self hosting) and it's basically exactly as easy as having done it on my own VM but this way I'm only responsible for my application and its interface.
- cyberax 1y ago
  You can mitigate a lot of security issues by not exposing your self-hosted stack to the Internet directly. Instead you can use a VPN to your home network. An alternative is a front-end proxy on a box with a managed OS, like OpenWRT.
- oxalorg 1y ago
  I left my VPS open to password logins for over 3 years, no security updates, no firewalls, no kernel updates, no apt upgrades; only fail2ban and I survived: https://oxal.org/blog/my-vps-security-mess/ https://oxal.org/blog/my-vps-security-mess/ Don't be me, but even if you royally mess up things won't be as bad as you think.
  - Matumio 1y ago
    I've had password login enabled for decades on my home server, not even fail2ban. But I do have an "AllowUsers" list with three non-cryptic user names. (None of them are my domain name, but nice try.) Last month I had 250k failed password attempts. If I had a "weak" password of 6 random letters (I don't), and all 250k had guessed a valid username (only 23 managed that), that would give... uh, one expected success every 70 years? That sounds risky actually. So don't expose a "root" user with a 6-letter password. Add two more letters and it is 40k years. Or use a strong password and forget about those random attempts.
  - m463 1y ago
jstummbillig 1y ago
I think this is a moderately good idea, if you are certain that you want to remain involved with the business operationally, forever. It's still not ever a great idea (unless, maybe, this is what you do for a living for your customers), simply because it binds your time, which will absolutely be your scarcest asset if your business does anything. I am speaking from my acute experience.
thewebguyd 1y ago
> Majority of projects don't need the web scale or whatever. Truth. All the major cloud platform marketing is YAGNI but for infrastructure instead of libraries/code. As someone who works in ops and has since starting as a sysadmin in the early 00s, it's been entertaining to say the least to watch everyone rediscover hosting your own stuff as if it's some new innovation and wasn't ever possible before. It's like that old MongoDB is web scale video (https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs) Watching devs discover Docker was similarly entertaining back then when us in ops have been using LXC and BSD jails, etc. to containerize code pre-DevOps. Anyway, all that to say - go buy your gray beard sysadmins a coffee let them help you. We would all be thrilled to bring stuff back on-prem or go back to self hosting and running infra again and probably have a few tricks to teach you.
Sohcahtoa82 1y ago
Everything you said 110% I wish I understood why some engineers feel the need to over-engineer the crap out of everything. Is it because of wishful thinking? They think their blog is gonna eventually become so popular that they're handling thousands of requests per second, and they want to scale up NOW? I just think about what web servers looked like at the turn of the millennium. We didn't have all these levels of abstraction. No containers. Not even VMs. And we did it on hardware that would be considered so weak that they'd be considered utterly worthless by today's standards. And yet...it worked. We did it. Now we've got hardware that is literally over 1000 times faster. Faster clocks, more cache, higher IPC, and multiple cores. And I feel like half of the performance gains are being thrown away by adding needless abstractions and overhead. FFS...how many websites were doing just fine with a simple LAMP stack?
chrisweekly 1y ago
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.
- eddieroger 1y ago
  You're right, including your warning of premature optimization, but if the premise of the thread is starting from a VPS, user-perceived latency shouldn't be as wild as self-hosting in a basement or something because odds are your VPS is on a beefy host with big links and good peering anyway. If anything, I'd use the CDN as one more layer between me and the world, but the premise also presupposed a well-hardened server. Personally, the db and web host being together gave me itches, but all things secure and equal, it's a small risk.
assimpleaspossi 1y ago
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.
- whatevaa 1y ago
  How interactive are those sites?
deleted 1y ago
[deleted]
noduerme 1y ago
Are you talking about the VPS just serving as a reverse proxy and running the server on-prem or at home? Or are you having a reverse proxy on some VPS with a static IP send connections to other VPSs on a cloud service? I've self-hosted toy apps at home this way, with a static IP VPS as a reverse proxy in the middle, and it is indeed easy. With Tailscale you don't even need a static IP at home. A gigabit connection and a $100 box can easily handle plenty of load for a small app or a static site. To me, the reason I would never put something like that into production even for a very small client is, even in a fairly wealthy city in America, the downtime caused by electrical outages and local internet outages would be unacceptable.

isodev 1y ago

And there is an extra perk: Unlike cloud services, system skills and knowledge are portable. Once you learn how systemd or ufw or ssh works, you can apply it to any other system. I’d even go as far as to say that the time/cost required to say learn the quirks of Docker and containers and layering builds is higher than what is needed to learn how to administer a website on a Debian server.

neoromantique 1y ago
>I’d even go as far as to say that the time/cost required to say learn the quirks of Docker and containers and layering builds is higher than what is needed to learn how to administer a website on a Debian server. But that is irrelevant as Docker brings more to the table that a simple Debian server cannot by design. One could argue that lxd is sufficient for these, but that is even more hassle than Docker.
- tracker1 1y ago
  For my home or personal server stuff... I'm pretty much using ProxMox as a VM host, with Ubuntu Server as the main server and mostly Docker configured with Caddy installed on the host. Most apps are stacked in /apps/appname/docker-compose.yaml with data directories mounted underneath. This just tends to simplify most of my backup/restore/migrate etc. I just don't have the need to do a lot of work on the barebones server beyond basic ufw and getting Caddy and Docker running... Caddy will reverse-proxy all the apps running in containers. It really simplifies my setup.
  - neoromantique 1y ago
    That's essentially what I do (with a little extra step of having a dedicated server in Hetzner peered with my homelab with wireguard to use as internet facing proxy + offsite backup server). Ah, also docker is managed with komo.do, but otherwise it is simple GUI over docker-compose
    - tracker1 1y ago
      That's cool... I really should take a next step to bridge my home setup with my OVH server. It's a mixed bag, mostly in that the upgrade to "business" class from home is more than what I pay a month to rent the full server and IP block on OVH... But I've got a relatively big NAS at home I wouldn't mind leveraging more/better. Aside: I really want to like NextCloud, but as much as I like aspects of it, I don't like plenty as well.

bluGill 1y ago

A small business should onlyself host if they are a hosting company. everyone else should pay their local small business self hosting company to host for them. This is not a job for the big guys. You want someone local who will take care of you. They also come when a computer fails, ensuring updates are applied to them. Not by come I mean physically sending a human to you. This will cost some money but you should be running your business not trying to learn computers.

codegeek 1y ago
I meant a small software/SAAS business. I would agree with you about a non software business. Edited my comment.
throwzasdf 1y ago
> A small business should onlyself host if they are a hosting company. OK that's your opinion, in my view a business should selfhost if they want to maintain data sovereignty. > everyone else should pay their local small business self hosting company to host for them. That assumes all small business have at least one "local small business self hosting company" to choose from.

BinaryIgor 1y ago

Exactly; but I would rather say that you don't need CDN unless you have tens of thousands of requests per second and your user base is global; single powerful machine can easily handle thousands and tens of thousands of requests per second

codegeek 1y ago
Agreed. I was being generous to the CDN lovers :). Peope don't know how powerful static file servers like Nginx and Caddy are. You don't need no CDN.
- indigodaddy 1y ago
  For me, CDN is more valuable for avoidance of huge data transfer bills from the origin host, vs the endpoint getting overwhelmed. Obviously those are related and both could happen without a CDN, but the big bills scare me more at the end of the day.
dlisboa 1y ago
Issue is network saturation. Most VPSs have limited bandwidth (1Gbps), even if their CPUs could serve tens of thousands of req/s.
- BinaryIgor 1y ago
  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 :)
  - jcgl 1y ago
    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.
- Sohcahtoa82 1y ago
  Even 1 Gbps is plenty to handle 1,000 connections unless you're serving up video. That's 1 Mbps per user. If your web page can't render (ignoring image loading) within a couple seconds even on a connection that slow, you're doing something wrong. Maybe stop using 20 different trackers and shoving several megabytes of JavaScript to the user.

kijin 1y ago

> No need for CDN etc unless you are talking about millions of requests per day. Both caddy and nginx can handle 100s of millions of static requests per day on any off-the-shelf computer without breaking a sweat. You will run into network capacity issues long before you are bottlenecked by the web server software.

whatevaa 1y ago
Network capacity and geo-proximity are the issues, not number of requests.

czhu12 1y ago

This is why I built https://canine.sh 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 that a page is taking 10 seconds to load, but you can't replicate it. +$300 / m cloud service. Then, if you ever want to aggregate data into a dashboard to present to customers -- Looker / Tableau / Omni +$20k / year. Data warehouse + replication? +$150k / year This goes on and on and on. The holy grail is to be able to run ALL of these external services in your own infrastructure on a common platform with some level of maintainability. Cloud Sentry -> Self Hosted Sentry Datadog -> Self Hosted Prometheus / Grafana Looker -> Self Hosted Metabase Snowflake -> Self Hosted Clickhouse ETL -> Self Hosted Airbyte Most companies realize this eventually and thats why they eventually move to Kubernetes. I think its also why often indie hackers can't quite understand why the "complexity" of Kubernetes is necessary, and just having everything run on a single VPS isn't enough for everything.

threetonesun 1y ago
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.
- jerf 1y ago
  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.

mikepurvis 1y ago

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 ports exposed. Run that on someone else's managed k8s setup (or Talos if I'm self hosting) and it's basically exactly as easy as having done it on my own VM but this way I'm only responsible for my application and its interface.

cyberax 1y ago
You can mitigate a lot of security issues by not exposing your self-hosted stack to the Internet directly. Instead you can use a VPN to your home network. An alternative is a front-end proxy on a box with a managed OS, like OpenWRT.
oxalorg 1y ago
I left my VPS open to password logins for over 3 years, no security updates, no firewalls, no kernel updates, no apt upgrades; only fail2ban and I survived: https://oxal.org/blog/my-vps-security-mess/ https://oxal.org/blog/my-vps-security-mess/ Don't be me, but even if you royally mess up things won't be as bad as you think.
- Matumio 1y ago
  I've had password login enabled for decades on my home server, not even fail2ban. But I do have an "AllowUsers" list with three non-cryptic user names. (None of them are my domain name, but nice try.) Last month I had 250k failed password attempts. If I had a "weak" password of 6 random letters (I don't), and all 250k had guessed a valid username (only 23 managed that), that would give... uh, one expected success every 70 years? That sounds risky actually. So don't expose a "root" user with a 6-letter password. Add two more letters and it is 40k years. Or use a strong password and forget about those random attempts.
- m463 1y ago

jstummbillig 1y ago

I think this is a moderately good idea, if you are certain that you want to remain involved with the business operationally, forever. It's still not ever a great idea (unless, maybe, this is what you do for a living for your customers), simply because it binds your time, which will absolutely be your scarcest asset if your business does anything. I am speaking from my acute experience.

thewebguyd 1y ago

> Majority of projects don't need the web scale or whatever. Truth. All the major cloud platform marketing is YAGNI but for infrastructure instead of libraries/code. As someone who works in ops and has since starting as a sysadmin in the early 00s, it's been entertaining to say the least to watch everyone rediscover hosting your own stuff as if it's some new innovation and wasn't ever possible before. It's like that old MongoDB is web scale video (https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs) Watching devs discover Docker was similarly entertaining back then when us in ops have been using LXC and BSD jails, etc. to containerize code pre-DevOps. Anyway, all that to say - go buy your gray beard sysadmins a coffee let them help you. We would all be thrilled to bring stuff back on-prem or go back to self hosting and running infra again and probably have a few tricks to teach you.

Sohcahtoa82 1y ago

Everything you said 110% I wish I understood why some engineers feel the need to over-engineer the crap out of everything. Is it because of wishful thinking? They think their blog is gonna eventually become so popular that they're handling thousands of requests per second, and they want to scale up NOW? I just think about what web servers looked like at the turn of the millennium. We didn't have all these levels of abstraction. No containers. Not even VMs. And we did it on hardware that would be considered so weak that they'd be considered utterly worthless by today's standards. And yet...it worked. We did it. Now we've got hardware that is literally over 1000 times faster. Faster clocks, more cache, higher IPC, and multiple cores. And I feel like half of the performance gains are being thrown away by adding needless abstractions and overhead. FFS...how many websites were doing just fine with a simple LAMP stack?

chrisweekly 1y ago

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.

eddieroger 1y ago
You're right, including your warning of premature optimization, but if the premise of the thread is starting from a VPS, user-perceived latency shouldn't be as wild as self-hosting in a basement or something because odds are your VPS is on a beefy host with big links and good peering anyway. If anything, I'd use the CDN as one more layer between me and the world, but the premise also presupposed a well-hardened server. Personally, the db and web host being together gave me itches, but all things secure and equal, it's a small risk.

assimpleaspossi 1y ago

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.

whatevaa 1y ago
How interactive are those sites?

deleted 1y ago

[deleted]

noduerme 1y ago

Are you talking about the VPS just serving as a reverse proxy and running the server on-prem or at home? Or are you having a reverse proxy on some VPS with a static IP send connections to other VPSs on a cloud service? I've self-hosted toy apps at home this way, with a static IP VPS as a reverse proxy in the middle, and it is indeed easy. With Tailscale you don't even need a static IP at home. A gigabit connection and a $100 box can easily handle plenty of load for a small app or a static site. To me, the reason I would never put something like that into production even for a very small client is, even in a fairly wealthy city in America, the downtime caused by electrical outages and local internet outages would be unacceptable.