Vault Dynamic Secrets for Databases

By Kokil Thapa | Last reviewed: August 2026

Static database credentials in environment files are a persistent security liability for production web applications. Implementing Vault dynamic secrets for databases replaces long-lived passwords with short-lived, automatically rotated credentials that expire after use or a defined TTL. This guide covers the practical architecture, configuration, and Laravel integration patterns required to deploy this system reliably, building on infrastructure principles relevant to any secure server setup in Nepal or globally.

How do Vault dynamic secrets for databases actually work?

Understanding the mechanism is essential before touching configuration. Vault does not store database passwords; it generates them. The Database Secrets Engine maintains a privileged root connection to your database (MySQL, PostgreSQL, etc.) and uses it to create and revoke users programmatically.

The workflow follows three distinct phases:

1. Credential Request: Your Laravel application authenticates to Vault (via AppRole, Kubernetes auth, or token) and requests credentials from a specific database role path like database/creds/my-app-role.
2. Dynamic Generation: Vault executes pre-configured SQL creation statements against the database using its root connection, creating a new user with restricted permissions and a username typically prefixed with v- or token- for traceability.
3. Automatic Revocation: When the lease TTL expires or the application explicitly revokes the lease, Vault drops the user. If Vault becomes unavailable, the database user persists until its own expiry or manual cleanup — a critical failure mode to plan for.

This differs fundamentally from static secret rotation. There is no shared password to leak, no rotation window where two systems might use conflicting credentials, and no need to restart application pods after rotation. Each pod, each request, or each batch job can obtain isolated credentials.

How do you configure the Vault Database Secrets Engine for MySQL or PostgreSQL?

Configuration happens entirely via the Vault CLI or API. These examples assume Vault 1.18+ (current stable in 2026) and MySQL 8.4 LTS or PostgreSQL 17.

Enable and configure the database connection

# Enable the database secrets engine
vault secrets enable database

# Configure the MySQL connection with root-level privileges
vault write database/config/my-mysql \
    plugin_name=mysql-database-plugin \
    connection_url="{{username}}:{{password}}@tcp(mysql-host:3306)/" \
    allowed_roles="laravel-app,reporting-readonly" \
    username="vault_root" \
    password="<root-password>" \
    max_open_connections=5 \
    max_idle_connections=2

The allowed_roles parameter is a security boundary. Even if someone compromises a Vault token with access to this mount, they cannot create credentials for roles not listed here. Always scope this tightly.

Create the database role with creation SQL

vault write database/roles/laravel-app \
    db_name=my-mysql \
    creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO '{{name}}'@'%';" \
    revocation_statements="DROP USER IF EXISTS '{{name}}'@'%';" \
    default_ttl="1h" \
    max_ttl="24h"

Key points from production experience:

• Use % or specific CIDR for the host wildcard depending on your network. In containerised environments, % is often necessary since pod IPs are ephemeral.
• Never grant SUPER, PROCESS, or FILE to dynamic users. Restrict to DML operations on specific schemas.
• Set max_ttl as a hard ceiling. Even if an application requests a longer lease, Vault enforces this limit.
• Test revocation statements before relying on them. Some MySQL versions behave differently with DROP USER IF EXISTS versus plain DROP USER.

For PostgreSQL, the creation statement syntax differs but the pattern is identical. Use CREATE ROLE ... WITH LOGIN PASSWORD ... VALID UNTIL and GRANT ... ON SCHEMA .... PostgreSQL's native role expiration provides a secondary safety net if Vault fails to revoke.

How do you integrate Vault dynamic secrets with Laravel 12 in production?

Laravel does not natively support dynamic credential injection at runtime. You need a middleware layer that fetches credentials before the database connection is established. For teams evaluating whether to adopt this pattern versus sticking with traditional env-based config, understanding the modern Laravel architecture best practices helps contextualise where Vault fits.

Option A: Custom service provider (recommended for most Laravel apps)

Create a dedicated service provider that resolves database credentials from Vault before any Eloquent or Query Builder usage:

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\DB;
use GuzzleHttp\Client;

class VaultDatabaseProvider extends ServiceProvider
{
    public function boot(): void
    {
        if (! $this->app->environment('production')) {
            return;
        }

        $client = new Client([
            'base_uri' => config('services.vault.address'),
            'headers' => ['X-Vault-Token' => $this->getVaultToken()],
            'timeout' => 5,
        ]);

        $response = $client->get('v1/database/creds/laravel-app');
        $data = json_decode($response->getBody(), true);

        config([
            'database.connections.mysql.username' => $data['data']['username'],
            'database.connections.mysql.password' => $data['data']['password'],
        ]);

        // Store lease ID for graceful shutdown revocation
        cache()->put('vault_db_lease_id', $data['lease_id'], now()->addHour());
    }

    private function getVaultToken(): string
    {
        // Prefer AppRole auth in production; fallback to env for debugging
        return file_get_contents('/run/secrets/vault-token')
            ?: env('VAULT_TOKEN');
    }
}

Register this provider before DatabaseServiceProvider in config/app.php. Order matters — Laravel resolves database connections lazily, but queued jobs, scheduled tasks, and eager-loaded relations may trigger early resolution.

Option B: Sidecar proxy for zero-code changes

If modifying application code is prohibitive, run Vault Agent as a sidecar that renders credentials to a file, then point Laravel's DB_USERNAME and DB_PASSWORD to that file via a custom config loader. This adds operational complexity but keeps the application Vault-agnostic. I've used this pattern on legacy Laravel 10 applications where framework upgrades were already scheduled and adding Vault coupling was undesirable.

Handling connection pooling and long-running processes

This is where most implementations fail. Laravel's default MySQL connection persists for the request lifecycle, which works fine for HTTP requests. But queue workers, schedulers, and Octane/FrankenPHP long-running processes hold connections open beyond the credential TTL.

Implement explicit reconnection logic:

// In your queue worker or long-running process
if (cache()->get('vault_db_lease_expires_at') < now()->addMinutes(5)) {
    DB::disconnect('mysql');
    // Re-fetch credentials via Vault API or signal reload
    Artisan::call('vault:refresh-db-creds');
    DB::reconnect('mysql');
}

For Horizon or Supervisor-managed workers, set --max-time=3600 to force worker recycling before typical TTL expiry. This is simpler than mid-job credential refresh and avoids partial-query failures during rotation.

What are the operational risks and failure modes of dynamic database secrets?

Dynamic secrets introduce new failure classes that static credentials don't have. Understanding these prevents 3 AM incidents.

In my experience deploying this across multiple legal-tech portals handling sensitive client data, the most common incident wasn't Vault failing — it was developers forgetting that php artisan migrate:fresh in CI destroys the Vault-managed users mid-pipeline. Always ensure CI pipelines either use separate static credentials or properly authenticate to Vault before running destructive migrations.

When should you avoid Vault dynamic secrets for databases?

Despite the security benefits, dynamic secrets aren't universally appropriate. Skip them when:

• Your team lacks Vault operational maturity. Running Vault HA requires consensus storage (Consul/Raft), backup procedures, and unseal key management. If your team hasn't operated Vault before, start with static secret rotation via Vault's transit engine or AWS Secrets Manager while building operational competence.
• Database drivers don't support mid-connection credential refresh. Some older PDO configurations and legacy frameworks establish connections at boot and never reconnect. Retrofitting dynamic secrets into these systems costs more than the security benefit justifies.
• You have fewer than five services sharing the database. The operational overhead of Vault outweighs the risk reduction for small deployments. Use strong static passwords, encrypted env files, and regular rotation scripts instead.
• Compliance requires credential auditing via database logs. Dynamic usernames change constantly, making forensic analysis harder. Ensure your logging pipeline can correlate Vault audit logs with database query logs before adopting.

For teams managing database-driven websites with moderate traffic and established deployment pipelines, the sweet spot is usually applications handling PII, payment data, or legal records where credential exposure has regulatory consequences. E-commerce platforms processing transactions via Laravel payment integrations are particularly strong candidates since breach impact extends beyond data loss to financial fraud.

Implementing Vault Dynamic Secrets for Databases Securely

Vault dynamic secrets for databases represent a meaningful security upgrade for production PHP and Laravel applications, but success depends on treating it as an infrastructure project rather than a library installation. Start with a non-critical staging environment, validate your failure handling under simulated Vault outages, and only promote to production once your team has rehearsed incident response. The credential generation itself is straightforward; the operational discipline around monitoring, alerting, and graceful degradation is what separates successful deployments from fragile ones.

If you're evaluating this architecture for a production system and want to discuss whether it fits your specific infrastructure constraints, reach out to discuss your database security requirements. I've implemented dynamic secrets across legal-tech and e-commerce platforms and can help assess whether the operational investment aligns with your risk profile.