There is a specific kind of development environment frustration that only shows up after you have set up the same tools too many times.
You get a new machine, a temporary server, a cloud instance, or a clean container. Then the ritual starts. Install Node. Install zsh. Configure shell defaults. Add a package manager. Install editor extensions. Set up credentials. Install the CLI tools you use every day. Clone the repo. Fix a missing dependency. Fix the thing that fixed the missing dependency.
Eventually you get to work, but by then the environment has already taken more attention than the task deserved.
Devbox came from wanting a smaller answer to that problem.
I did not want a full platform. I did not want a complex remote development service. I wanted a Docker image I could run anywhere that gave me a browser-accessible VS Code experience, a proper terminal, and my AI coding CLI ready to go.
That is what Devbox is: code-server plus opencode inside a minimal, self-hosted development container.
The Setup I Wanted
The ideal setup had a few constraints.
It should run in a browser. That makes it useful from a laptop, a borrowed machine, an iPad, or a lightweight remote session.
It should be self-hosted. I wanted to control where the environment runs and what it has access to.
It should be persistent when needed, disposable when not. A Docker volume should be enough to keep a workspace alive, but destroying the container should not feel dramatic.
It should include AI development tools. For me, that meant opencode in the terminal, ready to work inside the same filesystem as the editor.
It should be boring to operate. One image. One port. One password. One workspace volume.
The basic run command looks like this:
docker run -d --name devbox \
-p 8080:8080 \
-e PASSWORD=changeme \
-v devbox-workspace:/home/devbox/workspace \
ghcr.io/darkrishabh/devbox:latestOpen the host on port 8080, log in, and you have VS Code in the browser.
That simplicity is the point.
Why code-server
code-server is essentially VS Code running on a remote machine and accessed through the browser. It is a good fit for Devbox because it does not ask me to rethink my editor workflow.
I still get a familiar file tree, editor tabs, terminal, search, extensions, and keyboard shortcuts. The main difference is that the compute and filesystem live inside the container or remote host.
That matters for a few workflows:
- Working from a machine that does not have my full toolchain installed.
There are hosted products that solve parts of this better at scale. Devbox is not trying to compete with those. It is intentionally smaller. It is the thing I can understand, build, run, and throw away.
Why Add Opencode
The second half of Devbox is opencode.
I wanted the AI coding tool to live inside the same environment as the code. That sounds obvious, but it changes the workflow. The CLI can inspect files, run tests, edit code, and operate from the actual project directory. It is not a separate chat window that requires copy-pasting context.
Inside Devbox, the terminal is not an afterthought. It is the control plane.
cd /home/devbox/workspace/my-project
opencodeFrom there, the AI assistant can work in the same container that has the runtime, dependencies, and source files. If tests fail, they fail in the real environment. If a command needs Node, it uses the container's Node. If a script writes files, they land in the mounted workspace.
That makes the setup feel coherent.
The Dockerfile Philosophy
The image is based on node:22-bookworm-slim. That choice is practical. Most of the projects I work on are JavaScript or TypeScript-heavy, and Node 22 gives the image a useful default without becoming too large.
The rest of the image is built around a few basics:
- code-server on port 8080
The shape is deliberately conventional:
FROM node:22-bookworm-slim
RUN apt-get update && apt-get install -y \
curl git sudo zsh ca-certificates \
&& rm -rf /var/lib/apt/lists/*
RUN useradd -m -s /usr/bin/zsh devbox \
&& echo "devbox ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/devbox
WORKDIR /home/devbox/workspace
USER devboxThe actual repository has more detail, but the philosophy is this: install the minimum useful system, avoid too much magic, and make the runtime easy to inspect.
Persistence Through Volumes
The most important operational choice is the workspace volume.
Containers are disposable. Workspaces often are not.
By mounting a volume into /home/devbox/workspace, the project files can survive container upgrades or rebuilds:
docker volume create devbox-workspace
docker run -d --name devbox \
-p 8080:8080 \
-e PASSWORD=changeme \
-v devbox-workspace:/home/devbox/workspace \
ghcr.io/darkrishabh/devbox:latestThat gives me a clean separation. The image contains the environment. The volume contains the work.
If I want to update Devbox, I can pull a new image and restart the container without treating the workspace as part of the image itself.
Where This Fits In My Workflow
Devbox is not my only development environment. I still like a local editor for many things. But Devbox is useful when I want a controlled environment quickly.
It is especially useful for AI-assisted work because AI coding sessions benefit from consistency. If the agent is going to run commands, inspect files, and make edits, I want the environment to be predictable. I do not want half the session spent discovering that the host machine is missing a tool.
It is also useful for experiments. I can clone something risky, test a dependency, run a proof of concept, or try a new workflow without contaminating my main machine.
That disposability changes behavior. I am more willing to experiment when cleanup is easy.
There is also a subtle focus benefit. When the environment is opened in a browser tab and scoped to one workspace, it feels less like my whole machine and more like a bench for one job. That matters when working with AI tools, because the tool can move quickly. A contained workspace gives me permission to let it try things, run commands, and make edits while still keeping the blast radius clear.
The best development environments reduce decision fatigue. They do not make you think about where Node came from, which shell profile loaded, or whether the editor is pointing at the right folder. They let you get to the actual question faster: what are we building, what is broken, and what should change?
That is the role Devbox plays for me. It is not glamorous infrastructure. It is a reliable place to start.
What I Would Improve Next
There are a few obvious directions.
First, secrets need a clean story. A remote dev container often needs access tokens, SSH keys, package registry credentials, and provider API keys. The right approach is not to bake those into the image. They should be mounted or injected at runtime.
Second, templates would help. A TypeScript template, a Python template, and an AI-agent template could make the first-run experience faster.
Third, observability matters if this runs on a shared server. Basic logs, resource usage, and health checks would make it easier to operate.
Fourth, I want the AI tooling layer to stay flexible. Opencode is useful, but the environment should not be overly coupled to one assistant forever.
Final Thought
Devbox is not a grand infrastructure platform. It is a small tool built around a practical feeling: I want to open a browser and have a real development environment waiting for me.
There is value in that smallness.
A remote development setup does not have to be complicated to be useful. Sometimes the right answer is a Docker image with code-server, a terminal you like, an AI coding tool, and a persistent workspace.
That is Devbox.