articles/2025/coolify-django/

[giscus[bot]]

articles/2025/coolify-django/

How I moved my Django projects from a manual server setup to Coolify for easier, zero-downtime deployments.

https://www.loopwerk.io/articles/2025/coolify-django/?utm_source=www.pythonweekly.com&utm_medium=newsletter&utm_campaign=python-weekly-issue-706-july-10-2025&_bhlid=e2b70a6451226940f740f1f97c199f5bdad237cd

[jfmatth]

checkout piku for django :)

https://github.com/piku/sample-django-app

[mjmare]

Thx for the article.
Q: since you migrate the DB at build time, there will be a container running with the old code and therefore old DB schema. Won't the migration interfere with the old version?

[kevinrenskers]

Yes, you are absolutely right. But isn't it the same problem when you run the migration at runtime rather than build time? The old container is still running until the Coolify healthcheck gives the green light for the new container. In the end I think it probably takes the same amount of time that the old container uses the new database schema?

I might be completely wrong of course.

[kevinrenskers]

I guess the best way would be to duplicate the database, do the migrations there, and then move the database over (by changing the env variable). But we have so few backwards incompatible migrations that it doesn't seem worth the effort. At least for now.

[mjmare]

Sure, but I always wonder how people handle this.I can for my apps afford to turn off the old version before the new one gets deployed. I run the migration at startup. Still, I'm curious to learn a way to handle it more graciously.

[mjmare]

That would do it, but seems like a lot of work 😉