hey all – we've trying to deploy dagster on ECS, but we've struggled to find a recent enough template to go off of. the guide from the dagster repo (link) says "_Once you're done experimenting with this reference deployment, you should destroy the AWS resources it creates._", so i can't whether this is meant to be used in production. are there any good recent deployment templates that you'd recommend following?

My team is using a slightly customized deployment we built using this reference in production. I think that the "_should destroy"_ language there is not really accurate

That docker compose example is our current recommendation.

Once you’re done experimenting with this reference deployment, you should destroy the AWS resources it creates.

is just to try to avoid someone getting charges by accidentally leaving a demo deployment up 🙂

@johann so does that mean that this is or isn't meant to be used in production? i couldn't quite tell now haha

Yes you can use it in production

love it, thanks!

Hi Roberto, we are also (partly) using docker-compose solution in production. However, do consider changing to CloudFormation when the infrastructure is fully built, as this gives you more flexibility in terms of configuration! :)

Hey @johann - sorry to piggy back on this thread but I am trying to deploy dagster on AWS and looking at the example I am sort of confused but my understanding of devops is basic at best. Should all this code live in the same repo as the user code? Our setup is; develop in a devcontainer locally, push changes to GitHub where we have an actions workflow that builds our container (user code) and stores in GHCR Would the ECS example code be in a separate repo or the same as the user code? I'm not sure how to adapt the example basically.

fwiw my team has two separate git repos (we are self-hosting dagster) - one git repo for dagster services (daemon and dagit) that has IaS (terraform), docker compose, dagster config, etc. Then we have another git repo for our workspace/pipeline service code (actual jobs/graphs/etc, also terraform)

Thanks Mike - so your business logic repo, that builds a container and tags it something like <biz logic name>:latest and that's referenced in your services repo at this point?

@martin o leary yes, well, sort of; we aren't including dagit... let me share a gist of the rough Dockerfile

Thanks for putting that together. i'm assuming that your user code (all your jobs / assets) is under the

pipeline

dir in your example?

Ah, yeah, at least this Dockerfile would be fine for k8s or ECS