Skip to content
Latchkey

Elixir "mix.lock is out of date" (--check-locked) in CI

With --check-locked, mix deps.get refuses to modify mix.lock; if resolving would change any locked entry, it fails instead. This surfaces a lockfile that drifted from mix.exs and was never committed.

What this error means

CI fails with "** (Mix) Your lockfile mix.lock is out of date and must be updated" (or "the lockfile would change") when deps.get runs with --check-locked.

** (Mix)
** (Mix) Your lockfile mix.lock is out of date and must be updated without the
--check-locked flag

Common causes

mix.exs changed but mix.lock was not committed

A dependency was added or bumped locally; the resulting mix.lock change never made it into the commit, so CI would have to modify it.

Different Hex resolution than the committed lock

A dep range allows a newer release than what is locked, so a fresh resolve would move the lock, which --check-locked forbids.

How to fix it

Regenerate and commit mix.lock

  1. Run mix deps.get locally without --check-locked.
  2. Commit the updated mix.lock with the mix.exs change.
  3. Push so CI can install the frozen, committed lock.
Terminal
mix deps.get
git add mix.lock
git commit -m "Update mix.lock"

Keep the frozen gate in CI

Enforce a committed lock so builds are reproducible; --check-locked fails fast when someone forgets to commit it.

.github/workflows/ci.yml
- run: mix deps.get --check-locked

How to prevent it

  • Commit mix.lock with every dependency change.
  • Run mix deps.get --check-locked in CI to catch drift.
  • Review mix.lock diffs so unexpected version moves are visible.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →