Table of Contents
Introducing DevPod - Codespaces but Open Source
Giving the power to the user. Any Infra, any IDE, and Unopinionated.
Download > Add a Provider > Create a Workspace > Start Coding in your IDE
What is DevPod?
Open Source Dev-Environments-As-Code
DevPod is a tool used to create reproducible developer environments. Each developer environment runs in a separate container and is specified through a devcontainer.json. DevPod providers can create these containers on the local computer, any reachable remote machine, or in a public or private cloud. It's also possible to extend DevPod and write your own custom providers.
If you have used Codespaces before, you know how powerful an automated development environment can be. The downside of CodeSpaces is that you can’t control everything and run your development environment anywhere you want. Have you ever thought - what if I had complete control and could do this on my cloud provider or locally, and what if the tool was Open Source?
We are excited to announce DevPod. It gives the user the ability to control where they run their development environment. Unlike other dev environment offerings, DevPod does not host or manage the dev environments. Instead, DevPod introduces a way to define a dev environment which can then be run in any cloud infrastructure or even on a localhost machine using Docker or Kubernetes.
DevPod allows dev teams to take full control over their dev environments, without being locked into a specific provider. Developers can write code in any language, and run it anywhere. For example, they can test on virtual machines, or code in Python with VS Code running on Docker Desktop, or in Go running in EKS. If the provider they need doesn’t exist, they can build it.
You can think of DevPod as the glue connecting your local IDE to a machine you want to use for development. So depending on your project's requirements, you can create a workspace locally on the computer, a powerful cloud machine, or a spare remote computer. Within DevPod, every workspace is managed the same way, which also makes it easy to switch between workspaces that might be hosted somewhere else.
Why DevPod
DevPod uses the open DevContainer standard to create a consistent developer experience no matter what backend you want to use.
Compared to hosted services such as Github Codespaces, JetBrains Spaces, or Google Cloud Workstations, DevPod (self hosted alternative to codespaces) has the following advantages:
Workspaces
A Workspace in DevPod is a containerized development environment that holds a project's source code and the dependencies to work on that project, such as a compiler and debugger. The underlying environment where the container runs is created and managed through a DevPod provider. This allows DevPod to provide a consistent development experience no matter where the container is running, which can be a remote machine in a public cloud, localhost, or even a Kubernetes cluster.
DevPod uses the devcontainer.json specification to configure the development container, which is also used by other popular tools, such as VS Code dev containers or Github Codespaces. This means you can already reuse projects that use this configuration to spin up a workspace in DevPod. If no configuration is found, DevPod will automatically try to determine the programming language used and provide an appropriate template.
A workspace in DevPod can be stopped and restarted without losing its state. This allows you to install additional programs or change the configuration without reconfiguring the container. Depending on the Provider, DevPod will also automatically determine when a workspace is not being used and shut down any unused resources to save costs.
Providers
Providers are simple CLI programs that let DevPod create, manage and run the workspaces requested by the user. In the simplest form, a provider defines a command to create, delete and connect to a virtual machine in a cloud.
DevPod relies on the provider model to allow flexibility and adaptability for any backend of choice. Providers in DevPod are defined through a provider.yaml that defines the necessary options, configuration, binaries, and commands needed to handle workspace creation.
There are multiple providers already created for users. We have also made it easy to create additional providers.
Types of Providers
Provisioning is easy whether you are using containers as a target or Virtual Machines.
Machine Providers
Machine providers will create and manage a VM for the workspace selected. An example of a Machine provider is the AWS Provider, which uses EC2 instances to run the environment. These types of providers will also manage the lifecycle of the VM, starting/stopping and deleting it when needed.
Non-Machine Provider
Non-machine providers are those who will work directly with containers instead of using VMs. An example of this can be the SSH, Kubernetes, and Docker providers. Those providers will not create any VMs but instead directly run the workspace container on the target.
Conclusion
So what do you think of DevPod? Join the community on Slack and let us know. We can’t wait to hear from you about your experiences with DevPod, or answer any questions you may have.
Here are a couple of links to get you started, as well as an overview video to show some of the features of DevPod.
