selfhostyour.tech
Why Self-Host?
141–150 of 269 posts
Re: Why Self-Host?
#142Earlier quoted context omitted.
I would not use nuc like this guy. Had one and it was slow and it have limited capacity. Then I had my old PC and it was very good but I wanted more nvme disks and motherboard supported only 7. Now I am migrating to threadripper which is a bit overkill but I will have ability to run 1 or two GPUs along with 23 nvme disks for example.
I have two NUC’s (ryzen 7 and intel i5) they’re rock solid.
Yes, if this works sure why not. Few years back decent NUC cost was at least 1k$ dollars. And still it is quite small, so you cannot slam 8 ssds in there.
I did use my old PC and it was working very nice with 4 sata ssds, in raid 10.
And as I already said on other comment - in my case power does not matter much. Space too.
Re: Why Self-Host?
#143Earlier quoted context omitted.
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.
>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.
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.
Re: Why Self-Host?
#14420 years ago grandpa could go to limewire.com, download setup.exe and click next->next->next to install a fully functional file hosting server+client. It was so easy that 1/3rd of world's computers had limewire installed in 2007 [1]. ONE FUCKING THIRD! Today, to install even the simplest self-hosted software, one has to be effectively a professional software engineer. Use SSH, Use Docker, use tailscale, understand TL…
> No idea why self-hosted software isn't `apt-get install` and forget.
Ubuntu tried to fix this with snaps but the whole Linux community raged and pushed back at them. Yeah, snap has its faults but it was designed initially for server-side apps.
Snap install xyz-selfhosted-app was the initial goal. You can install nextcloud as a snap right now.
Instead the Linux community let perfect be the enemy of good and successfully convinced everyone else to dump and avoid snaps as a format at all costs.
Re: Why Self-Host?
#145Earlier quoted context omitted.
>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.
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 ser…
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
Re: Why Self-Host?
#146Earlier 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…
Yeah, you are very right. If you start peaking success, you realize that while your happy path may work for 70% of real cases, it's not really optimal to convert for most of them. Sentry helps a lot, you see session replay, you get excited. You realize you can A/B test... but you need a tool for that... Problem: Things like Openreplay will just crash and not restart themselves, with multiple container setups, some ra…
Canine just makes deploying sentry / grafana / airbyte + 15k other OS packages a one click install, which then just gives you a URL you can use. Because its running on top of kubernetes, a well built package should have healthchecks which will detect an error and auto-restart the instance.
Obviously if [name your tool] is built so that it can be bricked [1], even after a restart, then you'll have to figure it out. Hopefully most services are more robust than that. But otherwise, Kubernetes takes care of the uptime for you.
[1] This happened with a travis CI instance we were running back in the day that set a Redis lock, then crashed, and refused to restart so long as the lock was set. No amount of restarts fixed that, it required manual intervention
Re: Why Self-Host?
#147"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…
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…
I'm also in this space - https://disco.cloud/ - similarly to you, we offer an open source alternative to Heroku.
As you well know, there are a lot of players and options (which is great!), including DHH's Kamal, Flightcontrol, SST, and others. Some are k8s based - Porter and Northflank, yours. Others, not.
Two discussion points: one, I think it's completely fair for an indie hacker, or a small startup (Heroku's and our main customers - presumably yours too), to go with some ~Docker-based, git-push-compatible deployment solution and be completely content. We used to run servers with nginx and apache on them without k8s. Not that much has changed.
Two, I also think that some of the needs you describe could be considered outside of the scope of "infra": a database + replication, etc. from Crunchy Bridge, AWS RDS, Neon, etc. - of course.
But tableau? And I'm not sure that I get what you mean by 150k/year - how much replication are we talking about? :-)
Re: Why Self-Host?
#148You write: I'm fortunate enough to work at a company (enum.co) where digital sovereignty is not just a phrase. info.addr.tools shows [1]: MX 1 smtp.google.com. TXT "mailcoach-verification=a873d3f3-0f4f-4a04-a085-d53f70708e84" TXT "v=spf1 include:_spf.google.com ~all" TXT "google-site-verification=TTrl7IWxuGQBEqbNAz17GKZzS-utrW7SCZbgdo5tkk0" This is not just a phrase, it is a DNS entry. Using the most evil in phrases…
Hi R_Spaghetti,
Founder of enum here. That's a fair point, and a good catch.
Honestly, using Google Workspace for our internal email was a pragmatic choice early on to let us focus on building our core product. It's a classic startup trade-off, and one we're scheduled to fix in the coming weeks.
I want to be clear, though: our customer-facing platform and all its data are and always have been 100% sovereign. Our infrastructure is totally independent of Big Tech.
Thanks for holding us accountable!
Re: Why Self-Host?
#149Earlier 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.
Depending on your mail flow, there's SendGrid and other options at a pretty reasonable cost to handle delivery concerns. I have one server set for sendgrid and another I've got setup for direct delivery... the only issue I've had sending from my own is to Outlook.com servers (not o365 or hotmail though). With DMARC/SPF, etc, gmail has been okay as well.
Re: Why Self-Host?
#150Self hosting is great and I'm thankful for all the many ways to run apps on your own infra. The problem is backup and upgrades. I self host a lot of resources, but none I would depend on for critical data or for others to rely on. If I don't have an easy path to restore/upgrade the app, I'm not going to depend on it. For most of the apps out there, backup/restore steps are minimal or non existent (compared to the one…
What kind of backup solution are you expecting? Every selfhosted app runs in docker, where the backup solution is back up the folders you mounted and the docker-compose.yml. To restore, put the folders back and run docker compose up again. I don't need every app to implement its own thing, that would be a waste of developer time.
+1 for the above... all my apps are under /app/appname/(compose and data)... my backup is an rsync script that runs regularly... when I've migrated, I'll compose down, then rsync then rsync to the new server, then compose up... update dns, etc.
It's been a pretty smooth process. No, it's not a multi-region k8s cluster with auto everything.. but you can go a long way with docker-compose files that are well worth it.