Readit News logoReadit News
Posted by u/gentele 3 years ago
Show HN: DevPod – Codespaces but Open Source, Client-Only, and Unopinionatedgithub.com/loft-sh/devpod...
Hi everyone - Looking for feedback for this new open source project we launched. It's called DevPod and it's built on the devcontainer.json standard to create reproducible dev environments. It lets you spin up dev environments in any infra, kind of like a Terraform but for dev environments.

Compared to hosted services such as Github Codespaces, JetBrains Spaces, or Google Cloud Workstations, DevPod has the following advantages:

- Open Source: DevPod is 100% open-source and extensible. A provider doesn’t exist? Just create your own.

- Client-only: No need to install a server backend. DevPod runs solely on your computer.

- Cross IDE support: VS Code and the full JetBrains suite is supported. Other IDEs can be connected through ssh.

- Rich feature set: DevPod already supports prebuilds, auto inactivity shutdown, git & docker credentials sync, with many more features to come.

I've gotten tons of good feedback from folks here in the past for other OSS projects, so I'm hoping to get some thoughts on this new project today.

What do you think? Open for any feedback - even if you think DevPod sucks, let me know.

eatmyshorts · 3 years ago
This sounds kind of like Tilt and DevSpace, but for just general purpose containers. From a quick look through the website, I didn't see these features, but these would be great additions:

- File sync with the local filesystem and the container (2-way)

- Port-forwarding to localhost for debugging (I guess the DevPod way is to run the entire IDE in the container, but I love Tilt/DevSpace for allowing me to work in my local fat IDE)

gentele · 3 years ago
Port-forwarding and using your local IDE is already working in DevPod today. We also added auto-port-forward where it watches what happens inside the container and then starts port-forwarding automagically.

File sync: That is a great idea. We got that in DevSpace already as you mentioned and we definitely think this could be super valuable in DevPod as well. Right now, a git push and then pull is required to get things from inside DevPod updated on local but with sync this would be even easier and faster.

darkteflon · 3 years ago
We have a designer on the team that uses a Windows box. This could be a great way to get him spun up without having to build him a local setup and manage two sets of local dependencies for him on Windows and us on macOS.

How well does it work for web dev - Django specifically? Is it as simple as running the dev server and accessing the locally-forwarded port through a local browser? Are there any gotchas to be aware of? Thanks!

zbhoy · 3 years ago
It is made by the same company that makes DevSpace so that tracks
endofreach · 3 years ago
A bit off topic - but does anyone know of a „pod“-solution with a mobile UI / optimized workflow?

I often find myself wanting to code on an existing project from my phone. Yes, vscode kind of works but it‘s not a quite the experience i‘m looking for.

dchuk · 3 years ago
I’m a solo dev, and just last night got a good local docker compose workflow setup for writing rails apps on my m1 Mac using Colima last night.

When I fired it up in vs code, I was immediately presented with all the dev container stuff, and I wasn’t sure what to do next.

I assumed I’d write and store all of my code locally in my Mac, then just use volumes to sync it over and run docker commands on my machine to interact with the app…

Should I use dev containers instead? Should I use dev pods? I want to be able to leave code for a while and come back and easily fire it up, I want simple deploys on single servers when ready (compose or swarm)…but I just keep running into so many options I’m getting confused.

gentele · 3 years ago
Adding devcontainer.json and then using DevPod with it should be pretty straight-forward for you. You can use docker-compose inside devcontainer.json if you want to reuse your existing setup.
dchuk · 3 years ago
Well I guess that’s my question then. Does the devpod become part of my docker compose app? Or does it run separately of it?
vegasje · 3 years ago
This looks like it could be exactly what I have been looking for--nice work!

I manage multiple AWS accounts, and my credentials file has multiple profiles in it. When using the AWS provider, is it possible to specify which profile to use?

89luca89 · 3 years ago
Hi! For now there is no exposed option for profile-selecting in the AWS Provider You can add multiple instances of the AWS provider and specify token/secret for each of them

But I'll open an issue to investigate how to implement the profile-selection, thanks for the feedback :)

EDIT: implemented

89luca89 · 3 years ago
I've just updated the AWS Provider, now you can use target profiles either setting an env variable AWS_PROFILE when you add the provider, or setting the option (from CLI or from GUI) to the profile you need
vegasje · 3 years ago
Thank you for that!
dmattia · 3 years ago
As someone who setup Codespaces + local devcontainer support for my company, I'm very impressed from an initial look over.

Could you clarify how authentication happens for things like private Github repos or AWS authentication?

gentele · 3 years ago
Thanks! Sure thing. Happy to clarify on these two topics:

- Private git repos: They work out of the box because DevPod uses regular git to clone repos and authenticate with your git hosting provider. The desktop app injects a lightweight client into the workspace and then connects from your machine to the client to inject your git credentials into the workspace. This can also be disabled for untrusted or public workspaces but it's by default on because it allows you to `git pull/push` from within the workspace without any issues.

- Credentials for providers: If you use the AWS, GCP, DO, Kubernetes or any other remote provider to provision dev workspaces with DevPod, it requires that either a) you have the credentials on your local machine (e.g. already signed-in via AWS CLI or gcloud CLI or valid kube-context/kube-config for k8s) or b) you provide the credentials directly to DevPod when adding the provider (e.g. provide k8s service account token or gcloud/aws tokens). Option a) would be my recommendation because credentials are stored safely by the respective cloud provider CLIs rather than having to trust DevPod to store them safely for you.

loa_in_ · 3 years ago
That's very a very good sight the see! Comparable solutions are full of dark patterns on sign up, and I already gave up and decided not to give them any access to any projects. This is a game changer.
gentele · 3 years ago
Thanks! Glad to hear that
gkapur · 3 years ago
Congratulations on getting the product out! Seeing innovation in local development, which seems to satisfy a lot of use cases with MacBook compute and memory increasing all the time, with the flexibility of using the cloud will be super helpful to some companies looking to save on cost!
gentele · 3 years ago
Thanks!
dirk_klement · 3 years ago
Like, what are the situations one would use this?