a year ago
I've got a setup of a Django Web Server and a Background Server (for handling queues). Both are looking at the same source code.
When I deploy the Django Web Server it runs: python [manage.py](manage.py) migrate && python [manage.py](manage.py) collectstatic --noinput && gunicorn backend.wsgi --timeout 600 as the Custom Start Command and expectedly runs the migrations.
However, my Background Server has the Custom Start Command: python [manage.py](manage.py) qcluster only (to start the cluster), however for some reason it still runs the migrations on the database.
Obviously if you have the same migration running on the database it's going to error because it already exists so this means quite often one of the builds will fail (because the both auto-deploy from main) due to a migration error. So my question is: "how do I switch off running Django migrations on the Background server or is there something in Railway automatically doing this?"
Project ID: 98a9a750-1944-4447-b83c-8cd90f904626
1 Replies
a year ago
Hey charlieday!
I have a similar setup with Django + Celery + PostgreSQL + Redis configured with Dockerfiles.
At the moment we are running the migrations in an entrypoint shell script and is working fine so far.
I used this template as an example:
https://github.com/Antvirf/railwaydjangostack/tree/main/deployment
I hope this helps.
Kind regards,
Leo
a year ago
something a little more complex than just custom start commands is good too but may be a bit overkill for you, if your worker service is trying to run migrations during build it makes me think you have a release command set somewhere, do you have a Procfile?
I do have a Procfile but assumed the custom start commands would be run instead of that? That does have python [manage.py](manage.py) migrate in it though
a year ago
its best to only set your start command in one location