Well… that didn’t last long
Back in March I wrote about crib, yet another dev environment tool I built after years of not hacking on this kinda stuff in the open. The Dev Container spec really felt like the right foundation: I didn’t have to invent my own format or special configuration anymore, just build a runner that worked the way I wanted.
A few months later (feels like multiple years in this age of AI), I’m going to stop working on it. I’ve opened an issue inviting people to reach out if they want to carry it on, and may eventually archive it if there’s no interest. It doesn’t have that many stars or a big community around it TBH, but I’d rather give people a chance than just disappear.
I’ve done this before with other “popular” projects I maintained pre-AI like vagrant-lxc and vagrant-cachier. I even did the “The Pull Request Hack” trick back then, fun times that don’t come back, that is something that is inconceivable in this age of AI :lolcry:.
Anyways, Crib’s lifespan was pretty short to me but that’s fine, I had fun along the way and it made me continue moving forward, that’s what matters. I still think the spec is cool but I’m just not sure I need it anymore.
I stopped using Crib in the past couple months
The reason I moved to devcontainers in the first place was consistency with the team. We were using VS Code and later Cursor, and having the same runtimes / services available to everyone was worth moving away from my good old terminal setup.
Then Claude Code clicked for me, and eventually I was spending most of my time in Cursor’s built-in terminal. At that point I wanted to ditch Cursor and go back to Neovim. I wrote a whole series about that transition, first using DevPod and later Crib to keep the team’s devcontainer setup while working from the terminal.
The next shift wasn’t really a conscious decision: for personal projects I started trusting agents enough to let them go YOLO with Pi on my machine. In the beginning I was mostly using open-weight models through Ollama Cloud, then started playing with OpenCode Go and more recently I started using OpenAI models too. I no longer have a personal Claude Code subscription, only for work.
Anyways, after a while I realized I was using Crib for my work project only, for consistency with the rest of the team. They still use devcontainers with DevPod on their Macs, at least for now, but I’ve been putting together a different setup for myself ever since I learned about bb back in August (more on that below).
Omarchy made something click
Omarchy’s approach to development tools helped me realize that mise and Docker are pretty much all I need to GSD.
Mise handles the tools / runtime versions and Docker handles the services my apps depend on, that’s it. I also loved the on-demand installation: Omarchy wires up little mise-backed launchers for commands like gh and the coding agents, so the command installs what it needs when I first run it. I don’t need every possible tool installed ahead of time.
Ever since I learned about those mise tricks, I’ve been carrying that idea into my own environments with a foundation and tools added as needed.
For example, I’ve been building a private personal-assistant project through prompting that uses a barebones container. I told the agent to start with Debian 13 and use mise for anything available through it. Once that foundation was done, it was a matter of saying “add Node”, “add whatever else”, and it just worked. Same for another lil tool I created to help me clean up a messy photo library I got.
Obviously, that’s still configuration. I picked the base and the tool manager, but I didn’t need a devcontainer runner to keep adding things to it. LLMs are very capable of generating the container configuration itself when I need one.
Side note: while writing this post I came across a post on Twitter about mise’s automatic tool updates and built-in sandboxing which I might experiment with in the future.
One environment is easier to reason about
There really wasn’t some magical “detect this project and configure its devcontainer” step in my old workflow (something I had back in the devstep days with Heroku-like buildpacks). I still had to read devcontainer feature docs, ask an agent to configure things, or use a large “one size fits all” image that already had the stuff I needed.
And sometimes I’d forget to shut environments down, so shit was left running unattended (for multiple days at times!). Having one main working environment is a lot easier to reason about than keeping track of a bunch of project-specific containers.
Crib has goodies I wanted enough to implement like package caching, persistent shell history, agent credentials and smarter restarts. I just don’t recreate my environments as often as I used to, so some of those conveniences (like caching) don’t matter that much to me anymore.
Sure, I could use a devcontainer for multiple projects and configure mise inside it, but at that point why use devcontainers at all? An ordinary container with the tools I need gets the job done with less “overhead”.
So far this has worked well, though I’m still polishing my sandboxing setup. Database usage has been limited to my work project and personal projects using SQLite, so I’m not claiming I’ve figured out how every possible stack should share an environment. In any case, supporting services can still have their own containers, or run with systemd / wrapper scripts inside the single shared container.
The main place where I work is what I want to keep together, and that environment should be isolated from my machine unless I’m hacking on my own OS-related stuff. I’ve been using virtualized dev environments for over a decade now and by no means do I want to keep a bunch of dev-related stuff on my machine unless I really need to.
What I’m using instead
I’ve been using bb ever since I found out about it, at work, for personal projects and the sporadic OSS contribs I do every now and then. I’m using my very own bb-image as the foundation for those environments and mise is part of that shared foundation, with tools available without baking every runtime into every project setup.
Much like Pi, I also love how malleable bb is and I’m hacking away on plugins rather than waiting for someone else’s interface to do exactly what I want.
Code review is one perfect example (yes, I still read code). For a good while I’d review code in GitHub’s web interface and hop back to the terminal to discuss things with agents. Eventually I tried terminal tools like Hunk, tuicr, and revdiff but I still had a separate surface to review and provide feedback (maybe that changed? dunno). What I wanted was a rich GitHub-like Pull Request review interface next to my agent, so I built Review Workspace: diffs, comments attached to lines, and feedback sent back to the agent in the same thread. I know there’s a Plannotator plugin for bb that might handle this, but I haven’t tried it yet.
I am also starting a new OSPS (Open Source Personal Software) project bringing my software workshop together in a single place, its name is Urdume and I might write about it once it’s been battle tested a bit more. It’s a “brand new thing”, nothing revolutionary, the bb experience behind it isn’t new, but this particular setup definitely is.
The devcontainer ecosystem isn’t dead
FWIW - I also checked what’s been happening outside my own setup.
The official CLI is still evolving, the community fork’s maintainer considers original DevPod abandoned, and is now focusing primarily on Devsy, which explicitly targets both developers and agents. The fork remains available and is still getting releases. Claude Code also documents devcontainer environments though I never used it.
In other words, it’s obvious that agents aren’t making devcontainers irrelevant for everyone, they’re another thing that can use a standardized workspace. Devsy even advertises microVM-backed workspaces, so moving to a VM doesn’t necessarily mean moving away from the spec either.
My team’s setup still makes sense for them (at least for now) but I’m just finding that I need less of that machinery for my own workflow.
Maybe I’m “done” with containers too?
Urdume currently runs on smolvm, but that’s an experiment that I hope will work, not a settled migration. If performance still gets in my way I might consider other alternatives, but I’ll probably just stick to Podman for a while.
I already tried using smolvm for a dev environment and shared-folder performance sent me back to Docker / Podman. There were also problems with host changes becoming visible in the guest, and I reported a separate nested-mount issue.
Fixes have shipped upstream, and the maintainers reported substantial performance and file-coherence improvements. That’s encouraging but I haven’t used this new setup long enough to say those problems are gone for my actual work.
The separate guest kernel is appealing as I’m giving agents more freedom, though it doesn’t make mounted host projects or forwarded credentials harmless given I still have to decide what the machine gets access to.
I’m also interested in branching machines but I haven’t made that part of my regular workflow yet. For now I want normal work to feel fast enough, shared folders to behave correctly and to find out whether branching is actually useful to me rather than just a cool feature.
So what am I actually “done” with?
I still want reproducibility, pinned versions where they matter, and a boundary around what agents can touch. What I’m “done” with is maintaining a project-specific devcontainer setup and runner when a reusable foundation, mise, and an agent adding what’s missing are enough for how I work.
Crib was what I wanted when I built it. Now I’m spending my time on bb plugins and this new workshop instead. I’m not 100% sure yet whether smolvm will stick but Podman is still there if it doesn’t ✌️