Migrations path option in ecto

In the mix ecto.migrate docs there is a command line option --migrations-path. I tried it like this in my project

              mix ecto.migrate --migrations-path  "priv/repo/migrations". But it returns error

                 ** (Mix) Could not invoke task "ecto.migrate": 1 error found!
                     --migrations-path : Unknown option    

Am I doing something wrong?


What is your version of ecto_sql according to your mix.lock?

First mention of that option is in the docs of 3.1.3.

ecto_sql: 3.1.1

Then you probably need to unlock and update your version of ecto_sql


Thanks for pointing this out . It works . Now I am trying to run migrations from another umbrella app . like this:

                     mix ecto.migrate --migrations-path  "relative_path_to_the umbrella_app_migration_folder"

But it gives me this error:

    ** (Mix) Could not find migrations directory "apps/umbrella_app/priv/repo/migrations"
     for repo App.Repo.

    This may be because you are in a new project and the
    migration directory has not been created yet. Creating an
    empty directory at the path above will fix this error.

    If you expected existing migrations to be found, please
    make sure your repository has been properly configured
    and the configured path exists.

I am following this thread:

I have single repo and migrations in two different umbrella apps.



Relative to where? And where in the filesystem do you run that command? Please use proper pathes here, not any obfuscations. Perhaps replace appnames with stubs, but make sure the regular umbrella structure is preserved when doing so, that we can understand what you are actually doing.

I run this command inside the umbrella app which contains the Repo. This is the relative path:

        mix ecto.migrate --migrations-path  "apps/al/priv/repo/migrations"

All the umbrella apps are inside the app directory. If i Provide the absolute path volumes/projects/apps/al/priv/repo/migrations it says already up. But no migrations will run.

I don’t have any config settings in the al app.

It seems to be working after dropping the database and creating again and then running the mix migrate command for the second app which doesn’t have a repo.

But it won’t work if i run the main app migrations first and then run the migrations from the other app(which don’t have repo). It returns already_up.

So you are running from inside an app, but specifiying the path relative to the umbrella project? That shouldn’t work…

Either specify a path relative to your current working dir or an absolute one.

Yes its working for absolute path but only if run the migrations from the second app first(which doesn’t have repo). But it gives me Already up console message if I run this after the main app migrations(which is what I need).

How are the migrations of both apps named? And can you successfully migrate the main app after the second app?

I guess the migrations table holds the name of the migration (either module or filename, I don’t know right now) and if the migrations in both apps are named the same way it thinks they are already migrated.

I haven’t worked with Elixir and a database in a long time, so this is just a wild guess.

Yes I migrate successfully the main app after the second app migrated but not vice versa.

You need to specify a second migrations table for your second app


That table is per repository as I understand it, but OP wants a single repo and migrations in different apps of the same umbrella…

Personally I’m not convinced that this was a good design choice, the application that contains the repository should be the only one tampering with the database. Everything else will get you into trouble…


Perhaps, but imagine a plugin system, each plugin wants to run its own migrations to add its own tables to the database. Perhaps ecto needs a way to have ‘named’ version columns, I.E. have the schema_migrations table have another field that defaults to the application name or so, that way each different ‘priv’ directory has it’s own migrations and can be done and undone individually.

1 Like

An external system can surely manage its own tables, but imho it should do so through migration files, which are added to the migrations path of the application it’s used in (e.g. oban does implement that quite nicely). Or if it’s part of a bigger system, where installing plugins is part of the core functionality have a truely custom handling of db migrations, but I don’t see that as feature ecto should support.


Inside the aliases in mix file. If we define migration command like this:

defp aliases do
 "ecto.migrate": [
      "ecto.migrate  data/priv/repo/migrations",
      "ecto.migrate --migrations-path apps/al/priv/repo/migrations"


If we run mix ecto.migrate. only first command executed and second ignored.
Is this the expected behaviour?
Is there any way to override it so both commands will execute?

In case anyone else comes across this post in search of an answer: there is a way to override it.

Mix — Mix v1.12.3 and text search for “Tasks can be executed again”