This direction looks good to me! And it seems like we can always mature the docker-compose over time when we need to

I like this direction too.

I (and I think users as well) would benefit from a description of how and why this compose differs from the deploy_docker example (postgres? different image name scheme?). It would be super cool if the only difference between this and the deploy_docker example were a different dagster.yaml, maybe attached via a volume mount rather than baked in to the image.

I could be wrong but I think a lot of users will want to use RDS. Is postgres just for ease of trying things out?

In D8292#217060, @johann wrote:

I (and I think users as well) would benefit from a description of how and why this compose differs from the deploy_docker example (postgres? different image name scheme?). It would be super cool if the only difference between this and the deploy_docker example were a different dagster.yaml, maybe attached via a volume mount rather than baked in to the image.

In D8292#217061, @dgibson wrote:

yeah to johann's point - the docker-compose setup here is basically identical other than that the image comes from $REGISTRY_URL right? (and the RunLauncher will be an ECSRunLauncher eventually - although will that similarly be able to use the DockerRunLauncher with different Docker creds do you think?)

I don't think they necessarily need to share code, but making the difference clear seems like a good idea

I don't know yet if the ECSRunLauncher is actually going to share any of the mechanics of the DockerRunLauncher because doing so will probably require us to mount the Docker socket as a volume. I'd be a little surprised if we can do this in ECS and I have a hunch we'll probably need to spin up new tasks via the ECS API.

So the differences are basically:

• no network definitions (just letting ECS take care of that for us so that it sets up things like service discovery using its defaults)
• images come from the ECR repository
• not exposing the docker socket

In D8292#217060, @johann wrote:

I could be wrong but I think a lot of users will want to use RDS. Is postgres just for ease of trying things out?

Yeah, that's my assumption too. I'm including it for the same reason that the Helm charts include it - ease of getting up and running with an expectation that people will switch to their own database. I was considering adding a "Next steps" section with some high level instructions on what you might want to do to get this production ready.