Drone CI can be configured to use either SQLite or PostgreSQL for its metadata backend.

Here’s how you can set up Drone CI to use SQLite:

version: '3.7'

services:
  drone-server:
    image: drone/drone:latest
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./drone:/data
    environment:
      - DRONE_GITHUB_CLIENT_ID=YOUR_GITHUB_CLIENT_ID
      - DRONE_GITHUB_CLIENT_SECRET=YOUR_GITHUB_CLIENT_SECRET
      - DRONE_SECRET=YOUR_DRONE_SECRET
      - DRONE_DATABASE_DRIVER=sqlite3
      - DRONE_DATABASE_DATASOURCE=drone.sqlite
  drone-agent:
    image: drone/agent:latest
    environment:
      - DRONE_SERVER=ws://drone-server:80
      - DRONE_TOKEN=YOUR_DRONE_AGENT_TOKEN

In this configuration, DRONE_DATABASE_DRIVER is set to sqlite3, and DRONE_DATABASE_DATASOURCE points to a file named drone.sqlite in the mounted volume ./drone. This file will store all of Drone’s metadata.

Now, let’s look at configuring Drone CI to use PostgreSQL:

version: '3.7'

services:
  drone-server:
    image: drone/drone:latest
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    environment:
      - DRONE_GITHUB_CLIENT_ID=YOUR_GITHUB_CLIENT_ID
      - DRONE_GITHUB_CLIENT_SECRET=YOUR_GITHUB_CLIENT_SECRET
      - DRONE_SECRET=YOUR_DRONE_SECRET
      - DRONE_DATABASE_DRIVER=postgres
      - DRONE_DATABASE_DATASOURCE=postgres://user:password@host:port/database?sslmode=disable
  drone-agent:
    image: drone/agent:latest
    environment:
      - DRONE_SERVER=ws://drone-server:80
      - DRONE_TOKEN=YOUR_DRONE_AGENT_TOKEN

  postgres:
    image: postgres:13
    environment:
      POSTGRES_DB: database
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

Here, DRONE_DATABASE_DRIVER is set to postgres. The DRONE_DATABASE_DATASOURCE is a standard PostgreSQL connection string. You’ll need to replace user, password, host, port, and database with your actual PostgreSQL credentials and connection details. I’ve also included a separate postgres service in the docker-compose.yml for completeness, which sets up a PostgreSQL instance. The volumes for drone-server and postgres are both pointing to ./postgres-data, ensuring that the PostgreSQL data is persisted.

When you first start Drone with a new database configuration, it will automatically create the necessary tables. If you’re migrating from one database backend to another, you’ll need to export your data from the old backend and import it into the new one. Drone provides commands for this:

To export data from an existing SQLite database:

docker run --rm \
  -v $(pwd)/drone:/data \
  drone/drone:latest \
  drone export --file drone.json --database sqlite --datasource drone.sqlite

To import data into a PostgreSQL database:

docker run --rm \
  -v $(pwd)/drone:/data \
  drone/drone:latest \
  drone import --file drone.json --database postgres --datasource "postgres://user:password@host:port/database?sslmode=disable"

The most surprising thing about Drone’s database configuration is how seamlessly it handles the switch between backends. You don’t need to rewrite your pipeline configurations or change how you interact with Drone; the underlying storage mechanism is entirely abstracted away. This means you can start with SQLite for local development or small deployments and easily migrate to PostgreSQL for production environments without any pipeline-level impact. The drone export and drone import commands are your best friends for this transition.

The DRONE_DATABASE_DATASOURCE environment variable is the key that unlocks this flexibility. For SQLite, it’s simply a file path. For PostgreSQL, it’s a full JDBC connection string. Drone parses this string and uses the appropriate driver to connect and interact with the database. The configuration is designed to be minimal, allowing you to focus on your CI/CD workflows rather than the intricacies of database management.

One aspect that often trips people up is the sslmode parameter in the PostgreSQL connection string. If your PostgreSQL instance is running locally without SSL, you’ll want to explicitly set sslmode=disable. If SSL is enabled, you’ll need to configure it appropriately, which might involve providing certificates in the connection string or ensuring Drone’s container has access to them. The default behavior when sslmode is omitted can vary depending on the PostgreSQL driver and server configuration, leading to unexpected connection errors.

Once you’ve got your database configured, the next logical step is to explore how to manage secrets within your Drone pipelines.

Want structured learning?

Take the full Drone course →