manhvu

Has Anyone Used Dev Containers for Elixir Development?

Recently, I’ve heard people using dev containers for development. I want to give it a try—has anyone here developed an Elixir app with them? Any tips or experiences would be appreciated.

I’m working on an Elixir cluster (Phoenix + Postgres) on macOS, with Kubernetes as the deployment environment.

18 comments

#dev-environment

1 1055 18

2025-12-31 17:46:01 UTC

Marked As Solved

billylanchantin

We are using Dev Containers at work. I think of them as a local minima in the current dev tooling landscape. They come with some downsides, sure. But the friction from not using them on a multi-disciplinary team is worse.

Pros:

Gets everything else working too: Your app probably has a collection of non-Elixir software that also must be in place to work. For us that includes multiple DBs and an emulator for testing. Using a Dev Container means all of the software needed for development is covered.
Uniform experience across languages: We use multiple languages. If you want to check on something from another team’s repo, you don’t want to have to get a separate dev environment up and running too. This also applies if you’re using something like Rustler in your Elixir app.
Works for multiple experience levels: Many devs you work with won’t be experienced Elixir devs. A Dev Container ensures that they can do their work too without having to pair with a senior Elixir dev every time something in the configuration changes.
Good VSCode experience: The VSCode integrated Dev Container workflow is quite nice.

Cons:

Slow on MacOS: Using a Dev Container in VSCode on a Mac is slower. Though this is no where near as bad as it was years ago. So if your impression of container speed was set a long time ago, you should reassess.
Poor support for non-integrated editors: E.g. I’ve been watching this Zed issue tracking integrated Dev Containers for some time. (Side note: there appears to be a PR now! I’ll be checking that out after I write this comment.)
New concepts: You have to now learn a new tech stack that is not really required to run your production app (though there will be overlapping concepts if you deploy with K8s). This held me off for a while and I’m still not an expert.
General docker pain points: E.g. mounting and networking are a pain. IME that doesn’t go away.

Despite the cons, the uniformity and consistency of the Dev Container experience are worth their weight in gold. If you’re a solo dev this won’t be as big of a deal (though even then it makes managing e.g. multiple Postgres versions on your machine, say one per project, much easier.) But if you’re on a team I recommend taking on the complexity.

Post #13

Also Liked

rhcarvalho

dev-containers.yml gets into the business of configuring the editor, plugins, shell environment, etc and running that inside of a container. The editor GUI becomes a client to LSP etc running elsewhere. This allows you to replicate the experience on desktop or Web (some companies offering remote development environments).

docker-compose.yml is limited to services that make up your project. Editor, plugins, LSPs, shell, is up to the developer.

Which one you choose depends on what you want to standardize/make readily replicable vs the imposed limitations.

Post #16

DGollings

Personally I’d advise using something like devenv.sh instead of a dev container. Most of the advantages without the disadvantages of Docker.

Been using that for two years, a dev can switch between any project and have the exact same setup as any other dev in a matter of moments

Post #3

allen-munsch

They are nice for a uniform and reproducible development environment.

They are NOT great when used in github’s browser based devcontainer environment ( extremely slow, laggy ).

I see it as trading in one set of problems for another. ( easily reproducible dev envs, for docker debugging issues )

In the same sense that having a web app inside the container network is a pain, because you’ll have a layer of problems arise from the internal DNS, networking layer, volume mount issues, files missing, etc, meaning there’s more stuff to go wrong in comparison to just having the standard stuff go wrong ( service ports not open, dependencies missing )

just my opinion, nice for initial start, less nice for long term debugging, but still okay

It’s a layer of abstraction, so it doesn’t help developers with learning how to do things manually when stuff goes wrong.

It might just be how i like things, but it really bugs me when tools get in the way, and its especially true for visual studio code and dev containers, its just a layer ( hey its great if its working, but at the same time, I don’t want to spend a few hours debugging/configuring/diagnosing the tool, the plugin, the whatever, just so i can get to the work )

Post #4

Last Post!

billylanchantin

Hey sorry, I accidentally credited the wrong person and now I can’t edit my post. It was @rhcarvalho who correctly outlined the benefits of Dev Containers over docker-compose.yml alone.

Post #19