• Concept
  • Create

Hosting options for an internal deployment

Last updated: September 29, 2026

The goal is a server your team can reach but that is not exposed to the public internet. The quick start gets an instance running on a single machine; for a production deployment, common approaches are:

On-premises server. A Linux server on your corporate network with Docker installed. Team members connect over the local network or VPN. This is the simplest option if your organization already runs internal servers.

Private cloud VM. A VM on AWS, Azure, or GCP in a private subnet with no public IP. Examples are an EC2 instance in a private VPC subnet, an Azure VM in a private VNet, and a Compute Engine instance with an internal IP only. Team members reach it through a VPN, a bastion host, or a private DNS name. This gives you cloud flexibility without public exposure.

VPN-protected server. Any server, cloud or on-premises, accessible only through your corporate or team VPN. The server can have a public IP as long as the application's HTTPS port (default 443) is firewalled to VPN traffic only.

Note: whichever host you pick, the deployment itself is Docker Compose. There are no Helm charts or Kubernetes manifests, so a Kubernetes cluster is not a supported target. Running the Compose stack on a VM the cluster happens to sit beside is fine.

Whichever host you choose, review the server requirements before you provision, and keep the HTTPS port restricted to your network. The installation itself is the same on any host. The Run Liquibase Secure server locally guide shows the liquibase-platform CLI flow you will reuse on your production machine.