i_stole_ur_taco

Oh my god that fermenter is gorgeous.

There’s a large group of folks here that swear by renting a VPS. A common argument is that when you fully self host and expose anything to the internet (incoming connections), you’ve always got some security risk you might not know exists.

A VPS offloads a lot of the low level security concerns to someone else (it’s the whole cloud sales pitch) and if someone breaks in, there’s little for them to steal (assuming you’re not putting anything personal and sensitive on the VPS).

The nice thing is that you can start with a small and cheap VPS and set things up and decide if you even want to self host, or to what extent. Then you have data to make a decision as to whether you need to upgrade to a better VPS, or port your setup to a local server (which you can now buy with a good idea of what sort of specs it should have).

On the flip side, you could also self host on whatever computer you have laying around (leave the laptop open) and play with some services there. If you decide you want to open it to the internet, you could just as easily port your local playground to a VPS and keep going.

I don’t think there’s anything in the self hosting world that really paints you into a corner.

Which password manager? I had the same problem with BitWarden until I found a buried setting to tweak each password domain. Maybe there’s a badly advertised feature in yours, too?

I run everything in docker. My docker volumes are all subdirectories under /media, which is the root of my NAS. If an app only needs something specific, docker only mounts, eg /media/movies. If the app needs many subdirectories (like backups), it gets the full /media mount.

All the docker data/configs are under /docker/volumes (eg /docker/volumes/jellyfin), and every container is configured with compose in /docker/docker-compose.yml.

The biggest hurdle for me was creating a sane docker-compose file that defines where everything lives. Once that is standardized, adding and maintaining your apps becomes easy.

If you’re very new to this, even a dumb LLM like ChatGPT can be very helpful to explain what’s inconsistent, redundant, or incorrect with your config. If you are lost I would strongly suggest this as a way to get oriented. But DO NOT copy and paste anything into the LLM containing passwords, tokens, keys, etc. if you accident do, change those keys before finishing up your project.

With docker there’s no duplication- you have one copy of everything you need and you just point each container at the same data. This makes it trivial to keep file consistent across your apps and doesn’t waste space.

The LubeLogger meltdown ticket is pretty goddamn funny.

what’s missing?

An AI disclosure for your app per the community rules, Claude.

This port requires an AI disclosure per the community rules.

On the flip side, if you’re vibe coding an app you should seriously consider whether it’s something you want to open source or make available publicly. There’s a social contract that comes with that.

I have 2 self hosted slop apps I build and maintain myself. I think people would genuinely get great use out of them.

…but then I’m inviting critiques and feature requests and am roped into supporting them so it’s not just a big pile of shit that wastes everyone’s time. And I don’t want to spend my limited free time making common sense improvements to improve it for others. I want to write a lazy Claude prompt with insufficient context, get it barely doing what I need, and then spend the rest of my time eating crayons and similar pastimes.

I use pangolin and traefik together and expose a few of my services that way. But not everything.

I slot services into categories based on:

• do I really need to be able to access this externally?
• …with full admin rights?
• what write/delete access am I granting?
• if an attacker got in, how much damage could they do with what they could access?

Then the service is either not externally open at all, secured behind pangolin SSO, or secured behind pangolin SSO AND that service’s native auth. Which is an annoying double auth, but I feel like it’s another layer of protection in case one of them gets a 0-day exploit.

If you’re not creating or tweaking recipes, a paper notebook is fantastic. It gives you something to do while you’re waiting on the boil.

I have a notebook with a page for every brew session: date, full recipe, steps, observations, and things I fucked up. Update it until the beer is done and there’s tasting notes. It’s fun to reread in later years. I have a few early brews that I noted got “infected” - and after some experience I had a good laugh because the “infection” was the shitty recipe I designed.

If you’re building a recipe you really need to use software (unless you don’t care about calculating estimated alcohol or IBU up front). The alternative is a level of referencing tables and doing arithmetic that exceeds what I want to see in my hobbies.

But if you aren’t trying to be scientific or you’re just following a basic kit? The only technology that should be involved is your phone playing music!

Beersmith is still around and still ugly, but www.brewersfriend.com is rather nice for recipe design.

Waddaya mean no cloud?

YOU ARE THE CLOUD NOW

That’s how I’d answer if I set something up years ago and it was stable and never required me to come tinker with it.

Read the email again. The key word in their marketing slop is “alternatively”. You have a Plex Pass and are the server admin. Your users need to do nothing.

Unfortunately, that does mean I have to respond to messages from all my users asking what that email means and convince them they can just ignore it.

A second “nice” part of this change is that iOS users no longer have to buy the Plex app on the App Store to stream longer than a minute. The app is only like 5 bucks one time, but it was a barrier when trying to convince stubborn people to just fucking TRY my Plex server.