Live data from Hacker News

Self-Hosting like it's 2025

kiranet.org

161–170 of 240 posts

Re: Self-Hosting like it's 2025

#161
post #157

Funny how the author doesn't give a single link in the post. The reader has to go searching, spend time to find the things the author writes about. Well, a simple example: Awesome-Selfhosted. Is it that hard to give a link? Is it some kind of phobia or religion that doesn't allow direct links on the internet? Really? Come on, it's hypertext! Where are the hyperlinks?

The headers are hyperlinks.

Re: Self-Hosting like it's 2025

#162
post #87
post #66

Earlier quoted context omitted.

I agree with this: I personally don't need tutorials for hosting stuff, rather tutorials about securing it properly.

Could you give an example of a guide that helped you self host a system or service by telling you how to do the security? One that shows what information would be missing from a regular setup tutorial? I'm a security consultant so this is not a problem I have. To me it seems very straightforward and like most things are secure by default (with the exceptions being notorious enough that I'd know of it), so I'm interes…

I haven't seen such a guide, unfortunately :-).

I consider hosting a system or service trivial ("just run the service and open its port to the public Internet"). Then the first question is: what if the service gets compromised (that seems like the most likely attack vector, right?)? Probably it should be sandboxed. Maybe in a container (not running as root inside the container, because I understand it makes it a lot easier to escape), better if it is in a VM (using Xen maybe?). What about jails?

Now say the services are running in VMs, and the "VM manager" (I don't know how to call it, I mean e.g. dom0 for Xen) is only accessible from my own IP (ideally over a VPN if it's running in a VPS, or just through the LAN if running at home?), the next question is: what happens if one of the services gets compromised? I assume the attacker can then compromise the VM, so now what are the risks for me? I probably should never ssh as a user and then login as root from there, because if it's compromised the attacker can probably read my password? Say I only ever login through ssh, either as root directly or as the user (but never promoting myself to root from the user), what could be vectors that would allow an attacker to compromise my host machine?

I listened to a lot of "Darknet Diaries" episodes, and the pentesters always say "I got in, and then moved laterally". So I'm super scared about that: if I run a service exposed to the Internet, I assume it may get compromised someday (though I'll do my best to protect it and keep it up-to-date). But then when it gets compromised, how can I prevent those "lateral moves"? I have no idea, as in "I don't know what I don't know".

All that to say, I would love to find a book or blog posts that explain those things. Tutorials I see usually teach how to run a service in docker and don't really talk about security.

Re: Self-Hosting like it's 2025

#163

What about Kamal? https://kamal-deploy.org/ Did anybody here use it for anything that is not a Ruby on Rails app?

Yes, I have been using it and really enjoying it for deploying web apps. So far I have deployed web apps using: * fastapi (python) * Django ninja (python) * ghost cms (node) I have been writing up my thoughts (and an example): https://andrewperkins.com.au/kamal/ The ability to deploy to both cloud servers and on-premises is a big win as I often work on projects that have a mix of both. As the sibling comment says, it…

Great! Are you also deploying DB servers or any other kind of additional servers that are dependencies of those webapps?

Re: Self-Hosting like it's 2025

#165

I feel like I’ve been plugging it way too many times... but if you’re looking for a more humane alternative to Portainer, check out my project, Lunni: https://lunni.dev/ (Docker Swarm only for now, though I’m thinking about adding k8s later this year)

this looks really cool, I love to see some competition in this space

Thank you so much!

Re: Self-Hosting like it's 2025

#166
post #157

Funny how the author doesn't give a single link in the post. The reader has to go searching, spend time to find the things the author writes about. Well, a simple example: Awesome-Selfhosted. Is it that hard to give a link? Is it some kind of phobia or religion that doesn't allow direct links on the internet? Really? Come on, it's hypertext! Where are the hyperlinks?

The headers are hyperlinks.

Yes, the links are now in the headers. The author has updated the post.

Re: Self-Hosting like it's 2025

#167

Self-Hosting like it's 2025...uhhgg... Don't get me wrong I love some of the software suggested. However yet a another post that does not take backups as seriously as the rest of the self-hosting stack. Backups are stuck in 2013. We need plug and play backups for containers! No more roll your own with zfs datasets, back up data on the filesystem level (using sanoid/syncoid to manage snapshots or any other alternative…

rclone is great for this.

One could set up a Docker Compose service that uses rclone to gzip and back up your docker volumes to something durable to get this done. An even more advanced version of this would automate testing the backups by restoring them into a clean environment and running some tests with BATS or whatever testing framework you want.

Re: Self-Hosting like it's 2025

#168

Self-Hosting like it's 2025...uhhgg... Don't get me wrong I love some of the software suggested. However yet a another post that does not take backups as seriously as the rest of the self-hosting stack. Backups are stuck in 2013. We need plug and play backups for containers! No more roll your own with zfs datasets, back up data on the filesystem level (using sanoid/syncoid to manage snapshots or any other alternative…

Why not zfs snapshots? Besides using Hyper-V machine snapshots, that's been the easiest way, by far, for me. No need to worry about the 20 different proprietary tools that go with each piece of software.

Each VM or container gets a data mount on a zvol. Containers go to OS mount and each OS has its own volume (so most VMs end up with 2 volumes attached)

Re: Self-Hosting like it's 2025

#169
post #79

The only thing that holds me back for self hosting is Postgres. Has anyone managed to get a rock solid Postgres setup self managed? Backups + tuning?

Why would tuning be necessary for a regular setup, does it come with such bad defaults? Why not upstream those tunes so it can work out of the box? I remember spending time on this as a teenager but I haven't touched my MariaDB config in a decade now probably. Ah no, one time a few years ago I turned off fsyncing temporarily to do a huge batch of insertions (helped a lot with qps, especially on the HDD I used at the…

PostgreSQL defaults (last I looked, it's been a few years) are/were set up for spinning storage and very little memory. They absolutely work for tiny things like what self-hosting usually implies, but for production workloads tuning the db parameters to match your hardware is essential.

Re: Self-Hosting like it's 2025

#170
post #167

Self-Hosting like it's 2025...uhhgg... Don't get me wrong I love some of the software suggested. However yet a another post that does not take backups as seriously as the rest of the self-hosting stack. Backups are stuck in 2013. We need plug and play backups for containers! No more roll your own with zfs datasets, back up data on the filesystem level (using sanoid/syncoid to manage snapshots or any other alternative…

rclone is great for this. One could set up a Docker Compose service that uses rclone to gzip and back up your docker volumes to something durable to get this done. An even more advanced version of this would automate testing the backups by restoring them into a clean environment and running some tests with BATS or whatever testing framework you want.

Rclone won't take a consistent snapshot so you either need to shutdown the thing or use some other tool to export the data first
Post reply on HN