If nothing else, using the smart model for planning to hand off to the previous gen for implementation still seems like a useful pattern.

My plan is to make hay while the sun shines: get some planning in over the next week or so, and just let Opus take care of it when I get to actual implementation.

So much of our lives is now digital. Important accounts of all kinds, banking, etc.

Waiting on several giant corps to grant your loved ones access after they go through the bureaucratic hole of documentation is... rough.

Putting my master password in my will feels the same as just writing it on a note on my desk. Putting it in a note in a safety deposit box is high effort and cost.

Anyone got a better alternative way to set this up if self-hosting and not going with Vaultwarden?

You shouldn't be looking at just various kinds of earplugs as options for this. You can get custom made earplugs for your ears for differing use cases (sleep, concerts) at an ENT.

Fair enough, that buys a little bit of time to not break deployments I supose.

> When the build process completes, it tears down the overlayfs

Ah okay, I misunderstood you then - I was referring to Docker-less servers and my build steps running there, not building the images on the machine.

Thanks for the info!

"Builds" are the same as deploys, so when working with server(s) instead of larger scale deployments, I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios.

But I have seen this in action, which is why I'm wondering if I'm missing something.

The clearer benefit to me seems to be in this scenario to use it as a fast environment provisioning tool.

> disk, i/o exhaustion

This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case.

I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deploying by definition also contains my source code because I'm not deploying anything compiled.

How? What I'm describing is using Docker less.

> The build process can exhaust resources on the host

Maybe, but I've yet to have a host where that's the case for usual CRUD fare.

> The advantage is simplicity, and it's often worth the risk.

That's basically what I'm evaluating for here.

For bog standard LAMP or similar stack applications, I've not understood the advantage of going through the build-image-then-pull-on-host rigmarole. There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects.

But I have seen that done fairly often, hence was wondering what the point was.

Is using Docker/Compose "just" as the layer for installing & managing runtime environment and services correct? Especially for languages like PHP?

I.e. am I holding it wrong if I run my "build" processes (npm, composer, etc) on the server at deploy time same as I would without containers? In that sense Docker Composer becomes more like Ansible for me - the tool I use to build the environment, not the entire app.

For the purpose of my question, let's assume I'm building normal CRUD services that can go a little tall or a little wide on servers without caring about hyper scale.

There is no truly good, independent, feature complete browser out there right now if you want to avoid Chrome and have something that a) works and b) isn't hostile to the userbase.

Brave at the very least said they'd keep supporting Manifest v2 extensions, though not sure how you'd acquire them anymore unless Chrome web store has kept the listings up.

LinkedIn has also been especially hard to find a good blocker for to remove the sponsored/suggested posts from the timeline (it's just full of garbage engagement bait hot takes).

I just vibecoded a tampermonkey script to block scrolling on Instagram and also block reels. I also had it redirect from the `/reels/` URL to `/reel` which is just the single video view (for when friends link me memes), but it seems they removed that.

And of course, OpenClaw is built to be a very generalist agent with a chat interface - same effective outcome as remotely controlling an AI harness, but not exactly what everyone wants.