devpod icon indicating copy to clipboard operation
devpod copied to clipboard

Support For Mono Repos

Open kyleburke-meq opened this issue 3 months ago • 15 comments

I'm not sure if this support already exists or not but here is what I am trying to accomplish. I have a mono repo setup like the following below. Each app may have a devcontainer file that points to the service in the docker-compose file for the repo:

my-monorepo/
├── app_1/
│   ├── src/
│   │   └── main.py
│   ├── requirements.txt
│   └── README.md
├── app_2/
│   ├── src/
│   │   └── app.py
│   ├── pyproject.toml
│   └── README.md
├── app_3/
│   ├── src/
│   │   └── index.js
│   ├── package.json
│   └── README.md
├── .devcontainer/
│   ├── app_1.devcontainer.json
│   ├── app_2.devcontainer.json
│   └── app_3.devcontainer.json
├── docker-compose.yml
├── README.md
└── .gitignore

When i use devpod to spin up one of my devcontainers for this project like this: devpod up . --devcontainer-path ./.devcontainer/app_1.devcontainer.json

It spins up the entire compose file but the whole thing acts as a single devpod service? Like if i try and now spin up my other devcontainer: devpod up . --devcontainer-path ./.devcontainer/app_2.devcontainer.json it will say: info Workspace app_1 already exists

I was wondering how i can make devpod use all my devcontainers for the existing containers spun up in docker compose. Is this already possible and if so how?

kyleburke-meq avatar Jul 30 '25 17:07 kyleburke-meq

Have you specified which containers each devcontainer.json should run within the devcontainer itself? ie: "runServices": ["database", "frontend", "nginx", "backend"], (these are the names of the services in the Docker Compose file)

Also, ensure that your workspaces are named differently.

Rich107 avatar Aug 01 '25 12:08 Rich107

@Rich107 heres an example of 2 devcontainers: app_1.devcontainer.json:

{
  "name": "App 1",
  "dockerComposeFile": "../../docker-compose.yaml",
  "service": "app_1",
}

app_2.devcontainer.json:

{
  "name": "App 2",
  "dockerComposeFile": "../../docker-compose.yaml",
  "service": "app_2",
}

when i spin up app_1 via: devpod up . --devcontainer-path ./.devcontainer/app_1.devcontainer.json it sets up all the containers in the docker-compose file (app_1, app_2, app_3) all under the name my-monorepo.

devpod list

    NAME |                     SOURCE                      | MACHINE | PROVIDER | IDE  | LAST USED |  AGE  |  PRO
  -------+-------------------------------------------------+---------+----------+------+-----------+-------+--------
    my-monorepo | local:/my/project/path/my-monorepo |         | docker   | none | 11s       | 2m19s | false

so when i go to spin up app_2 via devpod up . --devcontainer-path ./.devcontainer/app_2.devcontainer.json it gives me this:

10:26:59 info Workspace my-monorepo already exists
10:26:59 info Creating devcontainer...
10:27:01 info Setup container...
10:27:01 info Run 'ssh my-monorepo.devpod' to ssh into the devcontainer

and it doesnt make a new devpod:

devpod list

    NAME |                     SOURCE                      | MACHINE | PROVIDER | IDE  | LAST USED |  AGE  |  PRO
  -------+-------------------------------------------------+---------+----------+------+-----------+-------+--------
    my-monorepo | local:/my/project/path/my-monorepo |         | docker   | none | 11s       | 3m06s | false

kyleburke-meq avatar Aug 01 '25 14:08 kyleburke-meq

Can you share the contents of the Docker Compose file? Is that all of your devcontainer.json?

try this:

{
  "name": "App 1",
  "dockerComposeFile": "../../docker-compose.yaml",
  "service": "app_1",
  "runServices": ["database", "frontend", "nginx", "backend"]
}

In that list, which I have added, you need to specify which containers will run (I have just put in some placeholders for you) in which workspace, otherwise it will start up everything in the docker compose file.

You will probably need these to be different:

Image

I have not done what you are doing just assuming it based on my docker knowlage so happy to give it a bit of back and forth if needed.

Rich107 avatar Aug 01 '25 16:08 Rich107

@Rich107 I want all the containers running in compose. however, i also need a few of them them to be devcontainers (utilizing the same containers docker-compose spun up) so i can develop in them. vscode seems to do this well so im wondering what im missing in devpod.

kyleburke-meq avatar Aug 01 '25 16:08 kyleburke-meq

if I understand correctly, your currently trying to spin everything up more than once. You're going to have to choose which workspaces are going to host which containers, otherwise you will get port clashes etc.

Can you share your docker compose file?

Rich107 avatar Aug 01 '25 17:08 Rich107

And to be clear, you are giving each workspace its own name?

Rich107 avatar Aug 01 '25 17:08 Rich107

@Rich107 I dont have a working compose file for this example. however my real projects compose file works with vscode so im not sure thats the issue.

what I want is a single instance of all my containers grouped under the compose stack from docker-compose. and then for any of the containers with dev files to use those configurations for the existing containers under the compose stack. it looks like the closest thing in devpod is this (however I would lose some functionality)?: https://devpod.sh/docs/developing-in-workspaces/create-a-workspace#existing-local-container

kyleburke-meq avatar Aug 01 '25 17:08 kyleburke-meq

Yeah, that's what I am suggesting you try. Feels like we are talking at cross purposes. Your docker compose file would help me articulate an example of what I am suggesting I am not saying there will be any problems in it.

Say you have 5 services.

Database

Queue

Backend (dev container)

Frontend (dev container)

Worker (dev container)

Similar to this you will need to limit which workspaces run which containers. All your containers would be running but you want them grouped into workspaces. Otherwise they will just clash with each other.

You're probably used to docker compose up then exec into the containers you want. What I am suggesting would be like running 3 docker compose ups but you specify the services in each command. So it would be like:

docker compose up backend database

docker compose up worker queue

docker compose up frontend

So in DevPod world in each devcontainer.json you do something similar where for each workspace, one or more containers run. Which is the syntax I gave you before. All the containers would be running so long as you run all the workspaces.

If your only ever working on one Dev container at a time then that would be a different situation again.

Rich107 avatar Aug 01 '25 18:08 Rich107

@Rich107 Oh i see. that may make sense and I can give it a try though I think devpod using the existing containers may be simplest for my workflow. for example here are all the containers in my stack:

Image

Then in vscode I can run the following command: Image

which will prompt me to open one of the devcontainers in my workspace: Image

and after selecting vscode will just use one of my existing containers in my docker-compose stack applying the devcontainer configs rather than having to spin up its own thing.

now that i say that out loud though i may just be able to write a shell script mimicking this workflow using devpod and running containers in docker.

kyleburke-meq avatar Aug 01 '25 18:08 kyleburke-meq

Interesting, yeah give it a go and post back here.

Rich107 avatar Aug 01 '25 18:08 Rich107

Have you seen this in the settings? not sure if its related:

Image

Rich107 avatar Aug 15 '25 13:08 Rich107

@Rich107 i am not see this experimental tab. i have the beta features tab but it does not have the setting in your screenshot. this is on docker desktop 4.45.0 for macOS

kyleburke-meq avatar Aug 31 '25 16:08 kyleburke-meq

@Rich107 i am not see this experimental tab. i have the beta features tab but it does not have the setting in your screenshot. this is on docker desktop 4.45.0 for macOS

That screenshot is from DevPod :) @kyleburke-meq

Rich107 avatar Aug 31 '25 16:08 Rich107

@Rich107 ah looks like thats only available in the desktop app. im using the cli. but it possibly is the feature im looking for.

kyleburke-meq avatar Sep 02 '25 15:09 kyleburke-meq

This issue is stale because it has been open for 60 days with no activity. It will be closed in 30 days on inactivity.

github-actions[bot] avatar Nov 02 '25 02:11 github-actions[bot]