37
submitted 1 week ago by poVoq@slrpnk.net to c/selfhosting@slrpnk.net
top 7 comments
sorted by: hot top new old
[-] grrgyle@slrpnk.net 9 points 1 week ago

That also means resisting the temptation to make ourselves indispensable. Being the person everyone has to call when something breaks can feel like a sign that we are contributing something important, but [...] the goal should be to make ourselves increasingly unnecessary by making the knowledge we carry increasingly available to other people.

What a beautiful sentiment. Very well said.

To my chagrin, I've seen the "private sector" learning this lesson very well, with the practice of codifying configurations of machines and networks in "infrastructure as code" documents. Though these still require special training to decipher and apply, they make people (or workers) much easier to replace.

Although, I'm not sure I want reproduce the patterns I've learned from the corporate world, I'm curious if there's merit to using some of this technology to make infrastructure more easily "spin-up-able. " Or maybe SH hardware will vary too much to make something like OpenTofu useful in a non-cloud setting.

[-] fruitycoder@sh.itjust.works 2 points 1 week ago

I'm 100% biased towards this. It's really cool to see a system get frankenstiened or frankenstein a system from code. It's like getting to leap frog from all of their work without needing to ever explicitly knowing or working with each other.

The real deciding factor isn't whether to automate or not but what is the expected technical skills of who expect to contribute or maintain it the future.

So I personally layer levels to it prefering the common automation where applicable. So tofu for infra and spin up. Ansible for OS config and network equipment. Kubernetes for everything else with a fallback to tofu for some apps that have no k8s API but a good tofu provider.

With that people can actually piecemeal what they want and where they want it if some underlying assumption changed (it's no longer bare metal or aws, it's Ubuntu or SuSE now, it's RKE2 or it's GKE now etc)

That said for bare metal I actually skip tofu and do a cloud native bare metal management service like TinkerBell or Metal3, and that's really only if it's worth it.

The other, when you see it work it's beautiful, thing about the approach. GitOps. Watching what was a thousand shadow IT ops become PRs through automated testing and review is really magical. Coming from a IT back ground for life saving infrastructure the stress difference between the old hat way and this is really hard to understate.

[-] schmorpel@slrpnk.net 4 points 1 week ago

I thought this was an article, but I'm glad I checked it out. It looks like a really very well put together course (too comprehensive to call it tutorial). With guides for people who just want to learn part of the stuff. Had no time to dig deeper, but if you (want to) selfhost and are active in building resilience go have a look.

[-] fruitycoder@sh.itjust.works 3 points 1 week ago

This is truly an amazing guide on building resilient systems. It's so common for people to ignore human based failure domains too!

That said some of the early recommendations suggest fully mapping dependencies such as system accounts, payment accounts, etc. I've looked at that from the "asCode" side but always felt quite lacking. With digital twin modeling of an orginization being a highly academic work (how do you truly capture the reality right?) and smart contracts such DAOs being a heavy tool for enforcement. I was just wondering if you have recommendation for anything or templates?

If not I might try to templatize something based on those lessons myself just to see if there is an quick start way for people to do this.

[-] jobbies@lemmy.zip 1 points 1 week ago

Pretty sure that whole thing was generated by AI

[-] poVoq@slrpnk.net 6 points 1 week ago

By Autistici/Inventati ? Maybe some people from them were involved, yes.

[-] TacoButtPlug@sh.itjust.works 1 points 1 week ago

thank you!!!!!

this post was submitted on 25 Sep 2026
37 points (97.4% liked)

Self-hosting

4677 readers
2 users here now

Hosting your own services. Preferably at home and on low-power or shared hardware.

Please don't share vibe coded projects here.

Also check out:

founded 4 years ago
MODERATORS