Liquibase Secure server is the central 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 that data, and serves the dashboard your team uses to review it.

Without the server, each developer's Liquibase run is visible only in their own terminal. With the server, every update, rollback, policy check, and drift result lands in one shared dashboard that updates as operations arrive.

The three components

Liquibase Secure server: The central service. It receives operation data from your Liquibase machines, stores it, and serves the web app. Inside the deployment, the server's API listens on port 3000, and the installer bundle places it behind a reverse proxy so that all clients connect through a single HTTPS port. You manage the server with the server CLI included in the installer bundle.

The web app: The browser-based dashboard your team uses to review and analyze operations. The web app runs on your server, not on infrastructure hosted by Liquibase. It is served from the server on port 3001 behind the same HTTPS entry point, and users need only a browser and a URL. Nothing is installed on their machines.

The extension: A component bundled with Liquibase Secure on every machine that runs Liquibase commands. After each command completes, the extension collects operation metadata and reports it to the server. Reporting is non-blocking. If the server is unreachable, the Liquibase command still completes, so adopting the server never puts a deployment at risk.

Everything stays in your network

The server, the web app, and all stored data sit inside your network boundary, and your operation data is never sent to a dashboard hosted by Liquibase. Installing and updating the server do reach the network, because the server and web images are pulled from a license-gated registry, so the deployment is not air-gapped. Licensing itself is offline: an offline license file is validated locally, with no call out to Liquibase at run time.

How the components communicate

Any connection type is supported, but use HTTPS for production deployments: it encrypts traffic between your Liquibase machines and the server, which matters whenever the server is reachable over a shared network or VPN. See Let's Encrypt for obtaining and installing a certificate. The whole stack runs inside your network boundary.

For the concept-level view of how these pieces fit the wider product, see Understand Liquibase Secure.

Data storage

The server uses two separate PostgreSQL databases. Each has a distinct role and runs as its own instance.

For where to host the server in production, whether an on-premises server, a private cloud VM, or a VPN-protected host, see Hosting options for an internal deployment.

What the server adds to Liquibase Secure

The server provides capabilities a standalone Liquibase installation cannot. Drift detection compares a live database against a reference you supply, which is either another database or a saved snapshot, to identify schema drift between environments. Database connection credentials are stored in an isolated PostgreSQL instance, so a compromise of the primary data store does not expose them.

Where teams run it

Teams run the server on an on-premises server, on a private cloud VM in a private subnet, or on a VPN-protected host. The common property is that the server is reachable by your team and not exposed to the public internet.

What your team needs from you

Once the server is running, give each team member the URL of the web application (for example, https://liquibase.internal.yourcompany.com). They can then follow Connect to Liquibase Server to connect their Liquibase runs.

Each user generates their own API token from the web application during setup. The token is shown once at creation time and cannot be retrieved afterward, so users should save it when prompted.

User accounts

The server manages its own user database. Each team member registers directly in the web application with an email address and password, and credentials are stored within the application. You do not need to configure LDAP, SSO, or any external authentication system to get started. If your team requires single sign-on for compliance, you can configure it with Microsoft Entra.