Patterns for containers in dagger containers? (running Supabase in dagger)

[quartz knoll]

My app runs on Supabase. The Suapbase local development environment is based on docker-compose. It runs ~6-7 containers for various services. I don't want to replicate the whole supabase dev stack, so I'm wondering what the best pattern for this sort of situation is with Dagger?

So far I've got a kinda custom script that starts docker inside the dagger container, mounts a cached volume with postgres data, then starts supabase "normally" using the supabase cli as docker-in-docker. Then I expose the supabase ports from the dagger container as a dagger service.

Is this a good pattern? Is there a better way? How in general is it best to deal with docker-composed based tooling inside of dagger?

[lavish tide]

hi! @stark solar is a maintainer and has this docker module: https://github.com/vito/daggerverse/tree/main/docker

It can ingest a docker-compose.yml and run the containers defined there as Dagger Services, which you can bind to a Contiainer and use.

This was my preferred approach to switching from docker-compose to Dagger as it avoids the overhead of running a Docker daemon in Dagger and leverages Dagger's improved caching capabilities over Docker.

Note that I actually have my own "fork" of vito's module which includes this fix for handling compose files that use services.<service>.env_file: https://github.com/vito/daggerverse/pull/10

Here's my fork if you'd prefer to use that: https://github.com/frantjc/daggerverse/tree/main/compose

It also has the benefit of being up-to-date with Dagger v0.20.8

Note that I did not fork the non-compose Docker functionality from vito's module as I did not intend to take advantage of it

Hope that helps! Let me know if you have any questions.

[quartz knoll]

Awesome, thank you, I'll have a look! I think the issue is that supabase's cli does a whole lot more than just run "docker compose up" so I'm not sure if I'd actually be able to make the stack "pure dagger". I'll have to look more deeply into the supabase cli source to figure that out but that tool looks very useful!

[winter solstice]

Maybe we should make a supabase module 🙂

Does the supabase tool basically embed its own compose file, or it lets the user customize it or supply their own? What's the customization contract

[quartz knoll]

Hmm interesting, just started poking around the supabase/cli repo and it seems they're working on some non-docker runners. @supabase/stack is "Programmatic local Supabase stack for TypeScript. Create a local Supabase runtime from code, then control lifecycle, status, and logs through a small async handle." https://github.com/supabase/cli/tree/develop/packages/stack

They have a docker-compose setup for self-hosting https://github.com/supabase/supabase/blob/master/docker/docker-compose.yml

I'm not sure exactly what config the usual "supabase start" docker devenv uses.

Ah it looks like it's configured as part of the go based cli app https://github.com/supabase/cli/blob/46cc8586b33187d39aa04d684c7ed08340dc71fd/apps/cli-go/internal/start/start.go#L218

so it appears it's not docker-compose for supabase cli, it's all just containers started with configuration directly from the cli's go code

[winter solstice]

Interesting. And it looks like they have a facility for swappable backends for those containers?

(or are currently developing that)

[quartz knoll]

I'm not sure, I have been using supabase for a long time but this is the first time I've really taken a dive into the cli. I guess that's a testament to the quality of supabase, everything just works so I've never really had a reason to!

[quartz knoll]

Supabase regularly publishes blog posts about integrations with interesting tools. They'd probably do one on Dagger and maybe even accept a PR for an "official" dagger module if one were made.

[winter solstice]

We're getting ready to (finally) release Dagger 1.0, which will stabilize the interfaces and general user flow. Once that's done, it will be a perfect time to push for more integrations (and generally more promotion of the tool and what you can do with it). We've been in heads down fix-the-product mode for the last several months

@quartz knoll if I may ask - what's your ultimate goal for supabase+dagger. What's the ideal end state in your particular stack?

[quartz knoll]

I'm making an automated bug triage system, or at least attempting to -- almost have the basics working. It does the following (each as a dagger function)

1. Pulls data from sentry + linear around an issue given a URL
2. Runs a root cause analysis with gpt 5.5 on codex,
3. Spins up a supabase environment with some prod data and headless (framebuffer) browser then uses chrome-devtools to drive it and tries to reproduce the bug,
4. It creates a potential fix on a new branch and runs all tests
5. It spins up the supabase+data+browser service again and tries to verify the fix
6. Opens a PR (if there's a reasonable fix) and posts findings and summary on Linear

[quartz knoll]

Here's how I ended up doing it -- I made an image with all the tooling installed then have a function that starts supabase postgres inside the container and restores a database dump. Then I use that postgres data dir as a CacheVolume so as long as the data is fresh enough I can mount it and don't have to build up a container and restore a database dump with each run. I expose the whole thing as a service.

The reproduction phase of the bug exploration pipeline consumes that service. It starts supabase inside the container with the cached postgres data then calls codex cli which drives chrome with chrome-devtools to navigate through the app and try to reproduce the bug.

and it works! I pointed this pipeline at a sentry issue, it gathered evidence, reproduced the bug on its own, proposed theories on how to fix it, created a patch, tested the patch in the reproduction environment to attempt to verify the fix, then opened a PR and put a comment on the linear issue