Introduction

This Liquibase error means Spring Boot or Liquibase was told to load a changelog from the classpath, but the file is not actually present at that location in the built application. The fix is usually straightforward: put the changelog under the resources directory, point spring.liquibase.change-log at the real packaged path, and verify the file makes it into the final JAR.

Understand the Expected Default

In Spring Boot, Liquibase looks for a default master changelog under db/changelog/db.changelog-master.yaml unless you override it. If your project uses a different path or file type, configure it explicitly instead of relying on a guessed location.

A standard application.yml entry looks like this:

spring:
  liquibase:
    change-log: classpath:/db/changelog/db.changelog-master.yaml

The classpath: prefix means the file must exist inside the packaged application resources, not just somewhere in the source tree.

Put the File in the Right Source Directory

For a normal Maven or Gradle Java project, Liquibase changelogs belong under src/main/resources. Example structure:

1src/main/resources/
2  db/
3    changelog/
4      db.changelog-master.yaml
5      V001__create_users.sql

If the file sits under src/main/java, src/test/resources, or some custom folder that is not copied into the runtime classpath, Liquibase will fail at startup even though the file exists in your repository.

Verify the Path Matches Exactly

Small path differences cause this exception all the time. Common problems include:

• 'changelog versus changeLog'
• '.yaml versus .yml'
• missing leading slash after classpath:
• referring to a folder name such as liquibase that does not contain the expected master file

A safe configuration is:

spring.liquibase.change-log=classpath:/db/changelog/db.changelog-master.yaml

If you use XML or SQL instead, point to the real filename rather than the directory.

Confirm the File Is Packaged into the Build Output

The source path can be correct while the build output is still wrong because of resource filtering or custom packaging rules. Check the compiled artifact directly.

For a Maven project:

mvn clean package
jar tf target/app.jar | grep db/changelog

For a Gradle project:

./gradlew bootJar
jar tf build/libs/app.jar | grep db/changelog

If the changelog is not inside the JAR, the problem is not Liquibase itself. It is your build resource configuration.

Example Spring Boot Setup

A minimal working configuration keeps the changelog location explicit and easy to trace.

1spring:
2  datasource:
3    url: jdbc:postgresql://localhost:5432/appdb
4    username: app
5    password: app
6  liquibase:
7    enabled: true
8    change-log: classpath:/db/changelog/db.changelog-master.yaml

And a minimal changelog file:

1databaseChangeLog:
2  - changeSet:
3      id: 1
4      author: app
5      changes:
6        - createTable:
7            tableName: users
8            columns:
9              - column:
10                  name: id
11                  type: bigint
12                  constraints:
13                    primaryKey: true

If this structure works but your real project does not, compare the two setups and find the packaging or path difference.

Watch for Multi-Module and Test-Only Confusion

In multi-module projects, the changelog may live in one module while the Spring Boot app starts from another. In that case, the runtime module must depend on the resource-containing module so the changelog lands on the final classpath.

Another common issue is having the file only in src/test/resources. That works during some test runs and then fails in production packaging.

Common Pitfalls

One mistake is pointing spring.liquibase.change-log to a directory instead of a file. Liquibase needs the master changelog file, not just the folder name.

Another mistake is fixing the path in source code but never checking the built JAR. If the resource is filtered out during packaging, the startup exception remains.

Developers also sometimes mix absolute file paths and classpath locations across environments. Pick one strategy and keep it consistent.

Finally, do not assume the default Boot changelog location matches your project layout. If you moved the file, set the property explicitly.

Summary

• Liquibase must load a real changelog file from the runtime classpath.
• Put changelogs under src/main/resources unless you have a custom packaging strategy.
• Set spring.liquibase.change-log to the exact packaged file path.
• Inspect the built JAR when the file seems to exist but startup still fails.
• Multi-module packaging and path typos are the most common causes of this exception.