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?
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...
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.
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 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.
> 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.
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?
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.
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-...
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?
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
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.
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...
Also, DevBox (https://www.dev-box.app/) which is a collection of small tools for multiple platforms which I've been building since 2021.
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
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.
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.
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.
I thought you are talking about https://github.com/jetify-com/devbox :D
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
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?
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.
Amazing amazing project, thank you for sharing this
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.
I’ve been doing a version of this using bash scripts for a long time! Thanks for making it
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
There are already dev containers
"There is already the Ford Model T"
There is also Devpod with a nice UI.
https://devpod.sh/
Anything to do with "dependency hell", I can't see a better solution than Nix.