Many developers are excited about dev containers, but until now, people needed to use a managed service like Codespaces or Gitpod to feel that dev container magic. DevPod is a new open source tool that allows users to launch dev containers with any infrastructure that they have available. DevPod uses a provider model like Terraform's, and there are currently providers for many different infrastructures, like local Docker daemons, Kubernetes, AWS, and several other cloud providers. It's also possible to develop providers if you don't find one that fits your needs. While you can choose the infra you want to use with DevPod, you don't have to manage it. DevPod handles the lifecycle of the infrastructure it runs on, and it can even suspend cloud resources automatically to save on costs. DevPod uses the open devcontainer.json standard, so it's compatible with VS Code and many other IDEs, as well as tools like Codespaces. We'll look at how DevPod works and get into a quick demo that showcases how it can help developers and teams standardize their dev environments.

1. Open Source Dev
Containers with DevPod
Rich Burroughs
FOSSY Portland, 2023

2. I’ve been involved in open source communities for 30 years
● Creator and host of the Kube Cuddle podcast, where I
interview people from the Kubernetes community
● I worked in Ops/infrastructure/SRE for 20+ years
● I have seen some things
Hi, my name is Rich Burroughs
Rich Burroughs
Staff Developer Advocate
Loft Labs

3. Proprietary software used/mentioned in this talk
● macOS, Google Slides
● Microsoft VS Code, Jetbrains IDEs
● GitHub Codespaces, Gitpod

4. Why dev containers?

7. I was doing DevOps before DevOps was cool.
● I worked at a small startup with a payments product
● I was embedded with a team of application developers
● They wrote services in Java and several other languages
● I did manual deploys, configured services, troubleshooted problems

8. What happened when a new dev was hired?
1. They were handed a laptop
2. They went to a Wiki page with lots of instructions
3. They installed a bunch of prerequisite tools
4. They downloaded the source for all the apps they worked with
5. They built all the apps from source
6. They tried to run the services locally
7. They usually had to figure out some port conflicts, resources, etc.

10. Another issue is dependencies
● Developers sometimes have to manage dependencies for multiple versions
of their languages, and multiple languages
● The fact that tools like nvm, pyenv, rvm, etc. are so common shows what a
problem this is
● Ruby has rvm, rbenv, Bundler, and more

12. What did we learn from Infrastructure as Code?
● It’s self-documenting
● It doesn’t get stale like a Wiki page
● Helps with onboarding

13. Can we do dev environments as code?

15. Codespaces is great, but…
● It’s proprietary
● It’s a managed service
● Free version limits hours (about 30 a week) and storage

16. Dev Containers standard
● Created initially by Microsoft
● Open standard
● Almost everything you need to develop is in the container
● Configuration is defined in the devcontainer.json file

19. DevPod is…
● Open source
○ Mozilla Public License 2.0
● Client only
○ Ships as a lightweight desktop app for macOS, Linux, and Windows
○ There’s also a CLI
○ Nothing to install on the server
○ You can change where you run dev containers on the fly
● Unopinionated
○ We want you to be able to use DevPod with any infrastructure you have

20. Uses the Dev Container standard

21. Providers
DevPod uses the concept of providers, similar to Terraform.
Providers define how DevPod creates and manages the infrastructure to run the
dev containers.

22. Non-machine providers
● Docker (local or remote)
● Kubernetes (uses a kube context)
● SSH (runs containers on the target host)

23. Machine providers
● AWS, GCP, Azure
● Digital Ocean, Civo Cloud

24. Provisioning Process
1. Initialize provider
2. Optional: Create Machine (VM)
to host your dev environment
3. Create Dev Container
4. Launch and connect IDE
Dev Container
Machine
Provider
Agent
Agent

25. Hello World!
http://127.0.0.1:9000
Dev Container Agent
Port-Forwarding
SSH Remote
Connection

26. Community providers
You can use providers built by other community members.
Some that have been shared include:
● Cloudbit
● Flow
● Hetzner
● OVH Cloud
● Scaleaway

27. Custom providers
● You can write your own provider with a few lines of code
● They live in a provider.yaml file
● You can run them from your filesystem
● More info about developing providers is in the docs

29. DevPod manages the infrastructure
● You can set an inactivity timeout per provider
● When a machine has no active workspaces running it will sleep
● When all workspaces for a machine are gone, it will be deleted

30. Other topics - see the docs
● You can reuse local Git and Docker credentials with a credentials helper
● You can prebuild the dev container
● DevPod also works with vim/Neovim

31. Demo time

32. More resources
● DevPod website: https://devpod.sh
● DevPod GitHub: https://github.com/loft-sh/devpod
● DevPod and Colima tutorial:
https://loft.sh/blog/dev-containers-with-colima-and-devpod/
● Development Containers standard: https://containers.dev
● Loft Community Slack #devpod channel: https://slack.loft.sh

33. Thank you
● FOSSY organizers and volunteers
● Container Days - Josh Berkus
● DevPod maintainers, contributors, and community
● Thank you for watching

34. Slides