유아용 침대: Devcontainers만 있으면 충분합니다.

This picks up where DevPod: SSH-Based Devcontainers Without IDE Lock-in left off. I’ve been hacking on dev environment tooling since 2013. Ventriloquist and devstep were different takes on the same problem: I want to git clone && cd into a project to start working on it without thinking about infrastructure. Ventriloquist had you declaring platforms and services explicitly in a Vagrantfile using a custom format with no ecosystem, devstep went the other direction with buildpack magic that auto-detected our stack. I recently built yet another one, and how it came together surprised me. I think I found out about devcontainers back when the CLI got first released (early 2022 maybe? Hard to tell by now), it felt like the spec I’ve been waiting for. A JSON file describing the environment with tooling that builds the container. Same spirit as what I have been building but I didn’t have to own the spec anymore, just the runner. The thing preventing me from using it was the fact that for a good while the way to use it with a nice UX was through VS Code, I didn’t want to leave nvim to go there, but I got into it anyway with Cursor last year. Then DevPod changed that, I could SSH into a container and use whatever editor I wanted. That’s something I was comfortable with since the old Vagrant days and I even wrote a post about it last year, but early this year things started going sideways. I’ve been meaning to experiment with Podman for a while due to its daemonless / rootless support. I was trying to get DevPod working with Podman and couldn’t get it to work. I went to the repo looking for help and the last commit was… a merge of my own PR from 4 months ago fixing some port forwarding docs. I poked around the issues and remembered that @nick-walt pointed out to me that a community fork was being maintained so I gave it a shot. The fork mostly worked but other things started breaking (git signing workarounds, for one) and I couldn’t be bothered troubleshooting. That’s when I started considering more seriously the idea of building my own tooling again which eventually became crib. Before fully committing, I checked: could I just fork DevPod (or the community fork) and strip it down? I pointed Claude at the original loft-sh/devpod codebase and asked what it would take to extract the essentials. It ran for about 30 minutes and came back with a long list of things to remove: providers, SSH tunnels, agent injection, gRPC, IDE integrations. They were all “tangled together” which was kinda scary. The official CLI is a mature reference implementation but it’s not the kind of project that’s going to move fast on new ideas. I’ve been missing the plugin/extension capabilities I had back in my devstep days (I even had a Squid proxy plugin for caching package downloads) and the official CLI isn’t built for that. I also remembered it requiring Node and I just wanted a single binary I could drop in (they apparently have an install script now that bundles Node behind the scenes, but by the time I found that out I was already past it). TL;DR - ripping things out or trying to push my ideas into the official CLI was probably going to take longer than starting fresh. crib wasn’t a weekend of agentic coding, I actually had a first attempt back in September 2025 that used the Docker Go SDK directly which kinda worked, but it was a lot of code between me and a running container so I just threw it away. For crib, I started differently though. I asked Claude on my phone to distill the devcontainer spec into something digestible, got that markdown over to the computer, fed it into Claude Code along with a round of research on the reference implementation source code, and ran my project-inception skill (Claude interviews me about what I want to build and then produces docs + roadmap from that). From there, Claude executed the plan while I reviewed code, handled some architecture decisions and did manual testing on some examples we put together and my work project. Once the core was in place, I switched to focused sessions, one feature or fix per PR, with Copilot reviewing each one before merge. Go was a conscious choice: I’ve got experience with it and it compiles to a single binary. Also, instead of the SDK approach, crib just shells out to docker or podman and lets them “have fun with my --args ”. crib reads a devcontainer.json , builds the image, runs lifecycle hooks, and crib shell drops you in. I want to keep the core small and expand once it’s battle tested. The design choices came from things that gave me a hard time with DevPod. Most devcontainer tooling adds ceremony between you and a working shell: providers to configure, SSH tunnels to manage, IDE integrations to maintain. The git signing wrapper bug was enough to convince me that the simplest path is docker exec , no SSH or agents injected into the container. This is how I used to work with containers back in the vagrant-lxc / devstep days way before devcontainers were a thing. I wan