⭐ StartActions Overview

StartActions Overview StartActions are the core provisioning units responsible for launching database containers in a predictable, secure, and configurable manner. Each database engine (MySQL, PostgreSQL, Redis, etc.) has its own dedicated StartAction class, allowing the system to generate Docker Compose files, SSL certificates, persistent volumes, environment variables, and healthchecks tailored to that engine.

This page provides a high‑level overview of how StartActions work, why they exist, and how they fit into the broader architecture.

Purpose of StartActions StartActions serve as the orchestration layer between:

Laravel backend

Docker Compose generation

SSL subsystem

Persistent volume generator

Environment variable builder

Healthcheck configuration

Runtime options

They encapsulate all logic required to start a database container cleanly and consistently.

Why StartActions Exist

1. Engine‑Specific Behavior Each database engine has unique requirements:

MySQL needs MYSQL_ROOT_PASSWORD

PostgreSQL needs POSTGRES_PASSWORD

Redis may need no password but supports TLS

MongoDB requires keyfile authentication

KeyDB and Dragonfly have custom runtime flags

StartActions isolate these differences.

2. Predictable Provisioning Instead of scattering provisioning logic across controllers, traits, and helpers, StartActions provide:

One entry point per engine

One place to generate Compose

One place to generate SSL

One place to generate volumes

One place to generate environment variables

3. Extensibility Adding a new database engine becomes trivial:

Create StartNewEngine.php

Implement the required methods

Register the engine

No rewrites. No hacks.

How StartActions Work Every StartAction follows the same lifecycle:

1. Validate Configuration Check:

Ports

Credentials

Volume paths

SSL settings

Engine‑specific requirements

2. Generate SSL Certificates If SSL is enabled:

Create CA

Create server cert

Mount certs into container

3. Generate Persistent Volumes Using the GeneratesLocalPersistentVolumes trait:

Create local directories

Map them into the container

Support file‑based volumes

4. Build Environment Variables Normalize and inject:

Engine variables

User‑provided variables

System variables

SSL variables

5. Generate Docker Compose Compose includes:

Image

Ports

Volumes

Environment

Healthchecks

Networks

Custom runtime options

6. Start the Container Compose is passed to the provisioning engine to launch the container.

Database Engine	StartAction Class
MySQL	StartMysql
PostgreSQL	StartPostgresql
Redis	StartRedis
MariaDB	StartMariadb
MongoDB	StartMongodb
KeyDB	StartKeydb
Dragonfly	StartDragonfly

Each class implements the same interface but contains engine‑specific logic.

Common Responsibilities Across All StartActions

1. SSL Integration Generate certificates

Mount certs

Configure engine to use TLS

2. Persistent Volume Mapping Data directories

Config directories

Keyfiles (MongoDB)

SSL directories

3. Environment Variable Normalization Required engine variables

Optional user variables

System variables

SSL variables

4. Healthchecks Each engine defines:

Command

Interval

Timeout

Retries

5. Custom Runtime Options Examples:

MySQL: --default-authentication-plugin=mysql_native_password

PostgreSQL: shared memory settings

Redis: TLS flags

MongoDB: keyfile authentication

Dragonfly: memory limits

Example StartAction Flow (MySQL) mermaid flowchart TD A[StartMysql] --> B[Validate Config] B --> C[Generate SSL] C --> D[Generate Volumes] D --> E[Build Environment Variables] E --> F[Generate Docker Compose] F --> G[Start Container] How StartActions Fit Into the System StartActions are called by the provisioning engine whenever a user starts a database. They act as the “brains” of the operation, ensuring that every engine is started with:

Correct configuration

Secure defaults

Predictable behavior

Proper isolation

Proper resource limits

They are the foundation of the entire database provisioning system.