What's new

Liquibase Secure is the standard for Database Change Governance. For years, every Liquibase run ended in a terminal, with evidence scattered across pipeline logs, tickets, and screenshots. Liquibase Secure 6.0 extends that standard from the pipeline to the entire organization.

The Liquibase Secure CLI you already run on every workstation and CI/CD agent is now joined by Liquibase Secure Server, a self-hosted web application deployed inside your own network. Together, they turn every update, rollback, policy check, and drift scan into a shared, governed record that your entire organization can see, filter, and act on.

This is a major release, but it is a continuation, not a restart. Everything the command line did in Liquibase Secure 5.x it still does in 6.0, and existing changelogs, flow files, checks settings, and pipelines keep working. What 6.0 adds is a platform around that engine: Change Intelligence for visibility, Change Governance for centrally managed policy, a substantially upgraded Change Automation engine with cloud-native database connectivity, Developer Productivity tooling that brings Liquibase into the IDE and into AI coding assistants, and a role-based access control model built for regulated environments.

Liquibase Secure 6.0.0 is available now. Download Liquibase Secure 6.0.0 and see the Liquibase Secure product page Liquibase Secure for an overview of the platform.

Note: Liquibase Secure is a distinct commercial product with its own distribution and license, not Liquibase Community with a key applied. Standardize on one distribution per environment.

What's new at a glance

Liquibase Secure is now delivered as a platform of complementary components. Two run-time pieces, the Liquibase Secure CLI and Liquibase Secure Server, host the capabilities below. Each component is described in its own section of these release notes and in a dedicated Technical Overview.

Continuity from Liquibase Secure 5.x

Liquibase Secure 6.0 builds directly on the 5.x generation. The command-line tool your pipelines already run is unchanged in form and is now called Change Automation (in 5.x it was named Secure Automation, and 5.x license keys and support artifacts refer to it as general Liquibase Secure). It runs inside the Liquibase Secure CLI with a substantially expanded capability set in 6.0, described under Change Automation below. Liquibase Secure Server is additive: a CLI that is not connected to a server operates entirely from local configuration and writes its outputs locally, exactly as before. Connecting it adds visibility and centralized governance without changing how a deployment executes.

Most of 6.0 needs nothing from you when you upgrade. A small number of changes do require action and are listed in Action required when you upgrade. For step-by-step guidance, see Upgrading to Liquibase Secure 6.0.

The Liquibase Secure platform

Liquibase Secure is delivered as two components. Both run entirely inside your trust boundary, and neither depends on Liquibase-managed infrastructure.

Liquibase Secure CLI

The Liquibase Secure CLI installs on developer workstations and CI/CD agents and implements Change Automation: it reads changelogs, previews SQL, runs policy checks, applies and rolls back change, detects drift, and writes reports and structured logs. It makes outbound connections only and holds no credentials beyond the moment of execution.

New in 6.0, the CLI integrates with Liquibase Secure Server through paths that are always initiated by the CLI over HTTPS; the server never calls in. The Change Intelligence extension is bundled in the distribution and disabled by default; set LIQUIBASE_PLATFORM_ENABLED=true and the connection settings, and the commands that change or inspect a database (the update and rollback command families, excluding their -sql preview variants, plus checks run, diff, and diff-changelog) report their operation metadata to the server. The checks commands can resolve their configuration from a Change Governance Assignment instead of a local Checks Settings File. Reporting is non-blocking: if the server is unreachable, your Liquibase command still completes successfully; the trade-off is that the operation is not recorded in the dashboard.

Liquibase Secure Server

Liquibase Secure Server is the self-hosted, containerized service you deploy inside your own network to get the Liquibase Secure 6.0 web interface. It receives operation data from every machine that runs Liquibase, stores it, and serves the dashboards and governance interfaces your team uses. It never connects to a managed database and holds no database credentials; everything it knows arrives from your own CLI instances or from authenticated users in the browser.

The server hosts three functional areas behind one API and one web application: Core services (accounts, workspaces, projects, connections, changelogs, pipelines, license management, RBAC, SSO, API tokens, and the audit log), present in every installation; Change Intelligence, the licensed visibility module; and Change Governance, the licensed policy module. The modules share the API and web tiers, the data stores, authentication, and the access control model, so administering access to either uses the same groups, templates, and audit log as everything else.

Your operation data stays inside your network and is never sent to a dashboard hosted by Liquibase. The server keeps operations, changelogs, connections, users, and workspaces in one PostgreSQL database, and isolates your encrypted database connection credentials and SSO secrets in a second one, so a compromise of the first does not expose them. Deploy it on-premises, on a private cloud VM in a private subnet, or on a VPN-protected host; Liquibase Secure Server is distributed as container images. The supported deployment is Docker Compose, installed and managed by the included liquibase-platform CLI. The images are standard OCI images and the application is stateless, so customers running Kubernetes or ECS can deploy them using their own manifests; Liquibase does not currently publish a Helm chart or task definitions for those platforms. The only optional egress is to the LLM provider you choose to connect for AI Analysis (bring your own model), and it is removed entirely by hosting the model in your environment.

Your team needs only a browser and a URL; nothing is installed on their machines. The server ships with a CLI that drives its lifecycle, covering install, update, start, stop, status, logs, migrate, and uninstall. It is a convenience layer over the Docker Compose files in the bundle, and you run it as liquibase-platform.

Important: Two things to get right when you set up or upgrade. Use the update command to move to a newer version, never install --force, which regenerates the deployment’s database passwords and encryption key and leaves the existing data unreadable. And configure SMTP during setup, because without it there is no password recovery for anyone who gets locked out.

Licensing: Change Intelligence and Change Governance are licensed modules activated by your Liquibase Secure license. If your installation is not licensed for a module, that module’s permissions are inactive and its capabilities are limited or unavailable, while Core services remain fully administrable. Contact your Liquibase account team for licensing details.

Change Intelligence

Change Intelligence is the visibility module of Liquibase Secure Server. It treats every Liquibase operation as first-class telemetry: each deployment, rollback, policy check, and drift detection run produces a structured operation record that flows into a governed observability layer, so teams can identify risk earlier, triage failures faster, and capture audit evidence automatically, without slowing delivery. For architecture, security posture, data flow, and sizing guidance, see the Change Intelligence Technical Overview.

One view across the database estate

The Dashboard is the front page of the web app and opens on three groups of measurements, each of which is also its own page under Monitor, alongside a full list of every operation. Database Changes covers the DORA metrics: Deployment Frequency, Change Failure Rate, Rollback Rate, and Cycle Time. Policy Checks covers Pass Rate, Database Violations, Changelog Violations, Critical and Blocker, and coverage across your databases and changelogs. Drift Detection covers Drift Rate, Drift Detected, Total Drift Items, Avg Drift Items, and Database Coverage. Each measurement runs over a 7, 30, or 90 day window and compares that window against the three before it, so you see the direction as well as the number.

You organize the estate by registering your projects, changelogs, and database connections, and by grouping connections into pipelines that describe the path a change takes to production. Every dashboard and list shares one filter bar covering time range, project, connection, changelog, outcome, and free text, and you can save the filters you use often or share one as a link. Existing projects are migrated to a default pipeline automatically when you upgrade, keeping their deployment status and history.

From signal to root cause, fast

Open any operation and you get its status, duration, target database, the command that ran, and its captured logs. Instead of a literal command line, you see the configuration that was actually in effect, with each value labeled by where it came from: a flag, an environment variable, or a properties file. That matters because a command line never shows what was merged in at runtime. Values that look like passwords, secrets, tokens, keys, or credentials are stripped on the machine that ran the command, before anything is sent, and a second independent pass on the server redacts anything that slipped through. There is no way to reveal them from the interface.

Results are broken down for the question you are actually asking. Policy check results group by severity, by check, by changeset, and by database, and the by-check view lists every check that ran, including the ones that found nothing. Policy check operations arrive through the same path as deployments, so policy outcomes appear alongside deployment and drift evidence without requiring a Change Governance license.

Optional, on-demand AI Analysis with your own model

AI Analysis is optional and is off by default. Nothing else in Change Intelligence depends on it: dashboards, operation details, policy results, and drift findings work exactly the same whether or not it is ever turned on, and no operation data is sent to any AI provider unless an operator configures a provider and an administrator enables the feature for a workspace. Organizations that cannot use AI can simply leave it off.

For teams that choose to use it, AI Analysis follows a bring-your-own-model (BYOM) approach. Liquibase does not host, bundle, or route traffic through a model of its own; you connect the LLM provider of your choice, whether OpenAI, Anthropic, Google, or any OpenAI-compatible endpoint, which includes self-hosted and local models, so inference can stay entirely inside your network and under the AI governance, data-handling, and procurement terms you already have in place. With a model connected, Liquibase can summarize an operation and analyze it when there are warnings or errors to explain. When a user explicitly invokes Summarize or Analyze Failure on a specific operation, the server calls the provider you configured and nothing else. The provider, model, and endpoint are set once per installation, so a single operator-controlled decision governs where inference happens; AI Analysis is then enabled per workspace, and there is never automatic outbound LLM traffic. The result is saved with the operation, attributed to the model and the time it ran, so it becomes something the team can read later rather than a one-off answer.

Catch drift early

Drift detection runs at the cadence you configure, typically as a scheduled CI/CD job, and the results populate a trend view alongside individual drift findings. Drift shows added, removed, and modified objects with their full definitions in a familiar side-by-side diff, together with the execution log that produced the finding, and tells you how long ago each item was first detected, so you can tell a new problem from an old one. Drift also carries its own indicator separate from whether the operation succeeded, because a run can finish cleanly and still have found drift.

Audit ready by design

Change Intelligence captures an immutable record of operations alongside the Core audit log of permission and configuration changes. Operations are immutable once ingested, AI analyses are persisted with the operation they describe, and security reviewers can answer questions like "who had access to this project on this date" from inside the product without needing elevated permissions on other systems. See Security: SSO and RBAC for the permission model.

Change Governance

Change Governance is the centralized policy management module of Liquibase Secure Server. It replaces local and remote file wrangling with a graphical, searchable, shareable library of policy assets (catalogs, packages, and checks) and maps that library to the entities teams already operate (projects, pipelines, database connections, and changelogs) through named Assignments. Policies are written once and reused across releases, applications, and lines of business; successful compliance workflows are copied, tuned, and shared instead of rebuilt. For architecture, permissions, and data flow, see the Change Governance Technical Overview.

Policies: catalogs, packages, and checks

In the web interface you can browse the checks that ship with Liquibase, import a checks settings file you already have or a checks package zip exported with checks export, organize checks into packages and catalogs, rename them, and change a check’s parameters, all without editing a file. Saving a configuration offers Save to overwrite or Save As to create a renamed copy in any catalog and package you have access to; copying a shipped check and customizing the copy keeps the original intact, and later changes to a copy never affect the source.

Every workspace starts with the Liquibase Default Catalog, a read-only copy of the 59 checks built into Liquibase Secure 6.0, grouped into seven packages named after the check categories introduced in 5.2, and you can check it for updates as Liquibase adds to it. Starting with 6.0 every check lives in a package (legacy uncategorized checks land in an "Uncategorized Checks" package). Checks can be enabled or disabled individually or in bulk across a package, and every check and package carries version history that records who changed what, with rollback to a prior check’s version just a click away.

Assignments: policy without pipeline changes

Assignments connect your policy configuration to a run. You pick the checks or packages you want and the assets you want them to run against, choosing from your workspace, projects, pipelines, database connections, and changelogs, and Liquibase gives the Assignment an immutable ID. Passing --assignment-id=<UUID> to liquibase checks run (or checks show) collects that Assignment’s checks from the server and runs them on the executing host, so a pipeline no longer needs a checks settings file on disk, and pipeline managers do not need to track local and remote files to set up pipeline jobs. Comma-separate the IDs to run up to 50 Assignments together, de-duplicated, so a check referenced more than once is only run once.

Because the Assignment ID never changes, policy authors can add, remove, or tune checks and re-target the Assignment without any change to pipeline configuration: changing the Assignment changes the next run. A single pipeline or connection can carry several Assignments, so a DBA group, a platform team, and a security review group can each enforce their own concerns on the same target and run them independently; a long compliance sweep does not block a short coding-standards check.

Adopt incrementally

Adoption does not have to be all or nothing. The checks settings file continues to work exactly as before. When you pass both, --assignment-id wins and Liquibase logs the local file it skipped. Checks still execute where they always have: in the Liquibase Secure CLI on the host that already has access to the target. Change Governance stores and resolves the configuration a run consumes and, when reporting is enabled, receives the outcome for Change Intelligence.

Built for shared ownership

Governance is something a team shares, so the interface is built around who may change what. Permissions decide who can see, use, and edit a catalog, a package, or an Assignment. Assets you can view but not assign appear without a checkbox, so you never capture them by selecting a parent, and you can request access to the ones you cannot reach. Saving is never silent: the save dialog itemizes what the change affects before it is applied, the save applies atomically, every change is recorded in the audit log with who changed what, and the owners of affected assets are notified. Removing a package from an Assignment, or an Assignment entirely, requires a confirmation step.

Note: The governance interface needs Liquibase Secure Server. Policy checks themselves still run from the command line without it.

Change Automation

Change Automation is the command-line engine at the center of Liquibase Secure and the component that applies database change. It installs on the workstations and CI/CD agents that already perform deployments, connects to more than 65 database platforms, and converts a proposed schema change into a governed operation: previewed as exact SQL before it runs, checked against policy, applied under a lock, recorded in a tamper-evident ledger on the database itself, reversible one changeset at a time, and evidenced in a report a reviewer can read. Change Automation was named Secure Automation in Liquibase Secure 5.x; it is the same command-line tool your pipelines already run, and 6.0 substantially expands what it can do, with cloud-native database connectivity, new changeset targeting attributes, stricter validation, faster inspection of large schemas, and cleaner, automation-friendly output, all described below. For the full capability model, runtime posture, and integration architecture, see the Change Automation Technical Overview.

The changelog remains the central artifact. Whether it is authored in an IDE, produced by an external tool, captured from an existing database, or generated by an AI assistant through Liquibase’s own APIs, Change Automation treats it identically: committed to version control, checked against policy, previewed as SQL, deployed, tracked, and reported on. Policy checks are deterministic and do not distinguish a human-authored changeset from a generated one, which is what makes the governance path for AI-written change the same path as for any other change.

What is new in Change Automation 6.0, as a delta from Liquibase Secure 5.2.x:

Database Connectors: cloud authentication and secrets management

IAM authentication for Amazon RDS and Aurora

Liquibase Secure now connects to Amazon RDS and Aurora for PostgreSQL and MySQL using AWS IAM authentication with short-lived tokens instead of static database passwords. Teams authenticate with their AWS identity and can assume a role to reach databases in other AWS accounts. This removes long-lived passwords from pipelines and properties files, aligns database access with existing AWS identity policy, and shrinks the blast radius of a leaked credential to minutes.

IAM authentication and Secret Manager for Google Cloud

Liquibase Secure adds IAM authentication for Cloud SQL for PostgreSQL and MySQL, either through the Cloud SQL Java Connector or a lighter token-as-password option, and can pull values such as password, url, and username straight from Google Secret Manager. Teams on Google Cloud get the same passwordless, vault-backed connection pattern already available on AWS, so credentials never have to be written to disk or into a CI variable.

Azure Key Vault secrets

Liquibase Secure can now retrieve secrets, keys, and certificates from Azure Key Vault, joining the existing AWS Secrets Manager and SSM Parameter Store integrations. A property holds a reference to a vault entry rather than a credential, so Azure-centric organizations can enforce their vault policy on Liquibase the same way they do for every other workload.

Mixed authentication for target and reference databases

You can now use different authentication mechanisms for your target and reference databases when you run diff or diff-changelog on Snowflake, Databricks, MongoDB, and AWS RDS. Comparing a production database that uses cloud IAM against a reference that uses a password, or vice versa, no longer requires workarounds, which makes drift detection and changelog generation practical across heterogeneous environments.

Changeset targeting and filtering

New changeset attributes: teams, releases, keywords, and conditions

Four new changeset attributes, teams, releases, keywords, and conditions, let you tag changesets with the organizational metadata you actually plan by, and the matching --teams-filter, --releases-filter, --keywords-filter, and --conditions-filter flags select on them at run time. Add the @ operator to any of these filters for strict matching, so a filter selects only changesets with the exact value. Teams can deploy one release’s changes, one team’s changes, or one flagged subset from a shared changelog without maintaining parallel context and label schemes, and validate --strict checks the new attributes for typos before anything runs. These new attributes are also included in status --verbose output.

Checks Targeting

Checks Targeting lets you set persistent exemption or restriction rules so a check can skip or exclusively inspect specific changesets without disabling the check or editing the changelog. Use the new changeset attributes (teams, release, conditions, keywords) or the classic attributes of labels and contexts to filter the specific changesets to target with specific checks. In this way, an approved exception to a naming standard, or a check that should only look at one team’s changesets, becomes a rule that travels with the checks configuration. This keeps policy enforcement on for everyone else while eliminating the noise and the audit questions that come from suppressing a check globally.

Policy checks

Run checks from a Change Governance Assignment

checks run and checks show commands optionally accept --assignment-id to resolve their configuration from Liquibase Secure Server instead of a local checks settings file (see Change Governance). Pipelines reference an immutable ID, policy authors change the checks behind it, and the next run picks up the change with no pipeline edit. Local checks settings files continue to work unchanged and are not deprecated.

Stricter validation and partial customization

validate --strict now validates the new teams, releases, keywords, and conditions attributes and catches bad property names in include and includeAll blocks, and checks customize accepts partial updates so you can change one property without rebuilding the whole check. Configuration mistakes surface before deployment rather than as silently ignored settings, and check tuning becomes a one-line change.

Shared modules for custom Python checks

Custom Python policy checks can now import shared modules from other directories. Teams maintaining a library of organization-specific checks can factor common parsing and helper logic into one place instead of duplicating it in every check script, which makes large custom check suites easier to test and maintain.

More accurate results and attribution, better performance

Keyword-based checks such as SqlGrantWarn no longer misfire on data values that happen to look like reserved words, and the checks report now attributes violations correctly when you use checks packages with multiple configuration files, so nothing is counted twice or listed under the wrong file. Policy checks based on SQL patterns also run dramatically faster against changelogs with large multi-value INSERT statements, cutting runs that used to take minutes down to seconds.

Changelog generation

One file per table with object changelogs

generate-changelog and diff-changelog can now organize output as one file per table with --object-changelogs=by-table, so a table and everything tied to it lands in a single file. generate-changelog also infers the SQL dialect from the database you connect to when your filename leaves out a database-type segment. Teams bringing an existing estate under governance get a changelog layout that mirrors how they think about the schema and reviews cleanly in pull requests.

Generated changelogs that match the schema

Generated changelogs are more faithful to the schema they came from. Index prefix lengths survive on MySQL and MariaDB, TINYINT(1) and TIME(N) columns keep their types, a standalone index is no longer dropped when it shares columns with a unique constraint on PostgreSQL and MySQL, and a schema-filtered run on Microsoft SQL Server no longer pulls in database-level DDL triggers from outside the schemas you asked for. On PostgreSQL, diff-changelog now orders a view update ahead of a dropColumn the view still uses, so the changelog deploys without you reordering changesets by hand. Less manual clean-up after generation means faster onboarding of existing databases and fewer surprises when the generated changelog is first deployed.

Database support

PostgreSQL

Liquibase Secure supports PostgreSQL 18 VIRTUAL generated columns end to end. Together with the diff-changelog ordering fix and index handling described above, PostgreSQL teams can adopt the newest engine features without stepping outside the governed path.

MongoDB

set-labels and set-contexts now work on formatted Mongo changelogs, so the same environment-scoping workflow used on relational changelogs applies to MongoDB.

Amazon DynamoDB

Liquibase Secure validates createDynamoTable attribute definitions and tags up front, and lets you run consecutive changesets that create or delete a global secondary index on the same DynamoDB table. Errors surface at validation rather than mid-deployment, and index management no longer requires splitting work across runs.

Couchbase

On Couchbase, the commands that do not apply now tell you so instead of failing with an internal error, so unsupported operations are clear rather than confusing.

MySQL, MariaDB, and SQL Server

Snapshot and generation fidelity improvements for MySQL and MariaDB (index prefix lengths, TINYINT(1), TIME(N)) and for Microsoft SQL Server (schema-filtered DDL triggers) are described under Changelog generation; performance improvements for these platforms are described under Performance.

Performance

Faster on large schemas

snapshot, diff, and generate-changelog are now much faster on large schemas across PostgreSQL, SQL Server, MySQL, MariaDB, Db2, Databricks, and BigQuery. Snapshots of MySQL and MariaDB databases with many stored procedures and functions are roughly 25 to 30 percent faster, because Liquibase fetches those definitions in parallel instead of one at a time. Scheduled drift detection and changelog generation against production-sized schemas finish in a fraction of the time, which makes frequent drift scans practical and shortens pipeline stages.

CLI output and logging

Machine-readable STDOUT, human-readable STDERR

Liquibase now writes only machine-readable results, such as SQL, JSON, and diff output, to STDOUT. Everything else, including the banner, progress messages, and warnings, goes to STDERR. Scripts that capture update-sql output or parse JSON no longer need to strip banners and progress lines, and piping Liquibase into other tools works the way Unix conventions expect. Scripts that read STDOUT from commands like update, rollback, and dbDoc should be reviewed; set --legacy-stream-routing if you need time to migrate.

Control verbosity, see what changed

The new --verbosity flag, with quiet, normal, or verbose options, controls how much detail Liquibase prints, and a new --show-rows-affected flag reports the rows each statement affected when you turn it on. Benign command failures no longer print a full stack trace unless you run with --log-level=FINE. Console output is shorter and more useful in a CI log, while the detail is still one flag away when you need it.

Logging that stays out of your application’s way

If you embed Liquibase Secure, for example in Spring Boot, running a command no longer changes your application’s logging levels or handlers, because logging now runs through SLF4J. Your logs are a separate stream from console output: setting --log-level or a log file governs your logs independently of console verbosity, so a quiet run still records everything you asked it to.Structured JSON logging keeps working on the new backend, writing one JSON object per line so each record parses on its own. And, if a message has an error code, it gets a new liquibaseErrorCode key in the JSON object. Log aggregation and alerting can key on a stable classification rather than on message text.

Credentials and SQL handled as written

A failed connection no longer echoes your password when your JDBC URL carries credentials in the authority form, and the Maven plugin no longer prints database credentials in verbose output. Liquibase also no longer strips comments from your SQL by default, so comments you write in a stored procedure body reach the database as written. These changes close two common paths for credential leakage into CI logs and keep deployed code faithful to what was reviewed.

Error codes and exit codes

When a deployment fails, the first question is usually "what happened, and is it something I can fix?" Liquibase 6.0 answers that question from the start by improving the error and exit codes surfaced by the product. These improvements help you spend less time digging through logs, get to fixes faster, and let your CI/CD and other automation pipelines respond to failures intelligently.

First, exit codes have been reviewed and adjusted to ensure they have consistent meaning across the product. Exit code 0 still means success, and a failure’s exit code now reflects how that failure is classified rather than always being 1, so your pipeline automation can more readily determine whether an error occurred because of the changes you are deploying or because of something in the environment. Scripts that check for a literal exit code of 1 should be updated.

Second, new error codes have been added throughout the product to provide a stable reference point for errors. You can search for error information in the docs, use the codes in your alerting, or, if needed, share them with support. Structured JSON logs carry the code in the new liquibaseErrorCode field.

Developer Productivity

Liquibase closes the gap between where database changes are authored and where they are governed. Liquibase Secure Developer for VS Code brings changelog authoring, local operations, and policy enforcement into the editor developers already use. The Liquibase AI Changelog Generator lets AI assistants and coding agents produce changesets that are generated by Liquibase’s own APIs rather than written from a model’s memory. Both components run entirely on the developer workstation or CI agent; neither introduces a hosted service, an inbound network path, or a Liquibase-managed runtime dependency. For architecture, security posture, and analytics details, see the Developer Productivity Technical Overview.

Liquibase Secure Developer for VS Code

The Liquibase VS Code extension (version 1.2.1) creates changelogs in all four supported formats, Formatted SQL, XML, JSON, and YAML, along with changesets, defaults files, flow files, and policy checks configuration files, with format-aware snippets and the current dbchangelog XSD bundled so validation and completion work without additional setup. It exposes the operational command families from the command palette or a context menu on any recognized Liquibase file: status and validation, update, rollback, policy checks, history, and flow execution, each with an in-editor help command that links to the relevant documentation.

Every update and rollback command is registered once and produces two adjacent menu entries, the executing command and its -sql preview counterpart, so reviewing generated SQL before applying it is the neighbouring menu item rather than a separate CLI invocation to recall. A React-based configuration editor replaces hand-edited properties files and manages JDBC driver dependencies per database type. The extension requires only LIQUIBASE_HOME, JAVA_HOME, and LIQUIBASE_LICENSE_KEY, auto-detects all three, and opens an installation wizard rather than an error if detection fails. Policy checks run from the extension are the same checks from the same configuration file that the pipeline runs, so a change that passes locally passes in CI for the same reasons, and a change that fails locally is detected before moving in the pipeline to consume a build slot. Requirements: Liquibase Secure 5.0 or newer, JDK 17 or newer, and a Liquibase license key.

Liquibase AI Changelog Generator

The Liquibase AI Changelog Generator (version 1.0.0) is a Model Context Protocol (MCP) server that exposes thirty tools, covering table, column, index, view, procedure, function, trigger, sequence, and constraint operations, plus raw SQL, SQL file, and validation tools. The architectural point that matters for governance is that the language model does not write the changeset. The model interprets developer intent and calls a tool with structured parameters; the changeset itself is generated by Liquibase’s native Java change classes, then validated against an ephemeral in-memory H2 database before it is returned. A malformed or invalid change fails at generation time rather than at deploy time, and a model that misunderstands a request produces a wrong but valid changeset the developer can see and reject, never invalid syntax that fails in a pipeline.

Output is XML by default, or Liquibase Formatted SQL with database-specific syntax for any of twelve supported dialects, with optional explicit rollback blocks. It speaks STDIO and works with any MCP-compatible client, including VS Code and GitHub Copilot, Claude Code, and Claude Desktop, and is distributed through the public MCP Registry, Docker Hub, GitHub Container Registry, Maven Central, the Liquibase package repository, and JBang. It requires no database connectivity of any kind, makes no LLM calls of its own, has no listening socket, and can operate fully air-gapped once the JAR or container image is present. Its only credential is a Liquibase license key.

Deployment Connectors

Liquibase Secure 6.0 establishes the platform that Deployment Connectors will build on. Deployment Connectors extend governed database change into the enterprise systems teams already use: ServiceNow for approvals and change requests, GitHub for pull request workflows and pipeline orchestration with database-specific controls, and Terraform for infrastructure-managed databases, so teams keep their existing workflows while strengthening governance. Deployment Connectors are not part of the 6.0.0 release; read about the roadmap in What’s next for Liquibase Secure: Change Intelligence and new Deployment Connectors.

Security: SSO and RBAC

Liquibase Secure Server ships with enterprise authentication and an authorization model designed from a blank sheet against the access control patterns of regulated environments. Both are Core services shared by Change Intelligence and Change Governance. For the complete model, including permission vocabulary, resolution rules, and compliance evidence guidance, see the Liquibase Secure Role-Based Access Control Technical Overview.

Authentication and single sign-on

People sign in with an email and a password that the server manages itself, and operators can close self-service registration for the whole installation so new users arrive only through SSO or an administrator’s invitation. A Workspace Admin can also configure Microsoft Entra single sign-on per workspace, in the application and with no operator-level environment changes, through either OIDC or SAML 2.0 (one protocol active per workspace at a time), restrict it to your tenant, and let SSO and password sign-in coexist while you migrate. Disabling or deleting an SSO provider revokes the sessions it issued rather than leaving them to expire. Multi-factor authentication is delegated to your identity provider: where the Entra tenant requires MFA or conditional access, those policies apply to every SSO sign-in, and the server carries no separate authenticator enrollment or recovery-code custody of its own. First-time SSO arrivals are provisioned just in time into a Pending group with zero permissions until an administrator assigns them, and two lockout guards prevent configuration mistakes: the last enabled SSO provider cannot be disabled while registration is closed, and the last remaining administrator cannot be removed. Scope for this release: user provisioning is just-in-time only (SCIM is deferred), logout is local to Liquibase Secure Server (federated single logout is deferred), and Entra group claims are not consumed, so group membership is assigned in Liquibase Secure Server rather than inherited from the directory.

API tokens and service principals

For pipelines, each workspace issues API tokens that are shown once, stored only as a hash, and can be rotated or revoked at any time; every operation is attributed to the token that sent it. Two kinds of token exist. Service principal tokens belong to a distinct machine principal type scoped to one or more projects: they can post operation data and resolve Change Governance Assignments for the assets they deploy, but cannot sign in to the web application, cannot join groups, and cannot read any operation, dashboard, or permission data, so a pipeline token that leaks from a CI log cannot be repurposed as a read credential for the estate. User API tokens carry a human user’s permissions for interactive and scripted API use. Issue a service principal for every CI/CD pipeline and reserve user tokens for people.

Role-based access control

Access is granted to groups, not individuals, and permissions are granted through templates and groups with a default set in place from the moment a workspace is created. Six persona-based, immutable templates ship in every workspace, Workspace Admin, Application Developer, DBA, Platform/DevOps Engineer, Security Reviewer, and Service Principal, each applied to a group at a scope: the whole workspace, a list of projects, or a list of specific database connections. Customers adjust a group’s access with an overlay rather than forking a template, so Liquibase can improve templates in later releases without discarding customer configuration. Exceptions are handled with direct grants and denies on individual entities, which is what lets a single sensitive operation be contained even from principals whose template would allow it, and a named incident responder be re-admitted. Ownership is an independent source of access, and an entity is never left ownerless when a user is deactivated or a group deleted.

Enforcement never asks what template a user holds. Every authorization decision resolves a fine-grained permission name (domain:action:resource) at a scope, with one fixed precedence: a direct grant wins outright, a direct deny overrides the baseline, and the baseline is the union of templates, overlays, ownership, and licensed-module grants. Reads are governed throughout, list endpoints filter to what the caller may see, and a view permissions page lets a Security Reviewer answer "who has access to this project" from any project page. Every permission-changing action, from group membership and template assignment to token lifecycle and SSO configuration, is captured in an immutable, searchable, exportable audit log.

Boundary: Liquibase Secure governs access to its own records, the platform’s record of database change and governance configuration, not access to the databases themselves. Who can connect to a database, and with what rights, remains the province of the database’s own privilege system.

Action required when you upgrade

• Scripts that read STDOUT. Commands like update, rollback, and dbDoc now write entirely to STDERR. Set --legacy-stream-routing if you need time to migrate.

• Scripts that check exit codes. Liquibase Secure 6.0 reviews and adjusts CLI exit codes so they have consistent meaning across the product; see Error codes and exit codes. Exit code 0 still means success, and a failure’s exit code now depends on how that failure is classified rather than always being 1.

• Your own Python virtual environment. The embedded Python runtime moves from 3.11 to 3.12 (GraalPy 25.0.2). If you point liquibase.script.python.executablePath at your own environment, recreate it for Python 3.12 before you upgrade, or policy checks will fail with ModuleNotFoundError. If you use only the built-in checks or the embedded virtual filesystem, no action is needed.

• Db2 for z/OS tracking-table properties. Liquibase 6.0 removes liquibase.db2z.trackingTables.location.tablespace, liquibase.db2z.databasechangelog.index, and liquibase.db2z.databasechangeloglock.index. Remove them from your configuration.

• Changesets using a dbms-scoped <sqlFile>. Liquibase 6.0 fixes a bug that left these changesets with the checksum of an empty string, and it repairs the stored checksum on your next update. For a runOnChange changeset the repair re-runs it once, so if its SQL is not idempotent (a plain INSERT rather than a MERGE), that run can insert one duplicate row.

Security vulnerability report

This release includes updates to internal platform components and third-party dependencies to address known security vulnerabilities and strengthen the overall platform security posture of Liquibase Secure. These updates help organizations maintain secure deployment environments, improve compliance readiness, and reduce operational risk associated with outdated software components.

CVE summary

Liquibase Secure also includes VEX (Vulnerability Exploitability eXchange) files with every release to communicate Liquibase’s official assessment of reported CVEs. Refer to the VEX file included with the 6.0.0 release (files ending in .vex.json) for the complete list of vulnerability assessments and exploitability status. For more information about VEX files and how to interpret their status values, see the VEX documentation.

Full list of changes