为何AWS Elastic Beanstalk部署Django时仅执行migrate不执行makemigrations？

Great question! Let’s break down the key reasons why AWS recommends only running django-admin migrate (or python manage.py migrate) during Elastic Beanstalk deployments, and skipping makemigrations:

• makemigrations is a local/development-only step
  This command generates migration files based on changes to your Django models on the machine where it’s executed. It’s meant to be part of your local development workflow, not production deployments. Migration files represent intentional, tested schema changes—they belong in your version control (like Git) alongside your code, so every deployment uses the exact same set of pre-approved migrations.

• Consistency is non-negotiable for production
  If you ran makemigrations during deployment, you risk generating different migration files across Elastic Beanstalk instances or deployments. Even tiny environment differences (like package versions or file system state) could lead to inconsistent migration logic, breaking your database’s schema integrity. By committing pre-generated migrations to version control, you guarantee every deployment applies the same, vetted changes.

• Production environments restrict file writes
  Elastic Beanstalk’s application servers typically run with limited permissions—they can’t write new files to your app’s code directory (where migration files would be saved). Any migrations generated during deployment would be temporary and lost when instances restart or scale. This could lead to partial migrations or missing files that break future deployments entirely.

• Avoid accidental, untested schema changes
  Auto-running makemigrations in production might create migrations for trivial model tweaks (like updating a field’s verbose_name or adjusting field order) that you didn’t intend to apply to your live database. Worse, it could generate migrations that break existing data if you haven’t tested them locally. Handling makemigrations in development lets you review, test, and validate every schema change before it touches production.

The Correct Workflow #

1. Update your Django models locally
2. Run python manage.py makemigrations to generate migration files
3. Test the migrations locally with python manage.py migrate to ensure they work as expected
4. Commit the migration files to your version control system
5. Deploy to Elastic Beanstalk, where db-migrate.config runs migrate to apply the pre-tested migrations

内容的提问来源于stack exchange，提问作者user11141180