Show HN: DevPod – Codespaces but Open Source, Client-Only, and Unopinionated | Hacker News Reader

Show HN: DevPod – Codespaces but Open Source, Client-Only, and Unopinionated

github.com

71 pointsgentele31 comments

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.

Open articleView on HN

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)

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.

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!

Exactly. add a devcontainer similar to the example repo in [1], install the devpod app and point it to the repository and your designer is good to go, including port forwarding to their localhost

[1] https://github.com/backendclub/example-django-devcontainers

Thanks! Is it trivial to “copy” container connection information between machines? For example, can I write a devcontainer.json, spin up a back-end on Digital Ocean, make sure it has all the necessary envs and system dependencies and is working correctly, then just copy-paste connection information to that pod and send it to my designer, where he just pastes it into his DevPod desktop app and is off to the races?

Once you set up the provider on the designers machine, you can embed a deep link to the desktop app in your repo, similar to the „open in devpod“ button in our repo [1]. [1] https://github.com/loft-sh/devpod/blob/main/README.md (See line 11). This makes sure they open the correct repo with the provider you configured and are ready to go

For your use case it’d be cool to share provider information between parties. We‘ll think about it, although that might also be a potential selling point for teams and a commercial product…

Perfect, thanks for your time. Provider setup + deep link will work fine for us.

It is made by the same company that makes DevSpace so that tracks

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.

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.

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.

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?

It's a separate desktop app similar to docker desktop. DevPod is very, very lightweight though.

Ok, so I’d have this installed, and then Colima, and then vscode, all on my Mac. For the app I’m working on, I’d run it all in its own docker compose setup, I’d have the source code on my Mac (?), and the dev container would house all of the extensions and language servers and linters I need for this app, but in a separate container from my compose setup, and vs code would talk to it?

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?

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

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

Thank you for that!

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?

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.

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.

Thanks! Glad to hear that

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!

Thanks!

Like, what are the situations one would use this?

Neat! I enjoyed using gitpod a few times, this seems similar. How do they compare?

There are 3 main differences: 1) DevPod is based on GitHub/Microsoft's devcontainer.json standard while GitPod has their own file format 2) DevPod is client-only more like Terraform where the client creates/manages things directly using cloud credentials vs GitPod is a server-side solution to manage and provision dev workspaces 3) DevPod has a provider concept similar to Terraform that allows you to provision dev environments in ANY infra vs GitPod is mostly a hosted solution (they do have the option to host it yourself as well but it's usually you install it to one cloud and then provision in that same cloud vs DevPod is 1 client (no server, see point 2) and then you deploy the dev env in ANY cloud or even locally in Docker or local k8s)

Interesting! Might give this a try some time. I occasionally find myself needing a Linux environment, and my primary device is an arm64 mac, I think it could be useful for that.

More generally what do you see being the prime use cases?

Basically anything you'd use GitHub Codespaces for but without having to pay them a hefty fee + you get to choose your cloud provider (or self-hosted k8s). I.e. if you have some left over aws credits, you could start off with that but quickly change the provider if you need to move to gcp or azure

Are there any plans for an iPadOS client?

we're thinking about it but don't have any immediate plans. Mostly because it's not a straight forward port and we want to make sure it's stable on linux/windows/macOS before tackling mobile. Would be awesome for developing on the road though

Reply on news.ycombinator.com