Our team today announced an open beta of a service that spins up Nix-based developer environments Announcing Devbox Cloud
When you use it to spin up a cloud VM we automatically use Nix to set up the environment. For now we look for a devbox.json file generated by our OSS tool (GitHub - jetpack-io/devbox: Instant, easy, and predictable development environments) but we want to make the cloud service usable by the entire Nix community; whether your using our tool or using nix directly. Therefore we plan to support projects with a flake.nix very soon.
Curious if any of you have feedback on this product and how it should better evolve to serve your needs.
Hi @loreto ,
I read Devbox Cloud “Getting Started from your Terminal”.
What is the advantage over starting some VM in my favorite data center close to me using some simple script and then SSH there (with port forwarding as needed) and run
git clone +
nix develop or
devbox shell to get source code and environment ?
One more question, who pays for VM and what are the VM specs ?
Devbox does the following things out of the box without any configuration:
- We start VMs in the region closest to you and have VMs available in over 26 regions around the world.
- We setup a nix cache in each of those regions so you get faster nix package installation (we’re continuing to improve in the cache)
- We automatically setup file syncing between your local project and the cloud VM so that you can edit the local files with any editor you want and they’ll be reflected on the cloud automatically.
- We setup a secure SSH bastion that gates all connections. Allowing you to keep your VMs protected without having to setup a VPN yourself.
- Nix and Devbox comes pre-installed in the VMs.
- (coming soon) if you have a flake.nix we’ll automatically setup the nix shell and install all required packages.
It is possible to do all those things manually; but they usually require a bunch of setup. For developers that don’t have previously setup these pieces, Devbox Cloud makes it much easier.
During our beta period, the VMs are free as we want people to use it and give us feedback. After beta we’ll keep offering a free tier that is free to use up to X hours; and for more hours you would have to pay.
The beta VMs are 1 CPU and 1Gb of RAM; but we can bump interested users to a 4 CPU 8GB RAM vm (and that’s what we plan to standardize on once we’ve worked out all the kinks). Beefier VMs will be available in the paid plans too if required.
I forgot to add that we also automatically scale down VMs to zero if they are idle for too long. That way you don’t end up racking up costs if you forget to shutdown a VM.
Thank you very much for replying.
If you don’t mind, I have few more questions.
If I understand things correctly, I have my code editor (or IDE) running locally with my local copy of source code, but whole environment (for example Python with dependencies) exists only on remote VM. How can my editor access the remote environment for things like LSP ?
Also what are actually the use cases of such solution ?
I launch VMs for development mostly if my local machine is not powerful enough for what I am doing or I need to access some very large data located for example in some S3 bucket. For the first use case I would go for something at least with 32 GB of RAM/16 CPUs with fastest possible storage and for the second one, I need to launch VM in the region where my data is (not where I am) and again, if data is big, then I need much more powerful machine than 4 CPU 8GB RAM.
Thank you for your time answering my questions.
Since Discourse is kind enough to hint: Welcome to the community!
@imincik Great questions.
When we spin up a VM on the cloud, we automatically make it accessible over SSH as well.
For your editor to have auto completion, and other similar features, you have two options:
If you have an editor that supports remote development over ssh, you can set that up and have your editor talk to the remote environment. Both VSCode and Jetbrains support this.
If you have an editor that does not natively support a remote ssh environment; then what most people do is that they recreate the environment locally too. Because we’re powered by nix; that’s easy to do. Your local environment is then used by your editor for things like auto completion, while your cloud environment is used to run the application on the cloud.
a) There’s the case where you need better/different hardware than what you have locally. This is the case you mention and we totally agree with it. We do plan to make bigger VMs available too. We plan to offer VMs with GPUs; and we plan to give the VM preconfigured access to a Kubernetes cluster where you could spin up background jobs.
b) There’s a use case where you need/want better access to cloud services while you’re developing. For example, you might want a temporary S3 bucket to test against. We have some ideas we’re still working on to help here.
c) Sometimes you just want to spin up an ephemeral environment super easily that’s pre-set up to work on a branch. Maybe it’s a repo that you don’t normally work on, for which you’re making a small change. Devbox Cloud will make it easy for repos to add badges - if you click them, and the project uses Nix, you can get a pre-setup environment for that project in a single click.
d) We want to make it possible to share VMs with others. That can be helpful, for example, if your stuck debugging something. With sharing, you could put the entire environment you’re trying to debug on a VM, send someone else a link, and have them run commands to help you debug an issue.
@blaggacao Thank you! Much appreciated.
@loreto , thank you for your answers.