Skip to content

⭐ Persistent Volumes

Terrence Daniels edited this page Jul 9, 2026 · 2 revisions

The Persistent Volumes subsystem is responsible for creating, managing, and mounting durable storage directories for all database engines. It ensures that data survives container restarts, upgrades, and re‑provisioning. Every StartAction integrates with this subsystem to guarantee predictable, isolated, and secure storage for each database instance.

This page explains how persistent volumes work, how directories are generated, how they are mounted into containers, and how the subsystem integrates with the rest of the platform.

Purpose of Persistent Volumes The Persistent Volumes subsystem provides:

Durable storage for all database engines

Predictable directory structure

Engine‑specific mount paths

Automatic directory creation

Secure permissions

Isolation between database instances

Support for SSL, config, and keyfile directories

It ensures that no database loses data during container lifecycle events.

Volume Types Each database engine may require multiple persistent directories:

  1. Data Directory Stores the actual database files.

  2. SSL Directory Stores CA, server certificates, and private keys.

  3. Config Directory Stores engine‑specific configuration files.

  4. Keyfile Directory (MongoDB) Stores MongoDB authentication keyfiles.

These directories are created automatically.

Directory Structure All persistent volumes follow a predictable structure: /data/coolify/// Inside this directory, engine‑specific subdirectories are created:

MySQL / MariaDB data/ ssl/ conf/

PostgreSQL data/ ssl/ conf/

Redis / KeyDB / Dragonfly data/ ssl/ conf/

MongoDB data/ ssl/ keyfile/ conf/ This structure ensures consistency across all engines.

How StartActions Use Persistent Volumes Each StartAction integrates with the Persistent Volumes subsystem in a consistent way:

  1. Request Volume Creation StartActions call the volume generator to create required directories.

  2. Create Directories Directories are created under: /data/coolify///

  3. Set Permissions Permissions are normalized to ensure:

Database engines can read/write

SSL keys remain protected

Keyfiles (MongoDB) have strict permissions

  1. Mount Volumes Volumes are mounted into engine‑specific paths: | Engine | Mount Path | |-------------|------------------------| | MySQL | /var/lib/mysql | | PostgreSQL | /var/lib/postgresql/data | | Redis | /data | | KeyDB | /data | | Dragonfly | /data | | MongoDB | /data/db |

  2. Start Container Once volumes are mounted, the container starts with durable storage.

Example Volume Mapping (Conceptual) volumes:

  • /data/coolify/mysql//data:/var/lib/mysql
  • /data/coolify/ssl/:/etc/mysql/ssl
  • /data/coolify/mysql//conf:/etc/mysql/conf Why Persistent Volumes Matter Persistent Volumes ensure:

Data durability

Predictable storage layout

Secure handling of sensitive files

Engine‑specific directory mapping

Isolation between database instances

Consistent behavior across all engines

Without persistent volumes, database containers would lose all data on restart.

Clone this wiki locally