coolify-full — system architecture

One Laravel app, no separate API server, one deployment.

Every React page renders through the same Laravel routes as everything else, via Inertia — there's no standalone SPA and no separately-versioned API surface to keep in sync. The provisioning system on the right is what actually deploys databases; everything left of it is what an operator sees and clicks through.

System Diagram

React 19 + Inertia Frontend
↕ same routes, server-driven props
Laravel Backend
↓ StartActions ↓ Docker Compose Generator ↓ Running Database Containers
↓ SSL Subsystem → feeds Compose Generator
↓ Persistent Volume Generator → feeds Compose Generator

Major Subsystems

Laravel

Backend

  • API endpoints
  • Inertia controllers
  • Database provisioning logic
  • Healthcheck configuration
  • Environment variable builder
React 19 + Inertia

Frontend

  • Component-driven UI
  • Server-driven props, client-side rendering
  • React hooks for state
  • Vite build pipeline
8 engines

Database Provisioning

  • One dedicated StartAction class per engine
  • Generates Compose, env vars, healthchecks, start commands
→ Engine comparison diagram
Shared

SSL Subsystem

  • One CA certificate per server
  • One leaf certificate per database, signed by it
  • Every engine except ClickHouse
→ Deployment Pipeline diagram
Shared

Docker Orchestration

  • Dynamic Compose generation
  • Network configuration, log drain integration
  • Resource limits (CPU, memory, swap)
Shared

Persistent Volumes

  • Local data/config/SSL directory creation
  • Mapped into each database's container
i

Testing follows the same shared-vs-per-engine split: closure-style Pest tests (tests/v4/ and most of the suite) alongside PHPUnit-attribute-style tests (#[Test] on a TestCase subclass) in some tests/Unit// tests/Feature/ files — both are real, deliberate conventions here, not a single strict rule. See the Testing Strategy diagram for the full picture.