Skip to content

⭐ Deployment Flow

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

The Deployment Flow defines the full lifecycle of provisioning a database instance — from user configuration, through StartActions, through Docker Orchestration, to final health verification. It ties together every subsystem (SSL, Persistent Volumes, Environment Variables, Orchestration, Testing) into a single, predictable execution pipeline.

This page explains how deployments move through each stage, how subsystems interact, and how the platform ensures deterministic, secure, and reproducible provisioning.

Purpose of the Deployment Flow The Deployment Flow ensures:

Deterministic provisioning

Secure initialization

Correct subsystem sequencing

Engine‑specific behavior

Predictable container startup

Automatic TLS integration

Automatic health verification

Reproducible deployments across updates

It is the backbone of the entire provisioning architecture.

High‑Level Overview flowchart TD A[User Configuration] --> B[StartAction Selected] B --> C[Validate Configuration] C --> D[Generate SSL Certificates] D --> E[Generate Persistent Volumes] E --> F[Build Environment Variables] F --> G[Generate Docker Compose] G --> H[Provisioning Engine] H --> I[Start Container] I --> J[Run Healthcheck] J --> K[Mark Database Running]

  1. User Configuration The deployment begins when the user selects:

Database engine

Version

Port

SSL/TLS settings

Authentication settings

Optional variables

This configuration determines which StartAction is executed.

  1. StartAction Selection Based on the engine, the platform selects one of:

StartMysql

StartPostgresql

StartRedis

StartMariadb

StartMongodb

StartKeydb

StartDragonfly

Each StartAction contains engine‑specific provisioning logic.

  1. Validate Configuration The StartAction validates:

Required variables

Port availability

SSL/TLS settings

Volume paths

Keyfile requirements (MongoDB)

Runtime flags

If validation fails, the deployment stops immediately.

  1. Generate SSL Certificates (Optional) If SSL is enabled:

CA certificate is generated

Server certificate is generated

Server key is generated

Certificates are stored under: /data/coolify/ssl//

  1. Generate Persistent Volumes The Persistent Volumes subsystem creates:

Data directory

SSL directory

Config directory

Keyfile directory (MongoDB) /data/coolify/// Permissions are normalized for security.

  1. Build Environment Variables The Environment Variable Strategy generates:

Required engine variables

Optional variables

System variables

SSL variables

Engine‑specific prefixes

Normalized uppercase keys

Sensitive values are never logged.

  1. Generate Docker Compose The StartAction produces a complete Compose service:

Image

Ports

Volumes

Environment variables

Healthcheck

Runtime flags

TLS configuration

Config mounts

This Compose definition is passed to the provisioning engine.

  1. Provisioning Engine The provisioning engine:

Writes config files

Writes SSL certificates

Writes keyfiles (MongoDB)

Creates directories

Normalizes permissions

Prepares the container environment

This ensures the container has everything it needs before startup.

  1. Start Container Docker Orchestration:

Creates the container

Attaches networks

Mounts volumes

Injects environment variables

Applies runtime flags

Starts the engine

Startup behavior is deterministic across all engines.

  1. Run Healthcheck After startup, the healthcheck runs until the engine reports readiness.

Examples:

mysqladmin ping

pg_isready

redis-cli ping

keydb-cli ping

dragonfly ping

mongo --eval "db.adminCommand('ping')"

If healthcheck fails repeatedly, the deployment is marked as failed.

  1. Mark Database Running Once healthcheck passes:

The database is marked as running

Connection details are stored

SSL paths are stored

Environment variables are finalized

The instance is now ready for client connections.

Why the Deployment Flow Matters The Deployment Flow ensures:

Predictable provisioning

Secure initialization

Engine‑specific correctness

Automatic TLS integration

Reproducible deployments

Clean subsystem coordination

High reliability across updates

Clone this wiki locally