Codespaces but open-source, client-only, and unopinionated
devpod.sh
devpod.sh
DevPod is basically Vagrant but with containers, which brings a ton of benefits over the former VM-centric design. You can maintain an entire team (or organization) with one immutable development environment, to get away from the constant toil of fixing random problems on random people's dev environments that happened because they changed something locally and don't have an immutable environment to restore.
The fact that it's self-hosted means you can take it anywhere (your laptop, GCloud, AWS, Azure, etc). Containers means you can save resources or scale it, reuse public containers and container ecosystem tools. Unopinionated means you aren't forced to use one IDE or platform. Open Source means you can read the source to figure out what's going on and hack in a solution if needed.
This one is still early days it seems, as it doesn't run on my Mac (I opened an issue). But the benefits once it works will be incredible. I've been trying to onboard our teams to Devspace, which has its warts [and lack of docs], but is still lightyears better than most other solutions. Once DevPod is stable I'll be looking into moving to it.
DevPod is another implementation of the devcontainer spec, the most used one being the aforementioned devcontainer cli which vscode uses, or supplies, via its integration.
If you’re having problems with DevPod while they iron out the kinks you might want to try the devcontainer cli, which can build the images, and run them.
- Gitpod, a SaaS competitor to Codespaces. http://gitpod.io
- Coder, which I guess is the more enterprisey self-hosted Codespaces alternative? https://coder.com
- This project, Devpod, seems to be a polished experience but not centralized like Coder.
- I recently stumbled upon Recode, which looks like a more indie take on the problem. https://github.com/recode-sh/cli
https://github.com/hashicorp/vagrant
Possibly devenv, as well.. Though I haven't personally tried it
I haven't had a need to reach for it yet, but I will probably try it out at some point.
On the other hand, the ability to put non python deps in a place that feels like a venv... feels pretty magical.
Now there is overhead for mounting local volumes into the container, but I’ve found them to be negligible on my Apple Silicon Mac’s in the last year or 2. (Apple seems to have been the one to fix it with their new virtualization framework which docker for Mac supports).
Now back when they first added their APFS file system things were atrociously slow when it came to Disk IO (as in 10x slowdowns or more) and there were various workarounds but it seems resolved to me now.
The changelog lists both improvements and bug fixes and there's even apparently some effort to port it away from ruby: https://github.com/hashicorp/vagrant/blob/v2.3.7/internal/cl...
If you happen to have the exact set of needs that one of these products solve, then it can probably work fairly well. But, even when working on "web" stuff, I always find myself feeling like they're just never quite as good as just doing things locally. I feel like devcontainers and cloud coding in general are more impressive to those who haven't managed to tame their own dev environments and are seeing a solution to this for the first time.
It's also clearly useful for people on iPads and other devices that are either too low end to run/compile your code or arbitrarily limited to prevent it. However, with how powerful iPads are nowadays, it feels like if Apple ever allowed apps to use virtualization extensions, it would probably be a better solution for a lot of people who do not need a huge cloud workstation with a lot of RAM. I imagine your average Rails app or Go backend would just have no problem running directly on an iPad.
1. https://aws.amazon.com/cloud9/
2. https://aws.amazon.com/blogs/architecture/field-notes-use-aw... (2021)
https://techcommunity.microsoft.com/t5/azure-developer-commu...
Maybe this will be nice to get Jetbrains IDEs working with the devcontainer standard, since IIRC they don't support this at the moment
https://github.com/JetBrains/projector-docker
Unfortunately, It's hard to tell if JetBrains Gateway will keep all of the remote dev features or not.
Devcontainers are a good example of their strategy. VS Code's source code is open source, but the devcontainers extension is not [2] and alternative vscode-in-the-browser providers are not able to use the devcontainers extension as they're not allowed to use the official VS Code extension marketplace.
[1] https://ghuntley.com/fracture/ [2] https://twitter.com/castrojo/status/1671544329402302464?s=20
We need to support local dev environments first, with the exact same config a developer can then move to the cloud.
See https://github.com/jetpack-io/devbox for how this can be achieved and https://www.mikenikles.com/blog/dev-environments-in-the-clou... for my thoughts after 3 years of working in this space.
- VR headsets typically need very low frame times so that they can account for you moving your head and not give you motion sickness. The typical threshold is ~10ms, but it can be improved with good reprojection tech
- Older LCD TVs often added >50ms of input lag, although this is much less of a problem now, but this was enough for lots of people in the 360/PS3 era of consoles
[15:25:45] debug Run command provider command: ssh -oStrictHostKeyChecking=no
Edit: I've managed to make it work with my own solution (https://github.com/rcarmo/azure-dev-bootstrap). It works OK, but since I'm used to provisioning the back-end boxes by myself and using VS Code Remote, there's little practical difference (also, my setup adds the dev box to my Tailscale network).
Would be really nice if the baseline SSH provider (and assumptions as to how the remote SSH server is set up) were fixed, and if I could get it to work on an iPad with Blink shell (edge use case, I know, but I do use that a lot, or just an RDP on Linux desktop).
Oh, and add B-series VMs to the Azure provider. For burstable use like coding, testing, etc., those are much more cost effective.
Otherwise DX would be totally ruined. Totally.
> work on an iPad
I never tried, but from the distance it looks like _working_ on such kind of devices is a torture, what's are your impressions, effectiveness comparison to working on laptop (desktop) with real keyboard?
- My main machine is a Mac desktop. I am not looking to add another powerful machine to the mix that I'm not going to use regularly. The iPad (or even another high quality laptop) would be just used as another beautiful screen, to work or watch Netflix on.
- I have a high quality, ergonomic Bluetooth keyboard that I pair with my both my Mac and my iPad. This means my ergonomics with my iPad is better than using a laptop with it's attached keyboard.
- I'm not looking to do long work sessions on these devices, although I honestly could. It's more for one off things, for updating my org-notes, for having a quick cafe work session, etc.
(I am assuming that this, and the attempt to do passwordless sudo on the remote machine, simplifies the developers' life a lot since they don't have to put up prompts for you to validate the host key or do privilege escalation remotely, but they are must haves if I am to trust this solution.)
As to the iPad, I have been doing that for many, many years: https://taoofmac.com/space/blog/2016/11/06/1930 (the date on the URL does not denote the first mention). It is an excellent way to work for many hours with a quiet, cool (as in temperature) machine from remote locations.
My understanding of the value of codespaces was instant start up, literally zero to download locally, and centralised definition. Does this mean I would go back to have to downloading everything locally, albeit in a nice sandboxed package with a neat definition language and convenient command?
Maybe my assumptions are wrong though…?
However, once you're aware of this, honestly it's not that big of a deal. Docker rebuilds are pretty fast nowadays, and you can use tools like just to make the DX a little easier by adding macros to run stuff in a container.
End of the day though, folks are all gonna have their own way of working, and I think dev containers could have an advantage for peeps doing remote development. It would be nice to have a system where our developers could dial in to a container with everything they need from anywhere they want to work.
How often is this actually necessary? I've had projects that stick with the same dependencies for weeks/months and don't need anything new added outside of periodic version updates. There, most of the changes were the actual code, that was needed for shipping business functionality.
Furthermore, with layer caching, re-building isn't always a very big issue, though I'll admit that the slowness can definitely be problematic! Except for the fact that you don't have to pollute your local workstation with random packages/runtimes (that might conflict with packages for other projects, depending on the technologies you use and what is installed on a per project basis or globally), and the fact that you get mostly reproducible environments quite easily - both of those are great, at least when it works!
> ...dealing with permissions differences for volume mounts;
This is definitely a big mess, even worse if you need to run Windows on your workstation for whatever reason, as opposed to a Linux distro (though I guess WSL can help). I personally ran into bunches of issues when mounting files, that more or less shattered the illusion of containers solving the dev environment problem sufficiently: https://blog.kronis.dev/everything%20is%20broken/containers-...
But for what it's worth, at least they're trying and are okay for the most part otherwise.
Think "I have several teams and the output of 'team a' is a dependency of 'team b'" and 'team a' needs to release twice a day".
That's quite the fast paced environment! In that case the shortcoming seems like a valid pain point, provided that you need to launch everything locally with debugging (e.g. breakpoints/instrumentation) vs just downloading a new container version and running it.
What's the workflow for this?
A related issue for us is being able to test another developer's pull request with database migrations without wiping out your current database state. Is there a Devpods workflow for this?
We give you a serverless PostgreSQL database per branch in your code. [via Neon.tech] Each time you branch your code we grab the latest snapshot of your production database which is de-identified and transformed [Transformations are via TypeScript] and a subset of the original.
If a coworker and yourself are coding against the same branch you're coding against the same database.
Your devs only run a single command `snaplet dev` and all this happens automatically in the background.
[1]http://blog.pamelafox.org/2022/11/running-postgresql-in-devc... [2]https://github.com/pascalbreuninger/devpod-react-server-comp...
Would be happy to discuss getting a PoC setup to see if it helps in your case, or to answer any questions, feel free to reach out
Huh? Yes, it contains silicon.
I get they are abbreviating amd64 but still... I've never seen it done like this...
“Mac (Apple)”
I'll add that this is the first site that misdetects anything like that.
Everyone does it, but I think that's a mistake. What I want is something where I can build and publish a dev container to my local Docker registry and then use that container to develop until I decide I need to build an updated version due to changes in the OS, dependencies, etc..
To help clarify, look at this picture [2]. I'd want everything up to dependencies or resources, plus all of the tooling needed to make the Jetbrains Gateway, etc. work in the dev container. I want to build that container on a calendar based schedule (ex: daily) and have everything I need to develop accessible via local repositories that I can use without connecting to the internet.
Long ago I came to the conclusion that most Docker builds aren't repeatable, so the idea of re-building a consistent environment seems naive. For example:
RUN apt-get update && apt-get install vim
So, even if your intent is to build a container with the most up-to-date versions of everything, a transient failure between the update and install commands can leave you with ancient versions of dependencies, even if you intended everything to be up-to-date. This is especially true if you're using a local APT cache like Sonatype Nexus where the upstream 'update' might fail and the local cache probably has old versions of all the dependencies, allowing the install command to succeed.
IMO it's better just to assume you have zero guarantees when (re)building Docker images and you're better off adopting a strategy of build, publish, use.
1. https://devpod.sh/docs/developing-in-workspaces/devcontainer...
2. https://phauer.com/2019/no-fat-jar-in-docker-image/#the-solu...
Tiny correction that got me confused: an exit code of '0' would actually mean 'success', so you probably just meant that it could fail at any moment.
But also, this can happen any time external servers are accessed, regardless of the tool. An npm install could fail any time without warning, if the servers are down. Devs should expect their supply chain to break sooner or later, and plan accordingly depending on the severity of the consequences.
My example is if you use the Ubuntu debug packages repository, you'll basically never know if the next run will work until 'apt-get update' is run. Those repos are seemingly down or 'reindexing' for hours every few days.
No. It fails and then returns 0 = success. It's a design choice. [1] [2]
> But also, this can happen any time external servers are accessed, regardless of the tool. An npm install could fail any time without warning, if the servers are down.
I think that strengthens my argument that everything should be baked in to the dev container.
Edit: Reviewing those bugs, I see there's a new option to control the behavior:
-eany, --error-on=any
Fail the update command if any error occured, even a transient one.
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776152#15
It’s not perfect but I never have to spin the container down.
No. It looks a bit heavy for what I think is an ideal solution. The way this one works with Jetbrains Gateway is what really piqued my interest.
1. https://devpod.sh/docs/developing-in-workspaces/prebuild-a-w...
One area I struggle with when thinking about building container-based development environments is the best way to avoid mixing in your IDE specific dependencies with your project dependencies. I think some of the commercial tools do this, but I haven't gotten in set up well in my homelab.
I just came across two articles by a former GitPod employer who moved to Coder (these are the two main providers of open-source VS Code in the browser solutions). They're both really interesting.
The first is on how effectively Microsoft has used VS Code to fracture the market place to their advantage by strategically open-sourcing parts of VS Code while keeping many of its best features proprietary (Pylance, the python language server is a good example of this). https://ghuntley.com/fracture/
The second article is about why he thinks Coder's strategy is more promising than GitPod's prompting him to go work for them. It's not as detailed, but it touches on some of the parts of container-based development environments that I've found overly limiting. https://ghuntley.com/integrate/
I have a mix of jetbrains, vs code and vs ent devs, would be great to unify their development experience a little
I guess either "dev environment" means something different to what I understand by the term, or Nixpkgs is considered a "heavyweight server-side setup"?
good job!
i tried same project running locally using VSC’s devcontainer extension too, but that felt really slow on a mac so i abandoned it.
what is devpod doing differently? iirc, running devcontainer directly via extension inside docker had same perf problems with bound volumes. is this solved differently in devpod?
i didn’t compare these two apples to apples style because i tried extension on older computer.
It's pretty crude but hopefully will give people some ideas!
Even just an empty folder!
Thank you.
Internally we use both in our development setup, spinning up remote workspaces using DevPod, installing DevSpace and kind into the devcontainer, then using DevSpace to develop against the cluster. See the vcluster setup[1] as an example
[1]https://github.com/loft-sh/vcluster/tree/main/.devcontainer