We are just about to move from a monolithic architecture to an auto-scaled group and I'm not sure how I should be running my database migrations (Laravel).

I am thinking that a script will run when a new box comes online, this will git pull my latest code down. Should this script also execute my database migration? I am not sure how I can get it run on only one box?

  • I'm assuming by moving from monolithic to auto-scaled, you are referring to your database specifically. Are you using AWS RDS? If not, have you looked into it? aws.amazon.com/blogs/database/…
    – Preston Martin
    Sep 26, 2017 at 15:52
  • 1
    Yes, we are using RDS. No I am scaling and load balancing the EC2 instances where the application runs.
    – Mick
    Sep 26, 2017 at 15:58
  • 1
    One solution is to use something like flyway or liquibase that can run idempotent updates on DB, this way each node starting can try to update the DB and do nothing if the migration already happened.
    – Tensibai
    Sep 27, 2017 at 8:00
  • Fair warning, Flyway marks migrations as complete only after they've been run. if you fire up Flyway concurrently from several nodes, there's a good chance they'll try to do the same migration at once, which can cause problems.
    – maplebird
    Sep 27, 2017 at 18:37

2 Answers 2


How are you doing your deploys? Nuke + rebuild the ASG (whether one node at a time, or by replacing the whole group at once), or do you have a script that redeploys all of your active nodes?

And also, how are you triggering your deploys?

Ideally you want to be running/triggering deploys from some form of CI server like Bamboo or Jenkins. If you're doing this, you can run your DB migrations from the build server (or its component build agent instances).

This would allow you greater control over your environment, as you could, for example, restore DB from snapshot if the deployment fails.

  • At the moment we just SSH onto the production box and pull the code. In reality I think that most of the time we will only have one node. I was thinking we would use Code Deploy. We don't yet have much experience of AWS/Devops and are just trying to find a simple way to get started with a load balance and ASG.
    – Mick
    Sep 27, 2017 at 7:49
  • AWS CodeDeploy is great, and scales long-term once you get larger and start using more servers. If for the moment, you're manually SSHing to deploy, you can always have a separate script that runs DB migrations. I.e. you would run the normal deployment script via CodeDeploy, and the database migration manually off one node. If you're not building a CI server that can run Liquibase any time soon, you can also look into other software like Datical: aws.amazon.com/blogs/devops/…
    – maplebird
    Sep 27, 2017 at 18:35

Many orm's store migration state in the DB itself, but if you do it 'manually' its not hard to build yourself either. Just have a "migrationstate" table where all executed migrations are stored. That way when a node comes online it can simply check that table against its local "migrations" folder, and execute what's missing - this should cause only your first node after a version bump to execute the migrations.

As a side note: CloudFoundry solves this by allowing each instance (node) in your scale set to access its identifier. The first one gets 0, the next 1 etc. That way a node knows if its the first one, and can execute migrations. I don't think ASGs have the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.