Deploying to PostgreSQL with drm-cli + Liquibase or Flyway

[dband-drm]

---

This week we published a step-by-step tutorial on deploying to PostgreSQL using drm-cli layered on top of Liquibase or Flyway. Wanted to share the approach here and hear how others are handling PostgreSQL deployments in their pipelines.

---

The problem we kept running into

Liquibase and Flyway are solid tools for versioning your PostgreSQL schema. But once you're managing deployments across multiple environments — dev, staging, prod — you start needing things they don't provide out of the box:

• A persistent history of what was deployed, when, and by whom (separate from the changelog)
• Encrypted connection strings you can commit safely
• Automatic retries when a deployment hits a transient failure
• Pre/post scripts that run around every deployment, not just schema changes
• A single release that targets multiple databases in one coordinated step

That's the gap drm-cli fills. It doesn't replace Liquibase or Flyway — it runs on top of them.

---

What a PostgreSQL release looks like with drm-cli

A minimal release.yml targeting PostgreSQL with Liquibase looks like this:

release:
  name: "billing-schema-v1.4"
  version: "1.4.0"

solutions:
  - name: billing-db
    engine: liquibase
    database: postgresql
    changelog: changelogs/billing.xml
    connection:
      host: "db.internal.example.com"
      port: 5432
      database: "billing"
      username: "deploy_user"
      password: "{{ env.DB_PASSWORD }}"

Run it with:

drm-cli deploy --release release.yml --environment production

drm-cli calls Liquibase under the hood, captures the result, logs the deployment to its release history, and handles retries if the connection drops mid-run.

---

Encrypted credentials

If you'd rather not rely on environment variables, drm-cli supports encrypting the connection string at rest:

drm-cli encrypt --value "postgresql://deploy_user:password@db.internal.example.com:5432/billing"

Store the encrypted value in your release.yml. drm-cli decrypts it at deploy time using your key — the plaintext never sits in the file.

---

Release history

After every deployment, drm-cli writes a record to its local history store:

2026-04-17T14:32:11Z  billing-schema-v1.4  production  SUCCESS  42s

That's separate from Liquibase's DATABASECHANGELOG table — it's a deployment-level audit trail, not a changelog table.

---

Full tutorial

The complete step-by-step guide — including Flyway configuration, environment setup, and troubleshooting — is on dev.to:

👉 Deploy to PostgreSQL with drm-cli + Liquibase: A Step-by-Step Guide

---

Questions for the community

A few things we're curious about based on conversations we've had:

1. Are you running Liquibase or Flyway for PostgreSQL, or something else? We built first-class support for both, but we want to make sure we're covering the patterns people actually use.

2. How are you handling credentials in your deployment pipelines? Environment variables, secrets managers, encrypted files — we've seen all three. Curious what's working.

3. Are you deploying to a single PostgreSQL instance, or managing multiple environments from one pipeline? The multi-environment case is where drm-cli's release history becomes most useful — happy to dig into that if it's relevant.

Drop your setup in the comments. If you're hitting a specific pain point with PostgreSQL deployments, we want to hear it — it feeds directly into what we prioritise for v1.2.

---

drm-cli is free and open-source.
Docs → github.com/dband-drm/drm-cli
Install → pip install drm-cli