In Liquibase Secure server, Change Governance capabilities bring centralized policy management, which scales organizational standards across the enterprise while decreasing the need for manual review. Entirely within your trust boundary, Change Governance provides a graphical, searchable, shareable, and customizable library of policies, assigns policy coverage to your entities (pipelines, connections, changelogs), and inherits the Liquibase Secure server permission model, designed for the access control patterns of regulated environments.

For application developers, DBAs, governance leads, and compliance teams, Change Governance provides modern configuration methods, scaled delivery, easily shared compliance workflows, and integrated audit trails for clear accountability.

Set up Change Governance for your team walks through bringing your policies into the library and putting them in force.

New capabilities and new terms

Change Governance introduces new aspects to the Liquibase ecosystem, and with them new terms.

• Workspace: The top-level construct in Liquibase Secure server holding all users, groups, governance assets, and Change Intelligence assets. In 6.0, users are limited to one workspace.

• Catalog: Within your policy collection, catalogs are the top-level bucket, holding packages, which in turn hold checks. Build catalogs by platform, team, release, or whatever works within your organization's workflows. The Liquibase Default Catalog holds the checks that ship with Liquibase Secure and is read-only.

• Package: Packages hold checks, and starting with 6.0 every check is in a package, initially structured by check category. Legacy uncategorized checks land in an Uncategorized Checks package. The package is the base element in Change Governance.

• Check: A policy check, with the same name, parameters, and severity it has in the CLI. Change a check's configuration and choose Save As to make a customized copy.

• Assignment: The mapping of policy assets to workspace entities such as projects, pipelines, database connections, and changelogs. Assignments carry an immutable assignment ID, used in checks operations run by the Liquibase Secure CLI, and have a name, a description, and access permissions as their identifying metadata. Assigning one check from a package assigns the whole package, with the other checks disabled by default. A governance assignment is not a template assignment in the authorization model, which applies a permission template to a group.

Understand policy governance goes deeper into how these fit together.

Executive summary

Liquibase Change Governance is the centralized policy management capability of Liquibase Secure server, providing enterprise teams a single pane for finding, creating, customizing, organizing, and sharing the policy library. It replaces local and remote file wrangling through command-line wizards with a graphical, searchable collection of policy assets (catalogs, packages, and checks), and it maps that library to the entities teams already operate (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, tweaked, and shared instead of rebuilt.

Assignments are the mechanism that keeps collaborative work viable from development to production. Each assignment carries an immutable assignment ID, so policy content can be edited, extended, or retargeted by permissioned actors without touching pipeline configuration. Governance evolves without breaking established CI/CD parameters.

Change Governance runs entirely inside your trust boundary and inherits the Liquibase Secure server permission model. That model provides six persona-based templates applied at workspace, project, or connection scope, group overlays that customize without forking the upstream template, entity-level grants and denies for exceptions, and an immutable audit log of every permission change. Check and package version history records who changed what, and rollback to a prior version is a single action. Governance runs provide key data for Change Intelligence dashboards, closing the loop from policy definition to executed evidence, remediation, and improvement.

Key outcomes for enterprise-scale governance teams

• Centralize policy management so standards are written once and applied many times across the organization.

• Scale governance delivery without scaling manual review workloads. Teams are a click away from pre-configured, tested policies.

• Share proven compliance workflows across releases, applications, and lines of business by copying and adapting what already works.

• Separate duties cleanly, with different groups governing the same pipelines under their own assignments and concerns.

• Strengthen audit readiness with version history, permission audit trails, and governance run evidence in Change Intelligence.

The Change Governance problem at enterprise scale

Enterprise change governance does not fail for lack of policy. It fails because useful policies live in multiple local and remote files, a friction often dodged by skipping policy check operations. Checks settings files, package files linking to other checks settings files, flow files which invoke them, and properties files are scattered across repositories, workstations, and CI/CD agents, configured through command-line wizards by the one person on the team who knows them. A standard proven on one pipeline is copied by hand to the next, or not at all. Coverage is asserted rather than known, and the evidence that a given policy actually governed a given deployment is reconstructed after the fact.

The centralized Change Governance capability of Liquibase Secure server closes that gap by making policy a centralized, searchable, and shareable organizational asset rather than just another set of files, turning a proven standard into organizational infrastructure with common-sense access controls. A catalog of packages and checks is authored once, divided by outcome, platform, release, or pipeline, however your organization already works, then tuned and tweaked across releases, applications, and lines of business. A base library is copied into a new catalog in a few clicks, then customized for a team's specific compliance concerns and put to work without rebuilding it all by hand.

Existing investment carries forward, growing from teams who already have the policies, checks, and knowledge. What large organizations lack is a way to hold them in common, see where they apply, and prove they ran. The Change Governance capability of Liquibase Secure server bridges that gap.

Policies

There are two main aspects to Change Governance in Liquibase Secure server, Policies and Assignments, reflected in the two links under Govern in the left navigation.

Manage catalogs

The Policies link opens a list of all catalogs in the workspace. Each catalog card carries the title, description, and package count, along with the author, the created date, and the groups with permission to view, use, and edit the content in the catalog. From this page you can also create a catalog with the + New Catalog button, or search the catalogs to find a specific one. Click the card or its Manage button to open the catalog and list the packages it contains.

Manage packages

Choosing a catalog from the All Catalogs page or the interactive breadcrumb opens a list of the packages in that catalog. Each package card carries the title, description, and metadata about the package, along with an option to see all the assignments the package is in and other management tools. Click the package or its Manage button to open it and configure the checks it contains.

From this screen you can also create a catalog, package, or check with the green + New button. Created packages and checks land in the current catalog. You can also import a checks settings file, or a bundled checks package zip created with the Liquibase Secure CLI's checks export command, to generate a full catalog, packages, and checks structure from your existing policy content.

Manage checks

Clicking a package lists the checks it contains. Add new checks with the + New check button in the upper right, or copy checks in from another package. Select checks in bulk with the upper left checkbox, or individually with the checkbox on each check card. A card lists the check's short name, description, category, and severity setting, with an option to see and edit the check's parameter configuration. Enable or disable checks in bulk across the package from the upper right toggle, or individually from each card's Enabled toggle.

Configure checks

Configure a check's parameters by choosing Configure from the gear icon on its card, or by clicking See Current Configuration near the bottom of the card. That reveals the check's configuration panel, which the Edit button activates. Each parameter lists its value options when the values are enumerated, or an open input field when they are open-ended.

Click Save to confirm your changes. You can overwrite the existing values by confirming with Save, or generate a new check by choosing Save As..., which also lets you rename the check and choose a destination in any catalog and package you have access permissions for.

Share checks across catalogs and packages

Checks can be shared and tuned by another user with access permissions, which greatly increases the efficiency of developing policy coverage across an enterprise. Select full packages or individual checks with their checkboxes to surface three options, Assign, Access, and Move. The Move button opens a dialog to choose a destination catalog and package. Once a check is copied, changes to it are specific to that copy, and the original is unaffected.

Note: The Assign button sends the selected checks to the Assignments side of Change Governance, described below, and the Access button opens the screen to configure access permissions on the selected packages and checks.

Assignments

Assignments map policies to workspace, project, and pipeline assets such as changelogs and database connections, generating an assignment ID that Liquibase checks workflows use. The Assignments page lists assignment cards carrying titles, descriptions, the assignment ID, pipeline and group permissions, and, behind a Details link, metadata such as the author and creation date. Click a card or its Manage button to reveal the policies and workspace assets in the assignment. You can also create an assignment with the + New Assignment button in the upper right.

To create an assignment, choose policies, either specific checks or full packages, and click the Assign button.

After clicking Assign, either create a new assignment or choose an existing one from the list. The opened assignment lists all the workspace and project assets. You can select the assets you have access permissions for. Assets you do not have permission for are visible but cannot be selected.

After choosing the collection of workspace and project assets, click Save to generate or update the assignment.

An assignment ID is immutable, so it stays the same as the policies and covered assets inside it change. Pipeline and checks operations pick up policy and asset changes to an assignment without any edits of their own, and Review policy coverage shows which assets each policy reaches.

Designed for enterprise personas

Application and team leads, DBAs, policy authors, governance and compliance teams, platform engineers, security reviewers, and auditors all have a default permission template tuned to their workflow. Permissions are governed centrally by Liquibase Secure server, audited continuously, and extensible through overlays and entity-level grants and denies without forking the model.

What Change Governance is, and is not

Change Governance is the centralized policy management capability of Liquibase Secure server. It holds your policy assets, organized as catalogs, packages, and checks, in a searchable, shareable library, structured however your organization works, for example packages grouped by a shared concern such as production safety or naming conventions, or one catalog per database platform. You map those governance assets to the platform entities, meaning pipelines, database connections, and changelogs, through a graphical interface, and express coverage as named assignments. Each assignment issues an immutable assignment ID that CI/CD workflows reference in place of a checks settings file. Every check and package carries version history and an assignments view, so teams can see who changed what and where an asset is in use before changing it.

Change Governance is not itself a policy engine, and it is not a database client. Checks execute where they always have, in the Liquibase Secure CLI, running inside your existing pipelines and developer workflows, using the assignment ID. Change Governance stores and resolves the policy configuration that a run consumes, and receives the results of that run for reporting in Change Intelligence. It is also not a version control system for changelogs or schema. It versions policy assets, meaning checks, packages, and their configurations, not the database changes those policies inspect. Finally, Change Governance does not connect to your databases, does not execute checks itself, and does not require you to author or maintain the Liquibase ecosystem files that policy has historically lived in.

Change Governance is also not a standalone application. It has no API, web tier, database, or authentication of its own. It runs inside Liquibase Secure server alongside the server's core services and Change Intelligence, and you administer it through the same workspace, groups, templates, and audit log.

This separation is intentional, and it has practical implications:

• The Liquibase Secure CLI remains the execution point. Existing CI/CD jobs keep their structure. The only change is that the checks run and checks show commands reference an assignment ID rather than a checks settings file path.

• Policy changes do not require pipeline changes. The assignment ID is immutable, so checks and targets inside an assignment can be added, removed, or tuned without editing established workflow parameters.

• One asset can be governed from several perspectives. A single pipeline or connection can carry several assignments, letting a DBA guild, a platform admin group, and a security review group each enforce their own concerns and keep each run narrow to what that group inspects.

• Ecosystem files become background infrastructure. Checks settings files, package files, flow files, and properties files are managed by Liquibase Secure server. New users and server-only users do not need to know they exist to find, customize, share, and deploy policy.

• Existing policy investment carries forward. A checks settings file or a checks package file can be imported directly into a new catalog or package, so your established standards populate the library rather than being rebuilt.

• Governance activity is reportable, not reconstructed. Check run output returns to Change Intelligence, where policy outcomes appear alongside deployment and drift evidence.

Liquibase Secure platform architecture

Liquibase Secure is delivered as two components. Both run inside your trust boundary, and Change Governance is part of the second.

Liquibase Secure CLI. The command line tool that 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. The Secure CLI also hosts the Change Intelligence extension, which is bundled in the distribution and disabled by default, and its checks commands can resolve policy configuration from Change Governance instead of a local file.

Liquibase Secure server. A self-hosted, containerized server that you deploy and operate. It never connects to a managed database. Everything it knows arrives from Secure CLI instances running in your own pipelines, or from users in the browser. The server hosts three functional areas behind one API and one web application:

• Core services: Present in every installation. They cover account and workspace services, project management and the shared entity model (projects, database connections, changelogs, and pipelines), license management and tracking, role-based access control, and the other administration services, including users, service principals and API tokens, single sign-on configuration, and the audit log.

• Change Intelligence: The visibility capability. It receives operation metadata from the extension, files it under the shared entity model as operations, and presents deployment history, DORA metrics, policy check outcomes, drift findings, and on-demand AI analysis.

• Change Governance: The policy capability. It holds your policy library as catalogs, packages, and checks with version history, and maps that library to projects, pipelines, connections, and changelogs through assignments that the Secure CLI resolves at runtime of checks operations.

The three areas are not separate applications. They share the Liquibase Secure server API and web tiers, the data stores, the authentication layer, and the access control model. Each registers its own permission domain with the core RBAC catalog and contributes grants to the six default templates, so administering access to Change Governance uses the same groups, templates, and audit log as everything else in the server. A capability that is not enabled for the installation has its permissions made inert and its interfaces closed, while the core services remain fully administrable.

Within this architecture, Change Governance occupies one place, the policy area of Liquibase Secure server, and has one counterpart in the Secure CLI, the checks commands, which resolve an assignment ID against the server and then execute the checks on the host. Everything around them, from authentication and RBAC to the data stores and the reverse proxy, is core infrastructure that Change Intelligence uses in exactly the same way.

Solution architecture

Change Governance consists of two parts inside Liquibase Secure server, its routes in the Liquibase Secure server API and its two user interfaces in the web application, and one counterpart in the Secure CLI, the checks commands that resolve an assignment ID against the server. All of them run inside your trust boundary, and the server side is reached through the same reverse proxy, on the same port, as everything else in the server.

Change Governance in the Liquibase Secure server API

The Liquibase Secure server API is a NestJS service written in TypeScript. Change Governance contributes the catalog, package, check, and assignment routes to that API, together with the assignment resolution endpoint the Secure CLI calls. It validates and persists policy assets and assignments in the primary database you control, relies on the core services for tenancy and authorization, serves the REST endpoints the Policies and Assignments interfaces consume, and emits real-time events over WebSockets through Redis pub/sub. The API tier is stateless and scales horizontally behind your reverse proxy.

Change Governance in the web application

The Liquibase Secure server web application is a Next.js application written in React, served by its own Node process behind a reverse proxy, either one you provide or the nginx container managed by the server's Docker Compose configuration. Change Governance contributes two connected interfaces to that application, one for configuring policies (catalogs, packages, and checks) and another for configuring assignments. The audit log and permission management interfaces belong to the core services and are shared with Change Intelligence. The web application communicates with the API over HTTPS for REST traffic and over WSS for real-time updates.

Assignment resolution by the Secure CLI

When configured with a valid assignment ID, the Liquibase Secure server URL, and an API token during a checks show or checks run operation, the Liquibase Secure CLI requests the configuration behind that assignment from the server. The server responds with the resolved checks and their settings, which the Secure CLI consumes exactly as it would a local checks settings file, running the operation as usual on the executing host and, if you report operations to the server, sending the operational outcome to Change Intelligence through the extension. Assignment resolution is a capability of the Secure CLI's built-in checks commands, not of the Change Intelligence extension. The two paths share only the token that authenticates them.

Data flow from Change Governance to the Secure CLI and back

The data flow runs from Change Governance to a Liquibase Secure CLI operation, and back to Change Intelligence:

1. You find, create, and customize governance assets, meaning policy packages or checks, for your specific needs in the web application.

2. You select governance assets to assign to projects, pipelines, connections, or changelogs.

3. An assignment ID is generated and carried as a property, an environment variable, or another standard method to the Liquibase Secure CLI checks operation in your CI/CD or sandbox workflow.

4. The checks operation requests the assignment from Liquibase Secure server, presenting the assignment ID and a valid API token.

5. Liquibase Secure server responds with the configured check settings.

6. The Liquibase Secure CLI executes the checks operation on the host.

7. If you have configured it, the Change Intelligence extension in the CLI sends the structured results to Change Intelligence, where they appear on the dashboards.

Logical architecture

The diagram below summarizes the two components of Liquibase Secure, the trust boundary, and the small set of external dependencies.

Three paths cross the boundary between the Secure CLI and Liquibase Secure server, and all three are initiated by the CLI over HTTPS:

• The Change Intelligence extension posts operation metadata to the ingest endpoint.

• The checks commands request the check configuration behind an assignment ID from Change Governance.

• The license telemetry collector receives usage information under its own credential.

Users reach the web application through the reverse proxy over HTTPS and WSS. The only optional egress from the server is the LLM endpoint you configure for Change Intelligence AI analysis, and you remove it entirely by hosting the model in your own environment.

Deployment model

Change Governance runs inside Liquibase Secure server, which is delivered as a self-hosted product. You own the deployment, the data, the network, and the egress posture. Liquibase publishes container images deployable on Docker Compose, Amazon ECS, Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine, or any container platform you already operate. There is no separate installation for Change Governance. The capability is part of the Liquibase Secure server images, so enabling it requires no additional container.

Components inside the trust boundary

All runtime components run within your environment. None require Liquibase-managed infrastructure or external SaaS dependencies for normal operation. The components below are shared by the core services, Change Intelligence, and Change Governance.

Network posture

• Inbound: Limited to the reverse proxy that fronts the API and web tiers. The proxy terminates TLS for HTTPS (REST and the web application) and WSS (live events). Two kinds of clients arrive through it: users in the browser, and Secure CLI instances on your CI/CD agents and developer hosts, which post operation metadata for Change Intelligence and request assignment configuration from Change Governance. No other inbound paths exist.

• Outbound: Required only when Change Intelligence AI analysis is enabled, and only to the LLM endpoint you configure. Change Governance itself makes no outbound connections. The assignment resolution exchange is a request from your own Secure CLI and a response from the server, both inside your environment. If you do not enable AI analysis, or you point it at a self-hosted model, Liquibase Secure server can operate in a fully air-gapped configuration.

• Lateral: No connectivity is required or used from Liquibase Secure server to monitored databases. Change Governance in particular never reaches a database or a changelog. Checks execute in the Secure CLI, on the host that already has access to the target.

Data residency

All of your data, including operation records, properties, policy assets, assignments, and configuration, remains in databases you own. Nothing leaves your environment except traffic between your own Secure CLI instances and Liquibase Secure server, and, optionally, the AI provider call Change Intelligence makes to the endpoint you configure.

Security posture

The security posture described here belongs to Liquibase Secure server and applies identically to the core services, Change Intelligence, and Change Governance. Where Change Governance adds a control of its own, the text says so.

Transport security

TLS is terminated at your reverse proxy in front of the API and web tiers. Cipher suites and certificate management follow your own policy at the proxy layer. HTTPS is the recommended configuration for every deployment reachable over a network you do not fully control. The server also accepts plain HTTP for local and fully isolated environments where encryption is not a requirement, so transport encryption is a deployment decision rather than a product constraint. WebSocket connections from the browser follow the same proxy, as WSS wherever TLS is terminated. Secure CLI traffic to the server follows the same rule, HTTPS wherever the proxy terminates TLS.

Authentication

Authentication is a core service, built on BetterAuth, and supports the controls expected in enterprise environments.

• Email and password authentication.

• Single sign-on against Microsoft Entra, over OIDC or SAML 2.0, configured per workspace.

• OAuth2 with Microsoft as the identity provider.

Multi-factor authentication is delegated to your identity provider. Liquibase Secure server carries no native second factor of its own. Where your Entra tenant requires MFA or conditional access, those policies are enforced upstream and apply to every SSO sign-in. This is a deliberate design decision, taken so the server has no separate authenticator enrollment to manage, no recovery-code custody, and no cryptographic surface of its own to bring into FIPS scope.

Operators can close self-service email and password registration for the whole installation. With registration closed, the sign-up route is refused at the server rather than merely hidden, existing accounts continue to sign in, and new users arrive only through SSO or an administrator's invitation.

API tokens authenticate Secure CLI traffic: service principal tokens for CI/CD ingest and assignment resolution, and user API tokens (personal access tokens) for assignment resolution and interactive or scripted API use. Ingest accepts service principal tokens only. Tokens are displayed once at creation, are stored only as a hash so they cannot be retrieved later, and can be rotated or revoked at any time.

Single sign-on

Single sign-on is configured per workspace by a workspace admin, in the application, with no operator-level environment changes. The administrator chooses the protocol that matches their Entra enterprise app:

• OIDC, configured with the tenant ID, client ID, and client secret.

• SAML 2.0, configured by uploading IdP metadata, pointing at a metadata URL, or entering the IdP entity ID, sign-on URL, and signing certificate directly. Liquibase Secure server publishes its own service provider metadata for registration in Entra.

One protocol is active per workspace at a time. Client secrets and signing certificates are held in the encrypted secrets store described below.

Sign-in is restricted to the configured tenant. Under OIDC, the tid claim on the ID token is validated against the configured tenant. Under SAML, an assertion is accepted only when the issuer matches the configured IdP entity ID and the signature validates against the configured certificate. Personal Microsoft accounts cannot sign in to a workspace bound to an organizational tenant, and a mismatch is refused with a message that names the cause without exposing configuration detail.

First-time arrivals are provisioned just in time. An invited user joins the groups named in the invitation, and anyone else is placed in the system Pending group with zero permissions, where they see an explicit awaiting-access screen until an administrator assigns them. Subsequent sign-ins resolve to the same user record through a stable identifier, without creating duplicates and without changing group membership.

Two lockout guards protect the installation from configuration mistakes: the last enabled SSO provider cannot be disabled while self-service registration is closed, and the last remaining administrator cannot be removed. Disabling or deleting an SSO provider revokes the active sessions that provider issued rather than leaving them to expire.

User provisioning is just in time. Logout is local to Liquibase Secure server. Entra group claims are not consumed, so group membership is assigned in Liquibase Secure server rather than inherited from the directory.

Secrets handling

Sensitive configuration values, including database connection credentials and SSO client secrets and signing certificates, are held in a separate, isolated PostgreSQL instance. All values are encrypted at rest with AES-256-GCM using per-value key derivation. The master encryption key is supplied at deploy time as an environment variable or a mounted file, typically sourced from your KMS or vault, and is never stored alongside the ciphertext.

Sensitive Liquibase properties never reach the server as values. The Change Intelligence extension strips them on the originating host before any network call. It strips any argument that Liquibase itself marks as obfuscated, together with connection URLs, and transmits each as a name with a null value and a sensitive flag. The API applies a second, independent pass on ingest. It redacts by key name against the patterns password, secret, token, key, and credential, and strips credentials embedded inside URL values. The second pass writes a distinct sentinel, so an operator can tell a value the API caught from one the extension stripped as intended. Neither pass is configurable, and both err toward redacting too much. The UI displays a redacted indicator, with no reveal control available under any user action.

Change Governance adds no secret handling of its own. Policy assets are configuration, not credentials. The assignment response returned to the Secure CLI carries the resolved checks and their settings and nothing else, and check results reported back to Change Intelligence pass through the extension's redaction described above.

Secure CLI authentication and principal separation

Secure CLI instances authenticate to Liquibase Secure server with API tokens. Two kinds of token exist, and the difference matters for least privilege.

Service principal tokens belong to service principals, a distinct principal type from human users. Service principals are scoped to one or more projects, cannot sign in to the web application, cannot join groups, and can reach only the routes that explicitly admit them. Every other endpoint refuses a service principal token regardless of possession. Two routes admit them: the Change Intelligence ingest endpoint, where a service principal may write operation data only for entities inside its assigned projects, and the Change Governance assignment resolution endpoint, where its default view-and-use permission on assignments lets a pipeline retrieve the checks assigned to the assets it deploys, without any governance authoring rights. A request naming an entity or assignment outside the principal's scope and a request naming one that does not exist are refused identically, so a CI token cannot be used to enumerate what exists. This separation eliminates the most common abuse path for pipeline credentials, which is repurposing them for read access. Tokens can be rotated in place and revoked, and both actions are recorded in the audit log.

User API tokens (personal access tokens) are workspace-scoped tokens owned by a human user, and they carry that user's permissions. They are accepted for assignment resolution and for interactive and scripted use of the API, but not for ingest. Operation data is written only by service principals, so a user token cannot feed a pipeline's results into Change Intelligence. Issue a service principal for every CI/CD pipeline and reserve user tokens for interactive and scripted use.

Assignment resolution authentication

A single assignment resolution endpoint accepts requests from the Secure CLI's checks commands. Each request is authenticated by an API token and names one or more assignment IDs, and the server validates three things before responding:

• The token is valid and not revoked.

• The principal behind it holds the view-and-use permission on assignments (gov:view:assignment).

• The named assignment lies within that principal's scope. For a service principal the scope is its assigned projects. For a user token it is whatever the user's group memberships grant.

A request that fails any of the three is refused, and a request naming an assignment outside the principal's scope is refused identically to one naming an assignment that does not exist.

The response carries the resolved checks and their settings and nothing else. It grants no read access to catalogs, packages, operations, or any other record, and a service principal token used for resolution cannot be turned around to browse the policy library or the dashboards. Because a service principal token also authenticates Change Intelligence ingest, a pipeline needs a single Liquibase Secure server credential to both resolve its policy and report its results.

Audit log

The audit log is a core service. It captures every permission-changing action in Liquibase Secure server, across the core services, Change Intelligence, and Change Governance, in an immutable record. Each entry records the actor, the timestamp, the target, and the before and after state. Logged events include:

• User invitation, deactivation, and reactivation.

• Group create, rename, and delete operations.

• Group membership changes.

• Template assignment, scope change, and unassignment.

• Overlay changes.

• Direct grant create and revoke.

• Direct deny create and revoke.

• Entity ownership added, removed, and transferred.

• API token lifecycle events, meaning create, rotate, and revoke.

• Service principal lifecycle events, meaning create, rotate, and revoke.

• SSO configuration changes, including enabling and disabling SSO, protocol changes, tenant and endpoint changes, and secret or certificate rotation. Secret rotations record a reference such as a certificate fingerprint, never the value itself.

The log is searchable by actor, target, and date range. Access is gated by the audit view privilege, which is bundled into the Security Reviewer template by default. Entries are exportable for handoff to a reviewer or an evidence package.

Change Governance adds its own change record alongside the audit log. Every check and package carries version history that records who changed what, rollback to a prior version is a single action, and assignments carry version history as well. Governance runs themselves are reported through Change Intelligence, so policy outcomes appear next to deployment and drift evidence.

Authorization model

Liquibase Secure server ships with a permission model designed against the access control patterns of regulated environments. The model is a core service, owned by the platform. There is one permission catalog, one set of persona-shaped templates, one resolver, and one fixed precedence order. Change Intelligence and Change Governance implement the model rather than inventing their own. Each registers its permissions into the platform catalog and contributes grants to the platform templates. Change Governance therefore brings no principals, groups, scopes, or precedence of its own. What it adds is a permission domain and a set of default grants that enrich the six templates.

One boundary is worth stating at the outset. The model governs access to Liquibase Secure server's own records, which are the server's record of database change and governance configuration, and never 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.

The model is built on principals, groups, templates, overlays, ownership, and direct overrides. Liquibase Secure Role-Based Access Control describes all of them, including the six persona templates, the resolution order, and how ownership contributes access.

Permission vocabulary and the gov domain

Every permission is a three-part name, domain:action:resource, and every authorization decision resolves one exact name at one scope. Wildcards are not part of the grammar. Domains are reserved namespaces, each owned by exactly one functional area. Change Governance registers its own domain, gov, with sixteen permissions. Registration is validated at startup. A malformed name, a duplicate registration, or a second capability claiming an existing domain stops the service rather than letting it boot with a silently wrong catalog.

When Change Governance is not enabled for an installation, its permissions are made inert. Template assignments, overlays, and direct grants referencing them resolve to nothing, are shown in the view permissions surface as originating from a currently disabled capability, and are preserved rather than deleted, so enforcement resumes automatically if the capability is enabled again. The core namespaces can never be made inert, so the permission model can never disable the ability to administer itself.

Change Governance permissions

The governance entities are a catalog, which contains packages, which bundle checks, and a governance assignment, which applies packages to project assets. The permission set follows one pattern, with a view, create, edit, and delete permission per governance record type:

Scope and cascade

For Change Governance entities, the scope of a permission check is a catalog, a package, a check, or a governance assignment, and containment follows the same downward rule as the core hierarchy. A permission held at catalog scope applies to every package and check inside that catalog. One held at package scope applies to the checks inside that package but not to the catalog. One held at check scope applies to that check alone. As with core scopes, an unscoped governance check is denied.

Assignments carry two scopes. Access to an assignment and to the project assets inside it is granted as a union of two things: the governance assignment scope itself, which allows creation, editing, and use of the assignment and its assignment ID, and the workspace, project, pipeline, and connection scopes, which allow use of those assets within the assignment. These permissions do not derive from catalog, package, or check access, nor the reverse. Holding a catalog grants nothing on the assignments that reference it. The table above shows only the governance half of that union. The core half follows the ordinary workspace, project-list, and connection-list eligibility rules.

Default template contributions

Change Governance contributes the following defaults to the six permission templates. Edit and delete rights restricted to the creator by default are expressed through ownership, so they can be widened by overlay or by adding owners.

Everything else is inherited. Governance entities reuse the same ownership, grant-and-deny, and audit hooks as core entities.

Governed reads and compliance evidence

• Governed reads throughout. Every read endpoint that returns operational, configuration, policy, or permission data enforces a corresponding view permission, and list endpoints filter to what the caller may see rather than refusing the whole page. A small set of routes is deliberately unauthenticated because it must function before or without a session. Those are the health and version probes, the pre-sign-in settings the login page reads, the SSO sign-in routes themselves, the invitation preview a new user opens from an emailed link, and the license telemetry collector, which carries its own credential. None of them return operational, policy, or permission data.

• View permissions surface. A security reviewer, or any principal with the view grants privilege, can open a who-has-access view from any project, and a who-has-direct-grants-or-denies view from any entity detail page. Seeing who has access is a separate permission from reading operational data, and it is bundled into the Security Reviewer and Workspace Admin templates rather than into the operational templates. These interfaces produce audit evidence on demand.

• Compliance evidence, and its boundary. The audit log and the view permissions surface together produce reviewable evidence of who could see which Liquibase Secure server records at any point in time, suitable for SOC 2, HIPAA, and similar review activities, answerable from inside the product by a reviewer whose own access is read-only. It is not evidence about access to the databases themselves, and presenting these reports as an answer to that question would misrepresent the control.

Forward compatibility

The authorization model is not a fixed set of permissions with room left over. It is a registry, and extending it is a shipped capability. Permissions are declared in reserved namespaces, each owned by a named functional area. Three owners are already registered, the core services, Change Intelligence, and Change Governance, each contributing its own permissions and its own additions to the default templates without forking them.

Authorization is always evaluated against a permission, never against a template name. You can restructure templates, overlays, and groups, and Liquibase can ship template updates, without changing how any endpoint is enforced. This is what makes the overlay mechanism safe. Your overlays are preserved across a template update, and the new template version applies cleanly beneath them.

Deployment and sizing guidance

Liquibase Secure server ships as a set of containers and a Compose configuration that runs all of them. That configuration is how the server runs, and it is the supported baseline. It stands up the application tiers, the databases, the cache, and the reverse proxy together, with the liquibase-platform CLI generating configuration, managing secrets, and running database migrations. You do not assemble the product from parts to get it running, and Change Governance requires no additional container. It is part of the API and web images.

Liquibase Secure server runs its databases, connection pooler, and Redis as the bundled containers in this configuration.

The default deployment

Every component runs as a container on a single host.

Database migrations run as a separate, on-demand container rather than automatically at startup, so schema changes are an explicit operator action.

Evaluation and small teams

This shape suits evaluation, pilots, and small teams, with every container on one host.

Production

This shape suits production deployments with multiple projects, multiple environments, and active use of the web application. The starting point is the same Compose configuration on a larger host, with the database volumes on dedicated storage.

These figures are starting points for a deployment of this shape, not the output of a published benchmark. Actual sizing depends on operation volume, retention, and how many users are active at once. For Change Governance, the sizing driver is not storage. Policy assets and assignments are small, and their version history grows slowly. The relevant figures are API capacity for assignment resolution requests at pipeline peak times and the number of concurrent users authoring policy in the web application. Where Change Intelligence is also in use, its operation history is what governs storage.

What is not required

Direct connectivity from Liquibase Secure server to monitored databases is not required and is not used. Change Governance requires no direct connectivity to changelogs or monitored databases either. The assignment ID, together with the server URL and an API token, is carried into the Secure CLI workflow and used inside your existing pipelines and developer workflows. The server also requires no shared filesystem between containers, and no scheduler or job runner beyond what the container platform already provides.