Live data from Hacker News

CLI agents make self-hosting on a home server easier and fun

fulghum.io

351–360 of 570 posts

Re: CLI agents make self-hosting on a home server easier and fun

#351
post #84
post #26

Earlier quoted context omitted.

I'd rather expose a Wireguard port and control my keys than introduce a third party like Tailscale. I am not sure why people are so afraid of exposing ports. I have dozens of ports open on my server including SMTP, IMAP(S), HTTP(S), various game servers and don't see a problem with that. I can't rule out a vulnerability somewhere but services are containerized and/or run as separate UNIX users. It's the way the Inter…

> I'd rather expose a Wireguard port and control my keys than introduce a third party like Tailscale. Ideal if you have the resources (time, money, expertise). There are different levels of qualifications, convenience, and trust that shape what people can and will deploy. This defines where you draw the line - at owning every binary of every service you use, at compiling the binaries yourself, at checking the code th…

> Ideal if you have the resources (time, money, expertise). There are different levels of qualifications, convenience, and trust that shape what people can and will deploy. This defines where you draw the line - at owning every binary of every service you use, at compiling the binaries yourself, at checking the code that you compile.

Wireguard is distributed by distros in official packages. You don't need time, money and expertise to setup unattended upgrades with auto reboot on a debian or redhat based distro. At least it is not more complicated than setting an AI agent.

Re: CLI agents make self-hosting on a home server easier and fun

#352
post #316
post #26

Earlier quoted context omitted.

I'd rather expose a Wireguard port and control my keys than introduce a third party like Tailscale. I am not sure why people are so afraid of exposing ports. I have dozens of ports open on my server including SMTP, IMAP(S), HTTP(S), various game servers and don't see a problem with that. I can't rule out a vulnerability somewhere but services are containerized and/or run as separate UNIX users. It's the way the Inter…

> introduce a third party like Tailscale. Well just use headscale and you'll have control over everything.

That just moves the problem, since headscale will require a server you manage with an open port.

Sure, tailscale is nice, but from an open-port-on-the-net perspective it's probably a bit below just opening wireguard.

Re: CLI agents make self-hosting on a home server easier and fun

#354

Earlier quoted context omitted.

People are not full time maintainers of their infra though, that's very different to companies. In many cases they want something that works, not something that requires a complex setup that needs to be well researched and understood.

Wireguard is _really_ simple in that sense though. If you're not doing anything complicated it's very easy to set up & maintain, and basically just works. You can also buy quite a few routers now that have it built in, so you literally just tick a checkbox, then scan a QR code/copy a file to each client device, done.

This may come with its own limitations, though.

My ISP-provided router (Free, in France) has WG built-in. But other than performance being abysmal, its main pain point is not supporting subnet routing.

So if all you want is to connect your phone / laptop while away to the local home network, it's fine. If you want to run a tunnel between two locations with multiple IPs on the remote side, you're SoL.

Re: CLI agents make self-hosting on a home server easier and fun

#355
Timely! I just re-setup my Pi5 with the help of Claude. https://github.com/kaihendry/ai-pi

Tbh I did the mistake of throwing away Ansible, so testing my setup was a pain!

Since with AI, the focus should be on testing, perhaps it's sensible to drop Ansible for something like https://github.com/goss-org/goss

Things are happening so fast, I was impressed to see a Linux distro embrace using a SKILL.md! https://github.com/basecamp/omarchy/blob/master/default/omar...

Re: CLI agents make self-hosting on a home server easier and fun

#356
post #317
post #122

Earlier quoted context omitted.

> It's simple, you increase your attack surface, and the effort and expertise needed to mitigate that. Sure, but opening up one port is a much smaller surface than exposing yourself to a whole cloud hosting company.

Headscale is a thing

Headscale is only really useful if you need to manage multiple users and/or networks. If you only have one network you want to have access to and a small number of users/devices it only increases the attack surface over having one wireguard listening because it has more moving parts.

Re: CLI agents make self-hosting on a home server easier and fun

#357
post #81

Earlier quoted context omitted.

If you expose ports, literally everything you are hosting and every plugin is an attack surface. Most of this stuff is built by single hobbiest devs on the weekend. You are also exposed to any security issues you make in your configuration. My first attempt self hosting I had redis compromised because I didn't realise I had exposed it to the internet with no password. Behind a VPN your only attack surface is the VPN…

You exposed your redis publicly? Why? Edit: This is the kind of service that you should only expose to your intranet, i.e. a network that is protected through wireguard. NEVER expose this publicly, even if you don't have admin:admin credtials.

Isn't GP's point inadvertently exposing stuff? Just mention docker networking on HN and you'll get threadfuls of comments on how it helpfully messes with your networking without telling you. Maybe redis does the same?

I mitigate this by having a dedicated machine on the border that only does routing and firewalling, with no random services installed. So anything that helpfully opens ports on internal vms won't automatically be reachable from the outside.

Re: CLI agents make self-hosting on a home server easier and fun

#360

Earlier quoted context omitted.

Oh yeah this is a really funny story considering what thread we are on, but I remember asking chatgpt or claude or gemini or anything xD to make QTM work and none of them could figure out But I think in the end what ended up working was my frustration took over and I just copy pasted the commands from readme and if I remember correctly, they just worked. This is really ironical considering on what thread we are on bu…

You aren't actually supposed to ever need to deal with tickets manually, unless you are trying to get a tunnel between two machines and neither can SSH into the other. It could be streamlined with something like Magic Wormhole, though. I'll add that to the backlog and see if there's interest. The normal way is to use SSH / docker exec / any remote shell to let QTM swap the tickets over it. I've added an asciinema to…

well my use case is the fact of connecting two servers behind nat. If I were to be able to gain ssh lets say, then I could've simply port forwarded in the first place.

Wow the asciinema is really good and very professional, thanks for creating it, I found it very helpful (in the sense that if I ever were to repeat my experiment, now I got your asciinema server) and I hope more people use it

> It could be streamlined with something like Magic Wormhole, though. I'll add that to the backlog and see if there's interest

To be really honest, its not that big of a deal considering one can do that on their own but I just had this idea for my own convenience when I was using QTM

I really like QTM a lot! Thanks for building it once again, I would try to integrate it more often and give you more feedback when possible from now.

Post reply on HN