creating the workspace is based on docker but within the workspace you're free to do whatever you want, no need to use docker-compose there

But then how is this so different from running "docker-compose" and then do whatever you want withing the container? Is the difference just that they provide ready-made Docker images for certain environments so that you don't have to create your own? Can I get the same images on Dockerhub then?

+1, trying to put it my head (disclaimer - I'm a rare user of local docker, as not being developer), hoping to get some insights which may be helpful in better setup for dev team

Partially, yep. The more important part is that these Docker images run on a remote machine

If you can script your setup steps, you can also run it in a devcontainer, either by using docker-compose[1] to bake it into the workspace image or using lifecycle hooks to run some scripts after creating the workspace[2]

[1]http://blog.pamelafox.org/2022/11/running-postgresql-in-devc... [2]https://github.com/pascalbreuninger/devpod-react-server-comp...

Yep, as we see it they compliment each other quite well. DevPod takes your workspace to the cloud and DevSpace let's you develop against your Kubernetes cluster - potentially the same one you used to start your workspace.

Internally we use both in our development setup, spinning up remote workspaces using DevPod, installing DevSpace and kind into the devcontainer, then using DevSpace to develop against the cluster. See the vcluster setup[1] as an example

[1]https://github.com/loft-sh/vcluster/tree/main/.devcontainer

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.

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

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