I usually don't take name clashes as seriously as some people here do, but when it's even in the same general niche, then that's not really a good look. It means the author failed to check the prior art - which is still fine for a (n+1)th hobby project, but not really for something more serious.
The overlap with Jetpack's devbox name is not fine. Not morally, given the massive overlap in functionality between the two implementations. At the very least, their existence will prevent you from getting a trademark.
Both projects even use devbox.json for their definitions, for crying out loud. If your usage is not compatible with Jetpack's devbox.json, please switch to a different filename ASAP.
Good point. I remember testing out Jetify's version a while back and switching away from it due to some issue I was having. I 100% thought this project was the same, just with a new website, as I did not remember much of the implementation details. Both of them even use `devbox.json` as the configuration file...
Well its not the same programming wise so your problem might be fixed on ours but as i said in another reply i wasnt aware of the existing project and our overlaps i did no research before hand sadly
We've been using devcontainers for this, as it's already got good support in vscode. Could you perhaps "elevator pitch" the main differences between devbox and devcontainers?
But having tried Devcontainers a lot, it feels like its probably a complex specification since outside of VSCode every implementation has issues.
The CLI on Mac has weird user permission issues. Cursor's implementation is very flaky. Zed doesn't implement it yet.
So maybe there's space for more solutions in the same space but Devcontainers are very feature rich. And not to mention they have a huge user base via VSCode.
The killer combo for us is remote+devcontainers. We use this for GPU access, so you can run a project on one or more GPUs that are on a remote server. You can spin up LLM stuff from a mac air and get the best of both worlds.
This has been my experience. I don't use VSCode and every time I've attempted to play with devcontainers I've just given up and gone back to a docker compose file. I love that they tried to extract the feature out into a stand alone thing, but the juice doesn't seem to be worth the squeeze yet.
Very good question, and even if your product is better it seems like an uphill battle. devcontainers are backed by MS/VS and they have good incentive to make them work.
Why you think your solution will succeed in long run and win over devcontainers?
I don't get how containers address "dependency hell". Is there some language that only supports installing libraries system wide? I've used a lot of different languages and yet to come across one.
I've worked on projects where the original dev has used containers for everything. It's super clunky and annoying. I don't want to use a different bash config just for working on that project. I've set my own up for a reason. All it makes me wonder is what are you afraid of? Why do you feel the need to isolate dev projects to this extent?
Isolation works both ways.
By isolating your dev project, you don't expose your host to the mess the project can create... and you don't expose your project to the mess that can exist on your host.
With dev containers, you can define your ENV VAR, your aliases... independently from what exists on your host. And it will exists straight out the box: you checkout the project, launch the dev container and you're ready to go.
As soon as you're done with this project, you delete the container and not a single trace of the project exists on your host.
No matter how many custom things the project required to run.
I'm kinda horrified to think there might be people writing C who don't know how to handle library versions. Somehow I don't think that is the target audience here, by I might be wrong.
While this is true, this project seems to wrap it up in a CLI package for starting and stopping projects. Whereas starting devcontainers, at least as far as I have seen, is always done via VSCode or IDE, so while it technically could be called CLI too, would be a lot more complicated than this project.
I am afraid that despite all these options for containers, I still use my Vagrant scripts that build whole VMs based on my own schemes, use an apt package cache on the host and manage .ssh/config for me to make VSC remotes more seamless.
Almost all my stuff still runs on simple VMs because I cannot rely on my clients to take on more complex cloud infrastructure and I don't want to be stuck managing all of the things forever, so my life involves building customer VMs from build scripts that are adequately similar to my Vagrant boxes.
I use the VMs a lot for simple tests (e.g. of wordpress plugins and themes) so I have gone to the trouble of setting up Avahi with alias support, adding options for mailhog, different databases, different webserver setups I use for WP or Laravel or node.js, setting up an automated WP install etc.; so there are two or three starting configurations. I even had one for Magento before I realised I could be a lot happier without Magento in my life.
I guess it looks a fair bit like devcontainers now, and I should consider migrating over to that. But it's solid and under my control and that counts for a lot.
I had a very strong personal opinion that, unless you expect frequent migrations or horizontal scaling, Docker is overkill and could be considered as bloat in many instances. After I joined my new company, I found out about devbox, and I love it. Now I use it for almost every personal project. It helps you to make the environment reproducible without sacrificing performance.
Yeah... i didn't realize this was a project before hand, do they use their own container framework? seems like too much for my small project but i can apricate your input.
> does your project attempt to provide any isolation security-wise?
Considering that they provide Docker-in-Docker by default, this would have to be a "no" right now. Having the ability to launch Docker containers is equivalent to having root access on the Docker host by default.
Plugging my own tool. I use it for development and running semi-trusted or temporary tools, mounts the current/project dir for isolation, and shuts down automatically when it can.
Hello!! All of your concerns have been addressed in a new commit of mine which is available to all of you now.
Added GPU pass‑through, engine‑agnostic containers (DEVBOX_ENGINE for Podman/rootless), and alternate config filenames to avoid Jetify collisions—while keeping a tiny, CLI‑first flow that works outside VS Code.
I've been using Docker containers for quite some time to do web dev work. The one thing I haven't yet set up is doing mobile dev in a docker environment.
Does devbox support mobile development - Flutter or ReactNative?
FYI there's a well-starred, corporate-backed, similar functionality, Nix-based product with the same name:
https://github.com/jetify-com/devbox https://www.jetify.com/devbox
I usually don't take name clashes as seriously as some people here do, but when it's even in the same general niche, then that's not really a good look. It means the author failed to check the prior art - which is still fine for a (n+1)th hobby project, but not really for something more serious.
I thought that OP linked this devbox since so many subcommands from the cli are almost identical
Again another oversight i also didnt relise i was mirroring docker commands and npm.
Looks like a really fun project. You might want to reconsider the name though, since there is this other devbox from Jetify https://www.jetify.com/devbox that also received quite some attention on HN a while ago https://news.ycombinator.com/item?id=32600821
Yep, also Microsoft Dev Box: https://azure.microsoft.com/en-us/products/dev-box
I am not affiliated with Microsoft and I anal but I think dev box is fine. What we want to avoid is the term dev containers.
https://containers.dev/
> I anal
There has to be a better way to phrase this
Yes, one would think it should have been presented as ANAL - which I think is the preferred way to present an acronym.
I think it’s reasonable. What’s another way, “I’m into backdoor stuff”?
hey, I mean, buttplug.io could always use the contributors
The overlap with Jetpack's devbox name is not fine. Not morally, given the massive overlap in functionality between the two implementations. At the very least, their existence will prevent you from getting a trademark.
Both projects even use devbox.json for their definitions, for crying out loud. If your usage is not compatible with Jetpack's devbox.json, please switch to a different filename ASAP.
I didn't realize our similarities until after i designed like all of it, i didnt do any research before hand sadly causing a lot of issues like this
Also, DevBox (https://www.dev-box.app/) which is a collection of small tools for multiple platforms which I've been building since 2021.
Good point. I remember testing out Jetify's version a while back and switching away from it due to some issue I was having. I 100% thought this project was the same, just with a new website, as I did not remember much of the implementation details. Both of them even use `devbox.json` as the configuration file...
Well its not the same programming wise so your problem might be fixed on ours but as i said in another reply i wasnt aware of the existing project and our overlaps i did no research before hand sadly
We've been using devcontainers for this, as it's already got good support in vscode. Could you perhaps "elevator pitch" the main differences between devbox and devcontainers?
Yes, it feels very similar to Devcontainers.
But having tried Devcontainers a lot, it feels like its probably a complex specification since outside of VSCode every implementation has issues.
The CLI on Mac has weird user permission issues. Cursor's implementation is very flaky. Zed doesn't implement it yet.
So maybe there's space for more solutions in the same space but Devcontainers are very feature rich. And not to mention they have a huge user base via VSCode.
The killer combo for us is remote+devcontainers. We use this for GPU access, so you can run a project on one or more GPUs that are on a remote server. You can spin up LLM stuff from a mac air and get the best of both worlds.
Nice! Do you have any tips or recommendations for a decent setup?
This has been my experience. I don't use VSCode and every time I've attempted to play with devcontainers I've just given up and gone back to a docker compose file. I love that they tried to extract the feature out into a stand alone thing, but the juice doesn't seem to be worth the squeeze yet.
Devcontainers work nicely with docker compose. It's the only way I use it... Really nice to have it all run containers.
https://code.visualstudio.com/docs/devcontainers/create-dev-...
Cool! I haven't seen this feature. Does it add some nice features beyond what a compose file could offer?
Very good question, and even if your product is better it seems like an uphill battle. devcontainers are backed by MS/VS and they have good incentive to make them work.
Why you think your solution will succeed in long run and win over devcontainers?
I don't get how containers address "dependency hell". Is there some language that only supports installing libraries system wide? I've used a lot of different languages and yet to come across one.
I've worked on projects where the original dev has used containers for everything. It's super clunky and annoying. I don't want to use a different bash config just for working on that project. I've set my own up for a reason. All it makes me wonder is what are you afraid of? Why do you feel the need to isolate dev projects to this extent?
Isolation works both ways. By isolating your dev project, you don't expose your host to the mess the project can create... and you don't expose your project to the mess that can exist on your host.
With dev containers, you can define your ENV VAR, your aliases... independently from what exists on your host. And it will exists straight out the box: you checkout the project, launch the dev container and you're ready to go. As soon as you're done with this project, you delete the container and not a single trace of the project exists on your host. No matter how many custom things the project required to run.
And since you have everything in a configuration file, it is breeze to transform your dev container in a production one.
C libraries are easiest to install system wide. The situation with multiple versions of libc is tricky to work with.
Not impossible, just not easy to comprehend by an average dev.
I'm kinda horrified to think there might be people writing C who don't know how to handle library versions. Somehow I don't think that is the target audience here, by I might be wrong.
You might need to install libxml2 in order to use XML parsing library for your high level programming language.
You don't need to be writing C code to be affected by the dependency hell.
So this reinvents devcontainers? https://containers.dev
Why should we use yours? What does it do better or differently?
While this is true, this project seems to wrap it up in a CLI package for starting and stopping projects. Whereas starting devcontainers, at least as far as I have seen, is always done via VSCode or IDE, so while it technically could be called CLI too, would be a lot more complicated than this project.
The devcontainers cli has existed for a while. Definitely not as smooth as using with vscode but it has all the main points.
https://github.com/devcontainers/cli
TIL.
I'm not proponent of installing nodejs apps globally, npm install -g or yarn install -g
There is also a CLI for dev containers. I use it for unattended builds.
I am afraid that despite all these options for containers, I still use my Vagrant scripts that build whole VMs based on my own schemes, use an apt package cache on the host and manage .ssh/config for me to make VSC remotes more seamless.
Almost all my stuff still runs on simple VMs because I cannot rely on my clients to take on more complex cloud infrastructure and I don't want to be stuck managing all of the things forever, so my life involves building customer VMs from build scripts that are adequately similar to my Vagrant boxes.
I use the VMs a lot for simple tests (e.g. of wordpress plugins and themes) so I have gone to the trouble of setting up Avahi with alias support, adding options for mailhog, different databases, different webserver setups I use for WP or Laravel or node.js, setting up an automated WP install etc.; so there are two or three starting configurations. I even had one for Magento before I realised I could be a lot happier without Magento in my life.
I guess it looks a fair bit like devcontainers now, and I should consider migrating over to that. But it's solid and under my control and that counts for a lot.
How does this compare to toolbx? (https://containertoolbx.org/)
And Distrobox: https://distrobox.it
One obvious one is that Toolbx and Distrobox are based on Podman, for one.
> One obvious one is that Toolbx and Distrobox are based on Podman, for one.
And as a result, the containers are rootless.
I had a very strong personal opinion that, unless you expect frequent migrations or horizontal scaling, Docker is overkill and could be considered as bloat in many instances. After I joined my new company, I found out about devbox, and I love it. Now I use it for almost every personal project. It helps you to make the environment reproducible without sacrificing performance.
However, I use https://www.jetify.com/devbox.
Yeah... i didn't realize this was a project before hand, do they use their own container framework? seems like too much for my small project but i can apricate your input.
I always like to see new projects using containers. Two questions:
- how is your devbox.json file different from a Dockerfile/Containerfile?
- does your project attempt to provide any isolation security-wise?
> does your project attempt to provide any isolation security-wise?
Considering that they provide Docker-in-Docker by default, this would have to be a "no" right now. Having the ability to launch Docker containers is equivalent to having root access on the Docker host by default.
erm, that name is already taken. https://jetify-com.vercel.app/docs/devbox/
Plugging my own tool. I use it for development and running semi-trusted or temporary tools, mounts the current/project dir for isolation, and shuts down automatically when it can.
Container Shell - https://github.com/jrz/container-shell
Hello!! All of your concerns have been addressed in a new commit of mine which is available to all of you now.
Added GPU pass‑through, engine‑agnostic containers (DEVBOX_ENGINE for Podman/rootless), and alternate config filenames to avoid Jetify collisions—while keeping a tiny, CLI‑first flow that works outside VS Code.
https://github.com/itzCozi/devbox/commit/d05c8980db7fb907f31...
I thought you are talking about https://github.com/jetify-com/devbox :D
There is also Devpod with a nice UI.
https://devpod.sh/
I've been using Docker containers for quite some time to do web dev work. The one thing I haven't yet set up is doing mobile dev in a docker environment.
Does devbox support mobile development - Flutter or ReactNative?
Yes hypothetically i haven't tested it but i am not sure why it wouldnt aside from machine constraints
Would love to use something like this for NixOS as an escape hatch, but its debian only. DistroBox always gives me trouble.
OP should consider changing their alias.
Too deep in and i also make projects for a week then abandon them for a while so its not very much worth it i dont think
Anything to do with "dependency hell", I can't see a better solution than Nix.
I’ve been doing a version of this using bash scripts for a long time! Thanks for making it
There are already dev containers
"There is already the Ford Model T"
It's good that we get more options. I like ddev, will try this as well.
how does it compare to testcontainers? https://www.npmjs.com/package/testcontainers
Amazing amazing project, thank you for sharing this
Oh! thank you for your appreciation means a lot.