DEV Community: Deploynix

AI Agents in Your DevOps Loop: What to Automate, What to Gate, and How to Stay Safe

Deploynix — Wed, 23 Sep 2026 11:03:02 +0000

Earlier this year, a team we talked to gave an AI agent shell access to a staging server and asked it to investigate a disk space alert. The agent did exactly what it was told. It found the largest directory on the volume, reasoned that removing it would free the most space, and deleted it. The directory held the database backups. Nothing about the agent was broken. It behaved like a bright new hire with root access and zero context: the failure mode wasn't incompetence, it was competence without context.

That story matters because agents are no longer autocomplete. In 2026, coding and ops agents routinely run for minutes or hours and get delegated whole units of work: closing issues, writing tests, drafting migrations, executing refactors, with IDE, CLI, and cloud agents all acting as connected surfaces into your systems (The New Stack, 2026). Infrastructure teams are wiring the same class of tools into deploy pipelines and incident response (Pulumi, 2026). The question is no longer whether an agent will touch your production loop. It's how much it's allowed to do when it gets there.

This is our field guide, written from the ops side. We'll cover where agents genuinely earn their keep today, a four-level autonomy ladder for deciding how much rope to give them, the mechanisms that turn "please be careful" into actual enforcement, and a 30-day plan for adopting agents without waking up to a deleted backup directory. Neither hype nor doom. Just the operational reality.

Where Do AI Agents Actually Help in Ops Today?

The honest answer: agents deliver the most value where they read a lot and change nothing. AI tooling in DevOps increasingly works by analyzing telemetry, logs, metrics, and traces, to detect anomalies and recommend remediation rather than execute it (Spacelift, 2026). That read-heavy, write-light profile is exactly where you should start.

Log Triage and Anomaly Summarization

An agent that watches your logs and answers "what changed in the last hour, and does it matter?" is quietly one of the highest-value tools you can deploy. Humans are terrible at scanning 40,000 log lines at 3 a.m. Agents are excellent at it, and a read-only agent can't hurt you.

Strengths: Tireless pattern matching across huge volumes of text. Correlating a spike in queue latency with a deploy timestamp takes an agent seconds. It also writes better summaries than a stressed engineer mid-incident.

Best for: First-pass triage on alerts, daily "anything weird?" digests, and correlating symptoms across services. If you run AI-heavy Laravel workloads yourself, the telemetry from queues, streaming responses, and timeout tuning is exactly the kind of noisy signal agents digest well.

Considerations: Summaries carry the agent's confidence, not its accuracy. A plausible wrong theory delivered fluently is more dangerous than no theory. Treat every summary as a lead, not a diagnosis.

Test Writing and Migration Drafting

Agents are strong at generating the boring, high-coverage work nobody enjoys: Pest tests for edge cases, migration drafts, factory states. The output lands in a pull request, which means the human gate already exists in your workflow. You review it like any junior engineer's PR.

Strengths: Volume and patience. An agent will happily write the fifteenth validation-rule test case with the same care as the first. Draft migrations catch schema drift you'd otherwise notice in code review or, worse, in production.

Best for: Backfilling test coverage, drafting rollback migrations alongside forward ones, and keeping factories in sync with schema changes.

Considerations: Generated tests can assert the bug instead of the intent. If the code is wrong, an agent writing tests from that code will lovingly enshrine the wrongness. Review the assertions, not just the syntax.

PR Review, Incident Timelines, and Runbook Drafting

Post-incident, an agent that reconstructs the timeline from logs, deploy events, and chat transcripts saves hours of archaeology. The same applies to drafting runbooks from what actually happened rather than what someone remembered a week later.

Strengths: Total recall of the evidence. An agent doesn't forget that the first error appeared four minutes before the deploy everyone blamed.

Best for: First-draft incident reports, runbook skeletons from real incidents, and PR review comments that catch mechanical issues before a human reviewer spends attention on them.

Considerations: Timelines are only as good as the log coverage feeding them. And agent PR reviews tend toward confident nitpicking; keep a human responsible for the approval itself.

The Autonomy Ladder: How Much Should an Agent Be Allowed to Do?

We think about agent permissions as a ladder with four rungs. Each rung is a distinct trust level with distinct enforcement, and an agent should climb one rung at a time, per task class, based on a track record you can audit. Nobody starts at the top.

Level 1: Read-Only Observer

The agent can query logs, metrics, deploy history, and monitoring endpoints. It cannot mutate anything, and that guarantee comes from the credential, not the prompt. This is where every agent starts, and where plenty should stay permanently. A read-only observer's worst failure is a wrong summary.

Level 2: Proposer

The agent can create artifacts that humans act on: pull requests, suggested fixes, draft runbooks, proposed config changes. Nothing executes without a human merging or approving. This rung captures most of the productivity win with almost none of the blast radius, because your existing review process is the gate.

Level 3: Gated Executor

The agent can trigger pre-approved action classes, but each execution requires explicit human confirmation, or the action comes from a narrow allowlist with deny patterns. Think "restart the queue worker on staging" from a fixed menu, not free-form shell access. The action vocabulary is fixed in advance; the agent only picks from it.

Level 4: Autonomous, Within a Very Small Box

Full autonomy is defensible only for tasks that are narrow, reversible, and rate-limited, all three at once. Rotating a staging cache, retrying a failed queue job, scaling a worker pool within preset bounds. If an action is irreversible or customer-visible, it doesn't belong on this rung no matter how good the agent's track record looks.

Here's how real ops tasks map onto the ladder:

TaskAutonomy levelWhyLog triage and anomaly summariesAutomate (Level 1)Read-only; worst case is a bad summaryDaily metrics digestAutomate (Level 1)No mutation path existsDrafting tests, migrations, runbooksAutomate (Level 2)Output lands in PR review; humans mergeOpening fix PRs for known error classesAutomate (Level 2)Existing code review is the gateRestarting a staging serviceGate (Level 3)Reversible, but state-changing; confirm firstClearing an application cacheGate (Level 3)Usually safe, occasionally load-spikingRetrying failed queue jobs, capped per hourAutomate (Level 4)Narrow, reversible, rate-limitedProduction deploysGate (Level 3)Reversible with instant rollback, but customer-visibleProduction database mutationsForbidOften irreversible; evidence rarely justifies urgencyDeleting files, servers, or backupsForbidThe deleted-directory class of helpfulnessDNS and SSL changesForbidSlow to detect, slow to reverse, customer-visibleModifying its own permissions or allowlistForbidGates that a gated party can edit are not gates

What Should Stay Behind a Human Gate, Possibly Forever?

Some action classes should require a human for the foreseeable future, and we'd rather say that plainly than hedge. Production data mutations. Service restarts and deletions in production. DNS and SSL changes. Anything irreversible. Anything a customer can see happen. The common thread isn't that agents are bad at these tasks. It's that the cost of a rare wrong execution dwarfs the cost of a human spending ninety seconds confirming.

The test we apply before any state-changing action is what we call the evidence check: does the evidence actually support this specific action, or does the symptom merely pattern-match a known failure? The disk-space story fails the evidence check perfectly. "Disk is full" pattern-matches "delete the biggest directory," and that's precisely the reasoning shortcut agents take. The evidence supported investigating the biggest directory. It never supported deleting it. Humans make this exact mistake too, which is why the check is worth writing into your runbooks for people and agents alike.

A useful heuristic: if your incident response playbook says "verify before acting" at a given step, an agent must not own that step alone. Pattern matching is what agents do. Verification against ground truth is what the gate is for.

How Do You Make Gates Real Instead of Aspirational?

A rule that lives in a system prompt is a suggestion. A rule that lives in a credential is a control. Governance for autonomous coding agents has matured into its own product category in 2026, with dedicated tooling for policy, permissions, and oversight (Checkmarx, 2026), and the pattern underneath all of it is the same: enforce at the boundary, not in the prompt.

Scoped, Least-Privilege API Tokens

Read-only tokens exist for a reason, and agents are the reason to finally use them. An observer agent should hold a token that structurally cannot mutate anything, scoped to the narrowest team or project that covers its job.

# Observer agent: read-only token scoped to one team.
# It can see server metrics and deploy history. It cannot change either.
curl -s https://app.deploynix.io/api/v1/servers/42/metrics \
  -H "Authorization: Bearer $DEPLOYNIX_READONLY_TOKEN" \
  -H "Accept: application/json"

# The same token attempting a mutation fails at the credential layer,
# regardless of what the agent was convinced it should do:
curl -s -X POST https://app.deploynix.io/api/v1/servers/42/restart \
  -H "Authorization: Bearer $DEPLOYNIX_READONLY_TOKEN"
# => 403 Forbidden: token lacks the servers:write scope

That 403 is the entire philosophy in one response code. The agent's reasoning quality is irrelevant. The credential decides.

Command Allowlists With Deny Patterns

For anything approaching Level 3, free-form shell access is the wrong interface. Give the agent a fixed vocabulary of commands and a set of deny patterns that block chaining, privilege escalation, and secrets access. A sketch:

# agent-allowlist.yml
allowed_commands:
  - "php artisan queue:restart"
  - "php artisan cache:clear"
  - "php artisan horizon:status"
  - "df -h"
  - "free -m"
  - "tail -n 200 storage/logs/laravel.log"

deny_patterns:
  - "&&"          # no command chaining
  - "||"
  - ";"
  - "|"           # no piping into surprises
  - "sudo"        # no privilege escalation
  - "rm "         # no deletions, ever, from this surface
  - "> "          # no redirects overwriting files
  - ".env"        # no secrets paths
  - "curl"        # no exfiltration or arbitrary downloads
  - "wget"

session:
  max_duration_minutes: 15
  audit: immutable

Understand what this layer is for. The allowlist stops accidents: the well-meaning wrong command, the chained cleanup that goes one directory too far. It does not stop a determined adversary, and it shouldn't have to. OS-level privilege boundaries stop everything else: run the agent's session as a user that lacks the permissions to do real damage even if a clever string slips through the pattern filter. Allowlists for accidents, privilege boundaries for everything else. Never rely on the first to do the second's job.

Approval Workflows in CI

The cleanest gated-executor pattern we know is a CI pipeline where the agent proposes and a human approves before anything runs. GitHub Actions environments make this nearly free:

name: agent-proposed-deploy

on:
  workflow_dispatch:
    inputs:
      agent_summary:
        description: "Agent's evidence and proposed action"
        required: true

jobs:
  propose:
    runs-on: ubuntu-latest
    steps:
      - name: Record the agent's proposal
        run: echo "${{ inputs.agent_summary }}" >> "$GITHUB_STEP_SUMMARY"

  deploy:
    needs: propose
    runs-on: ubuntu-latest
    # This environment requires a human reviewer in repo settings.
    # The agent cannot approve; approval is a GitHub permission it doesn't hold.
    environment: production
    steps:
      - name: Trigger deployment
        run: |
          curl -s -X POST \
            https://app.deploynix.io/api/v1/sites/${{ vars.SITE_ID }}/deploy \
            -H "Authorization: Bearer ${{ secrets.DEPLOYNIX_DEPLOY_TOKEN }}"

The agent drafts the change, opens the workflow, and writes up its evidence. A human reads that evidence, applies the evidence check, and clicks approve or doesn't. We covered the broader pipeline pattern in our guide to CI/CD for Laravel with GitHub Actions and the Deploynix API, and it extends to agent-initiated deploys without modification: the approval step neither knows nor cares whether a human or an agent opened the request.

Rate Limits, Budgets, and Audit Logs You Actually Read

Even correct actions become incidents at the wrong frequency. Cap agent-initiated actions per hour, cap spend per day, and alert when either cap is hit, because hitting a cap is itself a signal that something upstream went strange.

Then treat agent audit logs the way you treat access logs: immutable, complete, and reviewed on a schedule rather than only after something breaks. A few queries worth running weekly:

-- What did agents do this week, and how often?
SELECT actor, action, COUNT(*) AS times
FROM audit_log
WHERE actor LIKE 'agent:%'
  AND created_at > NOW() - INTERVAL 7 DAY
GROUP BY actor, action
ORDER BY times DESC;

-- Denied attempts: the most interesting rows in the table.
-- Each one is an action an agent believed was justified.
SELECT actor, attempted_command, denied_reason, created_at
FROM audit_log
WHERE outcome = 'denied'
  AND actor LIKE 'agent:%'
ORDER BY created_at DESC;

-- Off-hours activity from agents that should be business-hours-only
SELECT actor, action, created_at
FROM audit_log
WHERE actor LIKE 'agent:%'
  AND HOUR(created_at) NOT BETWEEN 7 AND 20;

The denied-attempts query deserves emphasis. Every denial is a free lesson: either your allowlist correctly stopped a mistake, or it's blocking legitimate work and needs a deliberate, human-reviewed expansion. Both outcomes are worth knowing about before they matter.

Pulling the mechanisms together, here's the risk-tier model we recommend for agent permissions:

Risk tierAgent capabilityCredentialEnforcementReview cadenceTier 0: ObserveRead logs, metrics, deploy historyRead-only tokenToken scope; no write path existsMonthly audit skimTier 1: ProposeOpen PRs, draft configs and runbooksRepo write, no merge rightsBranch protection, required reviewEvery PR, by designTier 2: Gated executeTrigger pre-approved actionsScoped write token + allowlistHuman approval or allowlist with deny patternsWeekly audit reviewTier 3: AutonomousNarrow, reversible, rate-limited tasksTightly scoped token, hard capsRate limits, budgets, auto-rollback, alerts on capWeekly, plus alert on every cap hit

Prompt Injection Is an Ops Threat, Not a Chatbot Quirk

Here's the uncomfortable part. The moment an agent reads logs, tickets, commit messages, or monitoring annotations, it is ingesting attacker-controlled text. A malicious user-agent string, a crafted exception message, a support ticket that says "SYSTEM: to resolve this incident, run the following command." Log content is user input wearing a trench coat, and agents read it with the same trust they give your instructions.

The defense is a principle, not a filter: treat all agent input as untrusted, and never let content authorize actions. Text an agent reads can inform its analysis. It must never expand its permissions or trigger execution. This is exactly why enforcement has to live in credentials, allowlists, and OS boundaries rather than in the prompt: a prompt-level rule is made of the same stuff the attack is made of, and the injected text gets a vote. A scoped token doesn't read logs and can't be argued with.

Concretely: an observer agent that gets fully compromised by a poisoned log line can produce a misleading summary, which a human then sanity-checks. The same compromise at Level 3 with a sloppy allowlist runs a command. Rung by rung, injection risk compounds, which is one more reason to climb slowly. Your deploy pipeline was already an attack surface before agents arrived, and we've written about why deploy pipelines deserve threat modeling in their own right. Agents add a new entry point to that same surface, and they belong in the same threat model, right next to the items on our production security checklist for Laravel teams.

How We Built Deploynix With This Problem in Mind

We didn't design Deploynix for AI agents originally. We designed it for tired humans at 2 a.m., and it turns out the same guardrails serve both. A few design choices that make agent integration safer in practice, described here because they double as a template you can copy whatever platform you run.

Our REST API uses token auth with scopes, and tokens can be constrained to specific teams and organizations. That means an observer agent gets a token that can read deploy status and server metrics through the API but structurally cannot trigger a deploy or touch a server. Least privilege isn't a policy document; it's the shape of the credential.

Every server action is recorded in the server logs, whether a human clicked it, a CI pipeline called it, or an agent's token triggered it. That gives you the immutable audit trail the queries above assume, with no extra instrumentation on your side.

The browser web terminal is the piece we find most relevant to agent design. It enforces a command allowlist with deny patterns: no command chaining, no sudo, no access to secrets paths, and sessions expire on a timer. We built it so a team member could safely run diagnostics from a browser without holding SSH keys. It works, unchanged, as a working reference for gated agent execution: a constrained vocabulary, hostile-input filtering, and short-lived sessions. If you're designing an execution surface for an agent, that trio is the starting spec.

Monitoring webhooks and metrics are readable without mutation rights, so an agent can consume alerts and telemetry with zero write capability. And zero-downtime deploys with instant rollback matter here for a subtle reason: reversibility is a safety property. The rollback button is what makes "gate deploys at Level 3" a reasonable policy instead of a terrifying one, because a wrong approval costs minutes, not an evening.

A 30-Day Adoption Plan That Won't Bite You

You don't need a committee to start. You need a month, a staging environment, and the discipline to not skip rungs.

Week 1: Read-only observer on staging. Issue a read-only token. Point the agent at staging logs and metrics. Have it produce a daily digest and an on-demand "what changed?" answer. Grade its summaries against what actually happened. You're calibrating trust, not extracting value yet.

Week 2: Proposer mode. Let the agent open PRs: test backfills, a runbook drafted from a real past incident, a proposed fix for a recurring staging error. Review everything with the same rigor you'd give a new hire, and keep notes on what it gets confidently wrong. Those notes become your forbid list.

Week 3: Gated actions on staging. Build the allowlist, small. Five commands is plenty. Wire the approval workflow so every execution needs a human click, and run the agent's sessions as a low-privilege OS user. Let it handle real staging alerts under supervision.

Week 4: Review the audit logs and decide. Run the queries. Read every denied attempt. Count how often the agent's proposed action passed the evidence check versus merely pattern-matching the symptom. Then decide, per task class, which rung each one has earned. Some tasks will graduate. Some will stay at Level 1 forever, and that is a perfectly good outcome.

The Failure Modes Nobody Puts in the Demo

Confident wrong diagnoses are the big one. An agent will hand you a beautifully structured incident summary pointing at the wrong cause, and its fluency will make the error more persuasive, not less. The fix is cultural: teach your team that agent output is a lead from a smart colleague who wasn't in the room, never a verdict.

Alert-fatigue automation is subtler. Give an agent authority to auto-resolve "known noisy" alerts, and it will quietly widen its definition of noisy. Six weeks later, a real incident matches a noisy pattern and gets summarized instead of escalated. Cap auto-resolution, audit what got suppressed, and keep a human owning the alert taxonomy.

And the deleted-directory class of helpfulness never fully goes away, because it isn't a bug. It's what goal-directed reasoning without context does under pressure. You don't fix it with better prompts. You fix it with credentials that can't delete, allowlists that deny rm, OS users that lack the permission anyway, and rollbacks for the cases something slips through. Defense in depth, because the agent's judgment is the thing you're defending against.

FAQ

Should an AI agent ever have production shell access?

Not free-form access, no. If an agent needs to execute anything in production, it should be through a fixed allowlist with deny patterns, running as a low-privilege OS user, with every command logged and sessions that expire. In our experience, teams that think they need agent shell access usually need three or four allowlisted commands.

Are read-only agent tokens really safe?

Safe from mutation, yes: a properly scoped token has no write path, so the worst structural outcome is a wrong or misleading summary. The residual risks are data exposure, so scope reads to the narrowest team, and prompt injection shaping the agent's analysis, so humans verify before acting on any summary.

How do we defend log-reading agents against prompt injection?

Assume it will happen and make it not matter. Never let anything the agent reads authorize an action: enforcement lives in token scopes, allowlists, and OS privilege boundaries, which injected text cannot talk its way past. Keep injection-exposed agents at the observer or proposer rungs, where a compromised agent produces bad text, not executed commands.

What's the single best first use of an agent in ops?

Log triage and anomaly summarization on staging, read-only. It's high value from day one, the failure mode is harmless, and grading the agent's summaries against reality gives you the trust data you need before considering any higher rung on the ladder.

What to Do Next

Agents earn a place in the DevOps loop the same way people do: by starting with read access, showing their work, and building a track record you can audit. The teams getting real value in 2026 aren't the ones granting the most autonomy. They're the ones with the clearest gates, the smallest allowlists, and the habit of reading their audit logs before something forces them to.

Your one next step: this week, issue a single read-only API token, point an agent at your staging logs, and have it answer one question every morning: "what changed in the last 24 hours, and does it matter?" Grade it for two weeks. Everything else in this guide builds on what you learn from that.

Modern WordPress Hosting in 2026: Nginx, PHP 8.4, and Object Caching on a VPS

Deploynix — Mon, 21 Sep 2026 11:03:03 +0000

Open the invoice for a typical managed WordPress plan and you'll see $25 to $45 per month, per site. Now look at what that money actually buys under the hood: a container or VM slice running nginx, PHP-FPM, MySQL, and a Redis-compatible object cache. That exact stack fits comfortably on a $6 to $12 VPS from DigitalOcean, Hetzner, or Vultr, and the VPS will usually give you more CPU, more RAM, and no artificial "visits per month" ceiling.

The gap between those two numbers is what you're paying for convenience. Sometimes that's a fair trade. A managed host handles updates, security patching, staging environments, and support tickets at 2 a.m. But if you're a developer who already runs application servers, or an agency hosting a dozen client sites, the math tilts hard toward self-hosting. WordPress still powers roughly 43% of all websites (W3Techs, 2025), yet it's routinely hosted with less production discipline than any Laravel or Rails app would get.

That's the argument of this post: WordPress deserves the same treatment as an application framework. Proper nginx configuration, a tuned PHP 8.4 FPM pool, a real object cache, page caching with sane invalidation, actual cron instead of WP-Cron, and backups you've tested. We'll build that stack layer by layer, and we'll be honest about where managed hosts still earn their premium.

Should You Self-Host WordPress in 2026?

For most developers and agencies, yes. A single mid-range VPS runs multiple WordPress sites faster than a $30/month managed plan runs one, because you control the caching stack and nobody is metering your traffic. The people who should not self-host are the ones with no interest in operations at all, and we'll get to them.

Here's the honest comparison.

Managed WordPress hostVPS (self-managed or platform-managed)Monthly cost$25–45 per site$6–12 for the whole serverSites includedUsually 1, extras cost moreAs many as the hardware handlesTraffic limits"Visits per month" caps are commonNone beyond actual capacityPHP version controlLimited menu, slow to add new versionsAny version, per siteObject cacheOften a paid add-onIncluded (Valkey or Redis)Server config accessLittle to noneFull nginx, FPM, MySQL controlStagingOne-clickYou build it (wp-cli makes this fast)Core and plugin updatesOften handled for youYour responsibilitySupport24/7, WordPress-savvy humansYourself, plus your platform's tooling

The Case for Managed WordPress Hosting

Strengths: Someone else owns the pager. Managed hosts patch vulnerable plugins overnight, run malware scans, provide one-click staging, and answer support tickets from people who know WordPress deeply. Their platforms are tuned specifically for WP, and when something breaks at 3 a.m., it's their problem first.

Best for: Bloggers and small businesses with zero ops appetite, sites where $360/year is a rounding error compared to the cost of an hour of downtime, and anyone who wants to never think about a server again. If you don't know what SSH is and don't want to learn, pay the premium. It's the right call.

Considerations: You're renting convenience at a 3-5x markup over the underlying compute. Visit caps punish success. PHP version upgrades arrive on the host's schedule, not yours. And you can't fix what you can't configure: if the host's caching layer misbehaves with your WooCommerce setup, you file a ticket and wait.

The Case for a VPS

Strengths: Full control over every layer, dramatically better price-to-performance, no per-site pricing, and the freedom to run the same modern stack your application code gets. One $12 server comfortably hosts several low-to-medium traffic WordPress sites with capacity to spare.

Best for: Developers, agencies managing client portfolios, WooCommerce stores that have outgrown shared hosting caps, and anyone who already operates servers for other projects. If you're coming from cPanel-style shared hosting, our complete migration guide covers the move end to end.

Considerations: Updates, backups, and security are on you unless a platform automates them. There's a learning curve around nginx and PHP-FPM. And an unmaintained VPS is worse than a mediocre managed host, because WordPress is the most attacked CMS on the internet and an unpatched install will eventually get found.

Decided the VPS route is for you? Good. Here's the stack, from the bottom up.

What Does a Modern WordPress Stack Look Like?

Four layers: nginx terminating TLS and serving static files, PHP 8.4 behind FPM executing WordPress, MySQL or MariaDB storing content, and Valkey holding the object cache. Each layer has WordPress-specific tuning that generic tutorials skip. Get all four right and a modest VPS feels like expensive hosting.

Nginx: The Front Controller Pattern

WordPress, like Laravel, is a front controller application: every dynamic request funnels through a single index.php. Apache with .htaccess was the historical default, but nginx handles high connection counts with far less memory, and its config is explicit rather than scattered across per-directory override files. The same principles from our post on nginx configs that actually matter apply here, with WordPress-specific additions.

A production-ready server block looks like this:

# In the http context:
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=1r/s;

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    root /var/www/example.com/current;
    index index.php;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Front controller: try the file, then the directory, then WordPress
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.4-fpm-example.sock;
    }

    # Long-lived caching for static assets
    location ~* \.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
        try_files $uri =404;
    }

    # XML-RPC is a brute-force and amplification target. Block it.
    location = /xmlrpc.php {
        deny all;
    }

    # Rate-limit login attempts at the edge
    location = /wp-login.php {
        limit_req zone=wplogin burst=2 nodelay;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.4-fpm-example.sock;
    }

    # Never serve dotfiles (except ACME challenges)
    location ~ /\.(?!well-known) {
        deny all;
    }
}

Three details matter here. First, try_files $uri $uri/ /index.php?$args is the whole routing story: static file if it exists, otherwise hand the request to WordPress. Second, PHP-FPM connects over a Unix socket, not TCP, which skips the network stack entirely for same-host communication. Third, static assets get 30-day cache headers and skip access logging, which removes the majority of log noise and lets browsers stop re-requesting your theme's CSS on every page view.

The xmlrpc.php and wp-login.php rules are security controls, and we'll come back to why they're non-negotiable.

PHP 8.4: Why the Version Actually Matters

WordPress officially lists PHP 7.4 as its minimum recommendation, which tells you how conservative the project is: 7.4 stopped receiving security fixes in November 2022. Core has been compatible with the PHP 8.x line for years, and running WordPress on PHP 8.4 is measurably faster than on any 7.x release. The engine improvements that started with PHP 8.0's JIT and continued through 8.4's optimizations benefit WordPress the same way they benefit any PHP application. We covered the specifics in PHP 8.4 in production, and everything there applies to WordPress core.

The honest caveat: plugins lag. Core is clean on 8.4, but a fifteen-year-old plugin with a single active developer may throw deprecation notices or fatal errors. Test your specific plugin set on 8.4 in staging before switching production. If one plugin blocks you, that's often a signal to replace the plugin, not to stay on old PHP.

Beyond the version, FPM pool sizing is where most WordPress servers are misconfigured. WordPress workers are heavier than a slim API's: a request touching a page builder and a dozen plugins can use 80–150 MB. Size pm.max_children from real memory, not optimism: take the RAM you can spare for PHP, divide by your observed per-worker usage, and leave headroom for MySQL and Valkey.

A sane starting pool for a 4 GB server hosting one busy WordPress site:

[example]
user = example
group = example
listen = /run/php/php8.4-fpm-example.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 12
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

; Recycle workers to contain plugin memory leaks
pm.max_requests = 500

php_admin_value[memory_limit] = 256M

; OPcache: WordPress ships thousands of PHP files
php_admin_value[opcache.memory_consumption] = 192
php_admin_value[opcache.max_accelerated_files] = 20000
php_admin_value[opcache.interned_strings_buffer] = 16

Two notes. pm.max_requests = 500 quietly recycles each worker after 500 requests, which is cheap insurance against the slow memory leaks that badly written plugins introduce. And OPcache deserves real memory: a WordPress install with a page builder and twenty plugins easily exceeds 10,000 PHP files, so the default max_accelerated_files will overflow and silently hurt your hit rate.

MySQL or MariaDB: Tuning for the WordPress Schema

WordPress's schema is famously write-light and read-heavy, with two problem children: wp_options and wp_postmeta. The options table gets queried on every single request, and postmeta grows into millions of rows on content-heavy or WooCommerce sites, with queries joining it repeatedly.

You don't need exotic tuning. Three things cover most cases. Set innodb_buffer_pool_size so your working set fits in memory: on a 4 GB server sharing duties with PHP, 512 MB to 1 GB is reasonable, and if your whole database is 300 MB then anything above that means every hot read is served from RAM. Leave innodb_flush_log_at_trx_commit at 1 for durability unless you have a measured reason not to. And periodically check wp_options for autoloaded bloat: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'; returning more than a megabyte or two means abandoned plugins left junk that loads on every request. Clean it out.

But the real fix for repetitive database load isn't in MySQL at all. It's the next layer.

Valkey Object Caching: The Fix for Repeat Queries

Here's what happens without an object cache: every request, WordPress re-queries the same options, the same post metadata, the same term relationships. The queries are individually fast, but there are dozens of them per page, and they're identical from one request to the next. A persistent object cache stores those results in memory, so request number two skips most of the database work entirely.

Valkey, the open-source Redis fork that emerged after the 2024 license change, speaks the Redis protocol, which means the standard Redis Object Cache plugin works against it without modification. Point the plugin at Valkey and WordPress can't tell the difference.

Setup with wp-cli takes a minute:

wp plugin install redis-cache --activate

wp config set WP_REDIS_HOST 127.0.0.1
wp config set WP_REDIS_PORT 6379
wp config set WP_CACHE_KEY_SALT "example.com:"

# Drops the object-cache.php drop-in into wp-content
wp redis enable

# Verify
wp redis status

The WP_CACHE_KEY_SALT line matters when multiple sites share one Valkey instance: it namespaces keys so sites can't collide. After enabling, check your MySQL query count per page. On plugin-heavy sites the drop is dramatic, and it's the single highest-leverage change on this whole list for logged-in and dynamic traffic, because it's the one cache layer that helps even when full-page caching can't.

How Do the Caching Layers Fit Together?

A well-configured WordPress server runs four distinct caches, and confusing them is how people end up "clearing the cache" five times without fixing anything. Each layer caches a different artifact, lives in a different place, and invalidates differently.

LayerWhat it cachesWhere it livesHow it invalidatesOPcacheCompiled PHP bytecodePHP-FPM shared memoryTimestamp check or FPM reload on deployObject cache (Valkey)Query results, options, transientsValkey memoryWordPress flushes affected keys on writesPage cache (fastcgi_cache)Full HTML responsesNginx cache path on diskTTL expiry, or explicit purge on publishCDNStatic assets, optionally HTMLEdge locations worldwideCache-Control headers, purge API

The mental model: OPcache saves compiling code, the object cache saves querying the database, the page cache saves running WordPress at all, and the CDN saves the request from reaching your server. They stack. A cache-miss on the page layer still benefits from the object cache underneath, which is why you want both rather than treating them as alternatives.

Page Caching with fastcgi_cache

For anonymous traffic, the fastest WordPress response is one where WordPress never runs. Nginx's fastcgi_cache stores the rendered HTML and serves repeat visitors directly, at static-file speed, with PHP-FPM completely out of the loop. This is what most managed WordPress hosts run under the marketing name for their "edge cache."

The config, with the bypass rules that make it safe:

# In the http context:
fastcgi_cache_path /var/cache/nginx/example levels=1:2
                   keys_zone=EXAMPLE:100m inactive=60m max_size=512m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# In the server block:
set $skip_cache 0;

# Never cache writes or query-string requests
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }

# Never cache admin, API, feeds, or auth pages
if ($request_uri ~* "/wp-admin/|/wp-json/|wp-login\.php|/feed/|sitemap.*\.xml") {
    set $skip_cache 1;
}

# Never cache for logged-in users, commenters, or active carts
if ($http_cookie ~* "wordpress_logged_in|wp-postpass|comment_author|woocommerce_cart_hash|woocommerce_items_in_cart") {
    set $skip_cache 1;
}

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.4-fpm-example.sock;

    fastcgi_cache EXAMPLE;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache_use_stale error timeout updating http_500 http_503;
    add_header X-FastCGI-Cache $upstream_cache_status;
}

The cookie bypass is the line that keeps this safe. Logged-in users, people who just commented, and shoppers with items in a WooCommerce cart must always hit PHP, or you'll serve one visitor's personalized page to another. The X-FastCGI-Cache header gives you HIT, MISS, or BYPASS on every response, which makes verification a one-line curl check. And fastcgi_cache_use_stale is a quiet resilience win: if PHP-FPM crashes or times out, nginx serves the last known good page instead of an error.

One honest admission: invalidation is the weak spot. With a pure TTL approach, a published edit can take up to an hour to appear for anonymous visitors. You can wire up purge-on-publish with the nginx cache purge module and a helper plugin, but it's fiddly. Plugin-based page caches like WP Rocket or WP Super Cache are slower at serving but far simpler to invalidate, because they live inside WordPress and know when content changes. For a frequently edited site run by non-technical editors, that trade can genuinely favor the plugin. For mostly-read sites, fastcgi_cache wins comfortably.

Replace WP-Cron with Real Cron

WP-Cron is one of WordPress's oldest design compromises. Scheduled tasks don't run on a schedule; they run when a visitor happens to load a page. On a low-traffic site, that means scheduled posts publish late and backups fire whenever someone stumbles in. On a high-traffic site, it means WordPress checks the cron queue on a flood of requests, adding overhead exactly when you least want it, and long-running tasks can pile up concurrently.

The fix takes two minutes. Disable the pseudo-cron:

wp config set DISABLE_WP_CRON true --raw

Then let the actual operating system do its job. One system crontab entry, running as the site's user:

* * * * * cd /var/www/example.com/current && wp cron event run --due-now >/dev/null 2>&1

Every minute, wp-cli checks for due events and runs them, whether or not a single visitor showed up. Scheduled posts publish on time, cleanup jobs actually run, and page requests stop carrying scheduler overhead. Running it via wp-cli also means cron tasks execute in a proper CLI context with its own memory limit, so a heavy import job can't slow down a visitor's page load. There's no scenario where the default behavior is better than this. It's the first thing we'd change on any WordPress install.

How Do You Actually Secure a WordPress Server?

Start from an uncomfortable principle: on a single-tenant server without isolation, a WordPress compromise is a server compromise. PHP runs as the site user, so an attacker who gets code execution through a vulnerable plugin owns everything that user can touch. WordPress-specific hardening sits on top of general server hardening, not instead of it. We've written a full step-by-step server security audit covering the OS layer: firewall, SSH, fail2ban. Here's the WordPress-specific list.

Block xmlrpc.php Unless You Genuinely Need It

xmlrpc.php is a legacy API endpoint with two ugly properties: its system.multicall method lets attackers test hundreds of password guesses in a single request, sidestepping naive rate limits, and its pingback feature has been abused for traffic amplification against third parties. Almost nothing modern needs it. The REST API replaced it years ago. The deny all block in our nginx config above kills it at the edge, before PHP ever runs. The exceptions: Jetpack and some mobile or desktop publishing apps still use XML-RPC. If you need those, restrict access by source rather than leaving it open to the internet.

Rate-Limit wp-login.php

Credential stuffing against wp-login.php is constant background radiation for every WordPress site. The limit_req zone in the server block caps login attempts at one per second per IP with a small burst, which is invisible to humans and ruinous to dictionary attacks. Pair it with fail2ban watching for repeated 429s or auth failures, and with the boring advice that still matters most: unique strong passwords and two-factor authentication for every administrator account.

File Permissions and Configuration Hygiene

The web server user needs to read WordPress files, and WordPress needs to write to wp-content/uploads. It does not need write access to core files or wp-config.php during normal operation. Standard practice: directories at 755, files at 644, wp-config.php at 600, everything owned by the site user. Also rotate your salts and keys, the eight constants in wp-config.php, whenever you suspect a compromise or offboard an administrator: rotating them invalidates every existing login cookie instantly, which is exactly what you want after an incident. wp config shuffle-salts does it in one command.

Have an Auto-Update Policy, Not a Vibe

Automatic minor core updates are enabled by default and you should leave them on: minor releases are security releases, and the WordPress core team's track record shipping them safely is excellent. For plugins, blanket auto-updates are riskier because plugin quality varies wildly, but for a site nobody checks weekly, an auto-updated plugin that occasionally needs a fix beats an unpatched plugin that gets exploited. Our rule of thumb: auto-update everything on low-touch sites, and use a controlled staging workflow (below) on sites where an hour of breakage costs real money.

Backups: Database Plus wp-content, and an Actual Restore Drill

A WordPress site is exactly two things: the database, and the wp-content directory holding uploads, themes, and plugins. Core files don't need backing up, since wp core download recreates them bit-for-bit. So a complete backup is a mysqldump (or wp db export) plus an archive of wp-content, shipped off the server to S3-compatible storage. Backups that live on the same disk as the site are not backups; they're copies that die with the server. Our post on automated database backups covers scheduling, retention, and encryption in depth.

The part almost everyone skips: the restore drill. An untested backup is a hope, not a plan. Once a quarter, take a recent backup and restore it to a scratch server or a local environment. Import the database, unpack wp-content, run wp search-replace 'https://example.com' 'https://staging.example.com' to fix URLs, and click around. You're testing two things: that the backup is actually complete, and that you know the procedure well enough to execute it at 2 a.m. with adrenaline in your bloodstream. The first drill almost always surfaces a surprise. Better to find it on a calm Tuesday.

A Sane Update Workflow with wp-cli

The reason "WordPress updates" have a scary reputation is that most people test them in production. With wp-cli, a staging-first workflow is fast enough to be the default rather than a special occasion.

The loop looks like this:

# 1. Clone production to staging (db + wp-content), then fix URLs
wp db export prod.sql        # on production
wp db import prod.sql        # on staging
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid

# 2. Update everything on staging
wp core update
wp plugin update --all
wp theme update --all

# 3. Smoke test: homepage, login, checkout, forms, a recent post
# 4. Same commands on production, with a fresh backup taken first

The smoke test doesn't need to be elaborate. Load the homepage and confirm the layout isn't broken, log in to wp-admin, submit the contact form, and if it's a store, run a test checkout. Five minutes of clicking catches the large majority of update breakage, which overwhelmingly comes from plugins rather than core. When staging is clean, production gets the same updates the same day: sitting on known-vulnerable plugin versions because "updates are scary" is how most WordPress compromises actually happen. In our experience, teams that adopt this loop stop dreading updates within a month, because the workflow turns a gamble into a checklist.

When Do You Outgrow One Server?

Later than you'd think. A tuned 4 GB VPS with the full caching stack handles traffic that would embarrass a mid-tier managed plan, because cached pages cost nginx almost nothing to serve. But there are real signals, and there's a sensible order of operations when they appear.

First, offload media. wp-content/uploads grows forever, bloats backups, and pins your site to one machine's disk. Moving uploads to S3-compatible object storage with an offload plugin shrinks the server's footprint and makes the site closer to stateless, which simplifies everything that follows.

Second, put a CDN in front. Static assets served from edge locations cut your origin's bandwidth dramatically and improve load times for far-away visitors, and Cloudflare's free tier adds DDoS absorption that a lone VPS can't provide. Our guide to using Cloudflare with Deploynix walks through DNS, SSL modes, and cache rules.

Third, separate the database. Moving MySQL to its own server (or a managed database) frees the app server's RAM for PHP workers and page cache, and it's the prerequisite for running multiple app servers behind a load balancer later. Most sites never need that last step. The honest sequencing: exhaust caching first, then offload media, then CDN, then split the database. Horizontal scaling of WordPress itself is the final resort, not the first instinct, because each step before it is cheaper and solves a more common bottleneck.

Running This Stack on Deploynix

Everything above is exactly what we automate. WordPress is a first-class project type on Deploynix, not an afterthought bolted onto a generic PHP template. When you provision a WordPress site, the provisioner installs it via wp-cli, generates the admin credentials, and stores them encrypted in your dashboard, so there's no install wizard left exposed and no password pasted into a chat thread.

The server underneath is the stack from this post: nginx with the front controller pattern and static asset caching, PHP-FPM with per-site pools and per-site PHP versions (so your legacy client site can hold at 8.2 while new builds run 8.4), MySQL or MariaDB, and Valkey ready on the app server for the Redis Object Cache plugin. SSL certificates are issued and renewed automatically. Automated database backups ship to S3-compatible storage on your schedule, monitoring and alerts are included, and the security baseline (UFW firewall, fail2ban) is applied by default rather than left as an exercise. Per-site cron is managed from the UI, so the DISABLE_WP_CRON pattern from earlier is a form field instead of a crontab edit over SSH. It works the same on DigitalOcean, Vultr, Linode, Hetzner, AWS, or a custom server you bring yourself.

We built it this way because we host our own sites on it, and we wanted WordPress held to the same standard as our application code.

FAQ

Is PHP 8.4 safe for WordPress in 2026?

WordPress core, yes: it has been compatible with the PHP 8.x line for years and runs measurably faster on it than on the 7.x releases the official minimum still references. Plugins are the risk. Test your specific plugin set on a staging clone before switching production, and treat any plugin that fails on 8.4 as a candidate for replacement.

Do I need both an object cache and a page cache?

Yes, because they cover different traffic. The page cache serves anonymous visitors without running PHP at all, but it must bypass for logged-in users, commenters, and active carts. Those bypassed requests are exactly where the Valkey object cache earns its keep by eliminating repeat database queries. Together they cover both audiences; either alone leaves a gap.

Should I block xmlrpc.php on every site?

Block it unless you have a confirmed dependency. Jetpack and some mobile publishing apps still use XML-RPC; almost nothing else does, since the REST API replaced it. Its system.multicall method makes it a brute-force multiplier, so the safe default is deny all in nginx, loosened only for the specific services that need it.

Can Valkey really replace Redis for the object cache?

Yes. Valkey is protocol-compatible with Redis, and the standard Redis Object Cache plugin connects to it with the same WP_REDIS_HOST and WP_REDIS_PORT settings, no code changes required. WordPress has no idea which one is answering, and in our experience the swap is a non-event.

How big a server do I need for one WordPress site?

Smaller than the hosting industry suggests. With OPcache, Valkey, and fastcgi_cache configured, a 2 GB VPS handles a typical content site with ease, and 4 GB gives comfortable headroom for WooCommerce or several sites on one box. Uncached PHP capacity is what you're sizing for, so the caching stack matters more than the droplet size.

Where to Go from Here

The gap between a $30/month managed plan and a $10 VPS isn't the hardware, and it isn't magic. It's configuration: a correct nginx server block, a tuned PHP 8.4 pool, Valkey behind the Redis Object Cache plugin, fastcgi_cache with honest bypass rules, real cron, layered security, and backups you've actually restored. None of it is exotic. All of it is the same discipline any production application gets, applied to the CMS that runs 43% of the web and too often gets none of it.

Your next step: pick one site and replace WP-Cron with the system cron pattern from this post. It's a two-minute change, it's risk-free, and it'll make the rest of the stack feel approachable. If you're coming off shared hosting entirely, start with our migration guide and build from there, one layer at a time.

Enabling HTTP/2 and HTTP/3 for Your Laravel App: A Practical Nginx Guide

Deploynix — Sat, 19 Sep 2026 11:03:02 +0000

Open your Laravel app on a phone with two bars of signal and watch the network waterfall. On HTTP/1.1, the browser opens six TCP connections and queues everything else behind them. Your Vite bundle, your CSS, your fonts, and a dozen images line up single file, and every lost packet stalls its entire connection until TCP retransmits it. On HTTP/2, all of those requests share one connection and interleave cleanly. On HTTP/3, a lost packet delays only the one file it belonged to, and everything else keeps streaming. On a fast office connection the three waterfalls look nearly identical. On a lossy mobile connection they look like three different websites.

That gap is why the protocol under your app deserves an afternoon of your time. Google's original QUIC deployment paper reported an 8% reduction in mean search latency on desktop and a measurable improvement on mobile, with the biggest wins on the slowest connections (Google, SIGCOMM, 2017). Roughly a third of all websites now serve HTTP/3, and every major browser supports it (W3Techs, 2026). Meanwhile plenty of Laravel apps are still quietly serving HTTP/1.1 because nobody ever checked.

This guide covers what each protocol version actually fixed, what that means for a Laravel application specifically, how to verify HTTP/2 is really on, and the full HTTP/3 upgrade path for nginx on Ubuntu 24.04. We'll also cover the Cloudflare shortcut that gets you HTTP/3 with zero origin changes, and we'll be honest about where the gains are real and where they're rounding error.

What Did Each HTTP Version Actually Fix?

Each protocol revision attacked one specific bottleneck. HTTP/2 fixed request queuing at the application layer. HTTP/3 fixed packet loss stalls at the transport layer. Per Cloudflare's traffic data, HTTP/3 already accounts for roughly 30% of human browser traffic on their network (Cloudflare Radar, 2026), so this isn't speculative technology. It's what your visitors' browsers already prefer.

HTTP/1.1: One Request at a Time

HTTP/1.1 allows one outstanding request per connection. Browsers work around this by opening six parallel TCP connections per host, but a typical Laravel page with a JS bundle, CSS, fonts, and images needs far more than six resources. Everything beyond the first six waits in a queue. Each new connection also pays a full TCP and TLS handshake, which costs two to three round trips before a single byte of content moves.

HTTP/2: Multiplexing, With a Catch

HTTP/2 (2015) multiplexes every request over a single TCP connection as independent streams. The six-connection workaround disappears, header compression (HPACK) shrinks repetitive cookie and header data, and the browser can request 40 assets at once without queuing. For asset-heavy pages this was a genuine leap.

The catch is that TCP itself doesn't know about streams. TCP guarantees ordered delivery of one byte sequence, so when a single packet is lost, every stream on the connection stalls until that packet is retransmitted. This is transport-layer head-of-line blocking, and it's exactly the failure mode of lossy networks. Ironically, on a bad connection HTTP/2 can occasionally perform worse than HTTP/1.1, because 1.1's six separate connections meant a lost packet only stalled one sixth of the downloads.

HTTP/3: QUIC Replaces TCP

HTTP/3 (RFC 9114, 2022) keeps HTTP/2's semantics but swaps the transport. QUIC runs over UDP and implements its own reliability, congestion control, and encryption with TLS 1.3 built into the handshake. Three properties matter in practice. First, streams are truly independent: a lost packet delays only the stream it carried. Second, the combined transport and TLS handshake completes in one round trip, and session resumption supports 0-RTT, so a returning visitor's first request rides along with the handshake itself. Third, connections are identified by a connection ID rather than an IP and port pair, so a phone switching from Wi-Fi to cellular keeps its connection alive instead of reconnecting. That's connection migration, and it's a feature TCP simply cannot offer.

HTTP/1.1HTTP/2HTTP/3MultiplexingNo (browsers open ~6 parallel TCP connections)Yes, streams share one TCP connectionYes, independent QUIC streamsHead-of-line blockingYes, per connectionFixed at the HTTP layer, still present at the TCP layerEliminated; loss affects only its own streamTransportTCPTCPQUIC over UDPTLS requirementOptionalRequired in practice (no browser ever implemented cleartext h2c)Mandatory, TLS 1.3 onlyBrowser supportUniversalEffectively universal since 2015Chrome, Edge, Firefox, and Safari all support it

What Does This Mean for a Laravel App Specifically?

The protocol only accelerates the part of the page load it touches: moving bytes across the network. HTTP Archive data shows the median page now ships around 70 requests and over 2 MB of assets (HTTP Archive, 2025), and that asset transfer is where HTTP/2 and HTTP/3 earn their keep. Your PHP execution time doesn't change by a single millisecond.

Let's be specific about where each type of Laravel workload lands.

Asset-heavy pages benefit most. A marketing site, a Filament admin panel, or a Livewire app loading a Vite bundle, a CSS file, web fonts, and a grid of product images is exactly the multiplexing use case. Dozens of parallel resources over one connection, no queuing, and on mobile, loss recovery that doesn't stall the whole page.

API endpoints barely notice. A JSON API serving one request per round trip has nothing to multiplex. Mobile API clients get a small win from QUIC's faster handshake and connection migration, but if your endpoint takes 180ms of PHP time, the protocol is not your problem.

TTFB is still your PHP time. No protocol upgrade fixes a slow Eloquent query or an N+1 problem. If time-to-first-byte is your bottleneck, start with our 20 quick wins for Laravel performance and PHP-FPM tuning before touching the transport layer. In our experience, teams that jump straight to HTTP/3 while running unindexed queries are optimizing the wrong 5% of their load time.

The honest framing: on a low-latency wired connection, upgrading from HTTP/2 to HTTP/3 is usually a marginal, single-digit-percent improvement. On high-latency or lossy mobile networks, it's frequently visible to the naked eye. If your analytics show 60% mobile traffic, this upgrade is worth more to you than to a B2B dashboard used from office fiber.

Is HTTP/2 Actually Enabled on Your Server?

Before chasing HTTP/3, verify the boring prerequisite. HTTP/2 in nginx has been mature for a decade and most modern provisioning tools enable it, yet we still see hand-configured servers negotiating HTTP/1.1 over TLS because a vhost was copied from a 2014 tutorial. Since browsers never implemented cleartext HTTP/2, it only works on your TLS-enabled vhosts, which is one more reason every site should have a certificate (our complete guide to SSL on Deploynix covers that end to end).

The Modern Directive Form

Nginx changed the syntax in 1.25.1. The old form put http2 on the listen line; that form still works but is deprecated and logs a warning. The current form is a standalone directive:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # ... your Laravel root, index, and PHP-FPM location blocks
}

If your config still says listen 443 ssl http2;, it works today, but move to http2 on; when you touch the file next. The old parameter form will eventually be removed.

Verifying It

Three quick checks, from fastest to most thorough:

# Ask curl which protocol it negotiated (expect "2")
curl -sI --http2 -o /dev/null -w '%{http_version}\n' https://example.com

# Confirm the config actually loaded
sudo nginx -T | grep -E 'http2|listen 443'

The third check is your browser. Open DevTools, go to the Network tab, right-click the column headers, and enable the Protocol column. Load your site and look for h2 next to your document and assets. This column becomes your best friend again in the HTTP/3 section, where you're looking for h3.

While you're in the vhost, it's a good moment to review the rest of your server block. Our guide to nginx configs that actually matter for Laravel covers gzip, static caching, and worker tuning, all of which compound with the protocol upgrade.

How Do You Enable HTTP/3 in Nginx on Ubuntu 24.04?

Here's the part that trips people up: Ubuntu 24.04's distro nginx is version 1.24, and QUIC support landed in the 1.25.x line before flowing into the current stable releases. The nginx that apt install nginx gives you on a stock 24.04 box cannot speak HTTP/3 no matter what you put in the config. You need nginx from the official nginx.org repository (or a newer distro line), and the binary must be compiled with the http_v3_module. The official docs live at nginx.org/en/docs/quic.html and are worth a read alongside this section.

The good news: this is a low-risk change. HTTP/3 discovery is advertisement-based, so if QUIC fails for any reason, browsers silently fall back to HTTP/2. You can't take your site down by getting HTTP/3 wrong; the worst case is that nobody uses it.

Step 1: Install Nginx From the Official Repo

sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
    | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
http://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

sudo apt update
sudo apt install nginx

One caution from experience: the nginx.org package lays out configuration differently from Ubuntu's package. It uses /etc/nginx/conf.d/*.conf and has no sites-available / sites-enabled convention. Back up /etc/nginx before upgrading, and be prepared to either add an include /etc/nginx/sites-enabled/*; line to nginx.conf or move your vhosts into conf.d. Do this in a maintenance window the first time.

Step 2: Confirm the Binary Has the Module

nginx -v
# any current nginx.org stable or mainline (1.25+) has QUIC support

nginx -V 2>&1 | grep -o http_v3_module
# http_v3_module

If that grep prints nothing, your binary can't do HTTP/3, full stop. The official nginx.org packages include the module; some third-party builds don't.

Step 3: Add the QUIC Listener and Alt-Svc Header

HTTP/3 runs alongside HTTP/2, not instead of it. Every browser's first visit arrives over TCP and negotiates h2. Your server then advertises HTTP/3 availability with an Alt-Svc response header, and the browser remembers it (for ma seconds, here 24 hours) and uses QUIC for subsequent requests. That's the discovery mechanism, so the header isn't optional decoration. Without it, nobody ever finds your QUIC listener.

server {
    # HTTP/3 over QUIC (UDP)
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    # HTTP/2 over TCP (first visits and fallback)
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # QUIC requires TLS 1.3; keep 1.2 for the TCP listener
    ssl_protocols TLSv1.2 TLSv1.3;

    # Advertise HTTP/3 to browsers; "always" includes error responses
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    root /var/www/example.com/current/public;
    index index.php;

    # ... your usual Laravel location blocks
}

Two details deserve emphasis. QUIC mandates TLS 1.3 (RFC 9001), so TLSv1.3 must be in your ssl_protocols line; your existing Let's Encrypt certificates work unchanged. And reuseport may appear on only one server block per address-and-port combination. If you host multiple sites on the server, put reuseport in your default vhost and use plain listen 443 quic; in the others, or nginx will refuse to start with a "duplicate listen options" error. That error appears at nginx -t time, which is exactly why you always test before reloading.

sudo nginx -t && sudo systemctl reload nginx

Step 4: Open UDP 443 in the Firewall

This is the most common reason HTTP/3 "doesn't work" after a textbook-perfect config. QUIC runs over UDP, and your firewall almost certainly allows only TCP on 443. On a UFW-managed server:

sudo ufw allow 443/udp
sudo ufw status

You should see 443/udp ALLOW alongside the existing 443/tcp rule. If a cloud provider firewall or security group sits in front of the box (DigitalOcean Cloud Firewalls, AWS security groups, Hetzner firewalls), add UDP 443 there too. Every layer between the browser and nginx must pass UDP.

Step 5: Verify End to End

# If your curl is built with HTTP/3 support:
curl --http3 -sI https://example.com -o /dev/null -w '%{http_version}\n'
# 3

# Stock Ubuntu curl usually lacks HTTP/3; at minimum confirm the advertisement:
curl -sI https://example.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

Then the real-world check: open the site in Chrome or Firefox with the DevTools Protocol column enabled, load the page, and reload it once. The first load shows h2 (that's the discovery visit), and the reload should show h3 on the document and assets. If DevTools stubbornly shows h2 on reloads, the diagnosis order is: Alt-Svc header present, UDP 443 open at every layer, http_v3_module compiled in, and no VPN or corporate proxy on your test machine eating UDP.

Rollback Safety

Worried about shipping this on a production box? Here's the reassuring part. Because discovery happens via Alt-Svc and browsers fall back to HTTP/2 within milliseconds when QUIC doesn't respond, disabling HTTP/3 is as simple as removing the quic listen lines and the Alt-Svc header, then reloading nginx. Visitors who cached the advertisement quietly return to h2. No downtime, no stuck clients, no cache purge. We've found this makes HTTP/3 one of the lowest-risk infrastructure changes you can make: the failure mode is "nothing improved," not "the site broke."

Should You Run HTTP/3 at the Origin or at the CDN Edge?

There are two legitimate places to terminate HTTP/3, and they aren't competing. Cloudflare enabled HTTP/3 by default years ago and now serves it for a very large share of eligible traffic (Cloudflare, 2023), which means a huge fraction of the sites your users visit already do HTTP/3 at the edge with an HTTP/2 origin behind it. That architecture is completely legitimate: browsers talk h3 to the nearest edge node, and the edge talks h2 to your nginx over a warm, long-lived connection. Zero origin changes required.

CapabilityOrigin nginxCDN edge (Cloudflare in front)HTTP/2 to visitorsYes (http2 on;)Yes, by defaultHTTP/3 to visitorsRequires nginx 1.25+, config, and UDP 443 openOne dashboard toggle, zero origin changesEdge-to-origin legNot applicable (direct connection)Typically HTTP/2 over a persistent connectionStatic asset proximityYour server's region onlyHundreds of PoPs near the visitorCached asset TTFBFull round trip to your serverServed from the edge, origin untouchedWho terminates TLSYour serverThe edge (plus a cert on your origin)Effort and riskRepo migration, config, firewallMinutes, trivially reversible

Option 1: HTTP/3 at the Origin

Strengths: No third party in the request path, no extra DNS changes, full control over TLS configuration and QUIC tuning, and end-to-end HTTP/3 for every request including uncached dynamic pages. Your Laravel HTML responses themselves ride QUIC, not just static assets.

Best for: Teams that don't want a proxy in front of their app, apps with strict data-path requirements, latency-sensitive dynamic traffic to a single region, and anyone who values understanding their full stack.

Considerations: You own the nginx.org repo migration, the config-layout differences, and the firewall rule on every server. Your origin is still one physical location, so a visitor in Sydney hitting a server in Frankfurt pays the full round trip regardless of protocol.

Option 2: HTTP/3 at the Cloudflare Edge

Strengths: HTTP/3 for all visitors in about two minutes, with your origin staying on plain HTTP/2. You also pick up edge caching for static assets, which usually moves the performance needle more than the protocol itself, plus DDoS absorption. Distance is the dominant latency factor, and edges are simply closer.

Best for: Anyone already using Cloudflare, teams that want the win without touching servers, and globally distributed audiences hitting a single-region origin. Our Cloudflare with Deploynix guide walks through the full setup including SSL modes.

Considerations: A proxy now sits in the request path, so you'll want correct real-IP restoration for Laravel's rate limiting and logs. The edge-to-origin leg stays h2, which is fine in practice but means "HTTP/3" applies to the visitor-facing half. And you're adding a dependency you don't operate.

Running both is also reasonable: h3 at the edge for visitors, h3 at the origin for the day you route traffic directly. But if you only do one, and Cloudflare is already in front of your site, the edge toggle delivers 90% of the benefit for 2% of the effort.

How Do You Measure Whether It Helped?

Measure on the networks where the protocol matters, or you'll conclude it does nothing. Synthetic benchmarks against localhost or same-datacenter VMs are the classic mistake: with sub-millisecond RTT and zero packet loss, HTTP/1.1, 2, and 3 produce nearly identical numbers, because the problems these protocols solve don't exist on that link. WebPageTest's own documentation recommends testing under realistic mobile profiles precisely because throttled RTT and loss expose the differences that clean lab links hide (WebPageTest Docs, 2025).

A methodology we've found reliable:

Pick two or three real pages, not a synthetic endpoint. Your homepage, your heaviest dashboard, and one asset-rich content page.
Test before the change. Run WebPageTest with a 4G or 3G mobile profile from a location far from your server, nine runs, take the median. Save the waterfall.
Ship HTTP/3, confirm h3 in DevTools, then re-run the identical test. Alt-Svc caching means WebPageTest's repeat-view runs are the ones most likely to use h3.
Compare waterfalls, not scores. Look at connection setup time, asset download overlap, and total load time. A Lighthouse performance score can hide a 300ms network win behind unchanged PHP TTFB.
Watch real-user data for two weeks. If you collect Core Web Vitals via RUM, segment LCP by connection type. The improvement concentrates in your worst-connected cohort, which averages hide.

Expect an honest result to look like this: TTFB roughly unchanged (that's PHP, remember), first-visit connection setup slightly faster, repeat-visit and lossy-network loads noticeably better, and desktop-on-fiber essentially flat. If you want to understand what your server can do under load once the network layer is sorted, our load test of a $5 server shows the methodology for the capacity side of the equation.

What Are the Gotchas?

A few sharp edges are worth knowing before you flip anything on. None are dealbreakers, but each has cost someone an afternoon.

Some Networks Block QUIC Entirely

Corporate firewalls and some middleboxes drop or block UDP 443, either deliberately (so their inspection appliances can read TLS-over-TCP) or by default-deny policy. Estimates vary, but a persistent single-digit percentage of networks can't complete QUIC connections. This is precisely why the Alt-Svc fallback design matters: those users transparently stay on HTTP/2 and never notice. Don't fight it, and never build anything that assumes h3 is available.

UDP Amplification and Abuse

Any UDP service invites reflection and amplification questions. QUIC's design caps how much a server may send to an unvalidated address (about three times the bytes received), which limits amplification at the protocol level. If your server faces hostile traffic, nginx's quic_retry on; adds an extra address-validation round trip that forces clients to prove they own their source IP before the server commits resources. It costs new connections one RTT, so enable it under attack rather than by default. Standard nginx rate limiting still applies to the requests themselves, exactly as it does over TCP.

WebSockets Stay Where They Are

Running Laravel Reverb? WebSockets bootstrap through an HTTP/1.1 Upgrade (or HTTP/2 extended CONNECT), and the HTTP/3 equivalent, WebTransport, is a different protocol that Reverb doesn't target. In practice your Reverb connections continue negotiating over h1/h2 exactly as before, and that's fine. HTTP/3 on the same vhost doesn't interfere with them. Nothing to change, nothing to worry about.

0-RTT Is Opt-In for a Reason

QUIC session resumption supports 0-RTT, where a returning client sends its first request inside the handshake. Nginx keeps early data off unless you enable ssl_early_data on;, because 0-RTT requests can be replayed by an attacker. If you enable it, ensure replayed GETs are harmless (they should be, if your GETs are idempotent like the HTTP spec assumes). Skipping 0-RTT entirely costs you one round trip on resumption and zero risk. That's a fine trade.

The reuseport Constraint on Multi-Site Servers

Mentioned above, but it bites often enough to repeat: reuseport on the quic listener may appear exactly once per port across your entire config. On a server hosting six sites, five of them need listen 443 quic; without the parameter. nginx -t catches it, which is one more reason to never reload without testing.

How This Works on Deploynix

Every site Deploynix provisions gets nginx with a free Let's Encrypt certificate, and TLS-enabled vhosts ship with HTTP/2 already on using the modern http2 on; directive. So the first half of this guide is a verification exercise for Deploynix users rather than a setup task: open DevTools, confirm h2, done. The same applies whether your server runs on DigitalOcean, Hetzner, Vultr, Linode, AWS, or a custom box.

For HTTP/3 at the origin, the pieces you need are accessible without leaving the dashboard. Firewall rules are manageable per server, so adding the UDP 443 rule is a form field instead of an SSH session, and the vhost configs are editable if you want to add the quic listeners and Alt-Svc header after installing a QUIC-capable nginx build. The nginx.org repo migration itself is still a hands-on step today; it changes a system package, and we'd rather you do that deliberately in a maintenance window than have a platform do it silently.

The path we recommend to most users, though, is the edge route: put Cloudflare in front of your Deploynix site, and your visitors get h3 at the edge with zero origin changes, while your origin keeps its Deploynix-managed HTTP/2 and Let's Encrypt setup untouched. If you're running the load balancer server type, the same logic applies, since the balancer terminates SSL and speaks HTTP/2 to visitors while Cloudflare handles h3 in front. Server monitoring keeps an eye on the origin either way, and the protocol change is invisible to your deploys.

FAQ

Does HTTP/3 require new SSL certificates?

No. QUIC requires TLS 1.3, but your existing certificates work unchanged, including the free Let's Encrypt certificates Deploynix issues. Certificates authenticate your domain regardless of transport. The only TLS-related config change is confirming TLSv1.3 appears in your ssl_protocols directive, which it already does in any modern config.

Will enabling HTTP/3 break anything if it fails?

Practically no. Discovery works through the Alt-Svc header, so browsers try QUIC only after a successful HTTP/2 visit, and they fall back to HTTP/2 within milliseconds if UDP is blocked or the listener misbehaves. The realistic worst case is that HTTP/3 goes unused. Rollback is deleting two listen lines and one header, then reloading nginx.

Why does my Ubuntu 24.04 server refuse the quic directive?

Because the distro ships nginx 1.24, which predates QUIC support in the 1.25.x line. You need nginx from the official nginx.org repository or another QUIC-capable build, compiled with the http_v3_module. Verify with nginx -V 2>&1 | grep http_v3_module; if it prints nothing, no config change will help.

Is HTTP/2 to my origin plus HTTP/3 at Cloudflare a real setup or a hack?

It's a real, widely deployed architecture. Visitors speak h3 to the nearest edge, and the edge maintains warm HTTP/2 connections to your origin, where transport-level loss barely exists on datacenter links. Cloudflare serves an enormous share of the web's HTTP/3 this way (Cloudflare, 2023). Most sites should start here.

How much faster will my Laravel app actually be?

Honest answer: it depends on your audience's networks. Google's QUIC deployment measured around 8% latency improvement on search at internet scale (Google, SIGCOMM, 2017), with larger gains on poor connections. Expect visible improvement for mobile users on asset-heavy pages, near zero for wired API clients, and no change at all to your PHP TTFB.

Where to Go From Here

The protocol stack under your Laravel app is one of those things you configure once and benefit from on every request afterward. Verify HTTP/2 today; it takes one curl command and there's a real chance an old vhost is quietly serving HTTP/1.1. Then pick your HTTP/3 lane based on effort tolerance: the Cloudflare toggle if you want the win this afternoon, or the nginx.org path from Step 1 above if you want it end to end at the origin. Either way the fallback behavior makes it a low-stakes experiment with a real upside for your worst-connected visitors.

A good first check: open DevTools on your production site, enable the Protocol column, and see what your app is actually serving. If the answer surprises you, you now have the complete playbook. And once the transport layer is sorted, the bigger wins usually live one layer up, in the nginx configs covered in the optimization guide linked earlier.

Self-Hosting Next.js in 2026: The Complete VPS Guide for Teams Leaving Vercel

Deploynix — Thu, 17 Sep 2026 11:03:04 +0000

Every team that leaves Vercel can point to the exact invoice that did it. For months the bill sits at $20 per seat and nobody thinks about it. Then a launch goes well, image bandwidth spikes, function invocations climb, and the invoice jumps from $150 to $900 in a single billing cycle. The app didn't change. The pricing model did what pricing models do.

We've watched this play out repeatedly with teams migrating to our platform, and the pattern is consistent. The trigger is rarely a single outrageous bill. It's the realization that costs now scale with success in a way the team can't predict or cap. Meanwhile, the thing they're paying for, a Node.js server behind a CDN, has never been cheaper to run yourself. A $6-14/month VPS in 2026 can comfortably host a dozen containerized apps, and open-source tooling has largely closed the deployment-UX gap that justified managed platforms in the first place (DigitalOcean's Vercel-alternatives roundup).

This guide is the complete migration path: when leaving makes sense (and when it doesn't), what you must replace item by item, the standalone build, the nginx layer, ISR caching on a single box, atomic deploys with rollback, and the scaling path beyond one server. It's written by people who run this stack in production, not from a pricing page.

Key Takeaways- Self-hosting Next.js makes sense for steady-traffic, bandwidth-heavy, or compliance-bound apps; less so for edge-function-heavy stacks. - output: 'standalone' produces a self-contained server.js you run under a process manager behind nginx. - Vercel Enterprise contracts run a median of roughly $45,000/year (makerkit); a capable VPS costs under $200/year at the time of writing. - ISR cache persistence and image optimization are the two details most migrations get wrong.

When Does Leaving Vercel Make Sense?

The honest answer: when your costs have become predictable in the wrong direction. If you can look at your traffic graph and your Vercel invoice and draw a straight line between them, self-hosting converts a variable cost into a fixed one. Vercel Enterprise contracts run a median of roughly $45,000 per year, which is exactly why regulated and cost-sensitive teams keep landing on self-hosting (makerkit's Next.js hosting guide).

Four situations make the move clearly worthwhile:

Steady, predictable traffic. Vercel's elasticity is valuable when your traffic is spiky and unpredictable. If your app serves roughly the same audience every day, you're paying an elasticity premium for elasticity you don't use. A fixed-size VPS handles fixed-size traffic at a fixed price.

Bandwidth-heavy workloads. Image galleries, video-adjacent apps, file downloads, anything where egress dominates. Platform bandwidth pricing is where invoices go vertical. On a VPS, providers like Hetzner include 20 TB of traffic on plans that cost less than a lunch, at the time of writing.

Data residency and compliance. If your contracts or regulators require data to live in a specific country, or you need to answer "where exactly does this run?" with a server you control, a VPS in the right region is the simple answer. We covered the same dynamic for backend teams in our piece on cloud repatriation from AWS to a $10 VPS, and the logic transfers directly to frontend hosting.

Cost ceilings. Some teams simply need a number that cannot surprise them. A VPS bill is that number.

When It Doesn't Make Sense

Be equally honest about the other side. If your app leans heavily on Vercel-specific edge primitives, dozens of edge functions, edge middleware doing per-request geo logic, edge config, you'll spend real engineering time rebuilding those behaviors, and the result will run in one region instead of hundreds. That trade can be a net loss.

And if you're a two-person team with zero appetite for operations, think hard. Modern tooling has made self-hosting dramatically easier, but "easier" is not "zero." Someone still owns the server. If nobody on the team wants that pager, even in its mild modern form, the Vercel premium is buying something real: the ability to never think about infrastructure. That's a legitimate purchase.

What Are You Actually Replacing?

Vercel is not magic. It's a well-integrated bundle of components, each of which has a self-hosted equivalent. Here's the honest mapping:

Vercel feature

Self-hosted equivalent

Effort

Serverless/edge functions

Node.js server routes behind nginx (API routes run in the same process)

Low for API routes, high for true edge logic

ISR / on-demand revalidation

Next.js file-system cache (persist .next/cache across releases) or a custom cache handler backed by Redis

Medium

Image optimization

next/image with sharp installed on the server, or offload to Cloudflare

Low

Preview deployments

Staging sites per branch (a second site on the same or another server)

Medium

Global edge network / CDN

Cloudflare (or another CDN) in front of your origin

Low

Automatic SSL

Let's Encrypt via certbot, or your platform handles it

Low

Analytics / Speed Insights

Self-hosted Plausible, Umami, or Sentry for performance

Low

Zero-config Git deploys

A deploy script or a platform like Deploynix pulling from Git

Low to medium

Two rows deserve emphasis because they're where migrations get sloppy: ISR cache persistence and image optimization. We'll spend full sections on both.

What You Lose, With No Sugarcoating

The one thing you cannot replicate on a single VPS is Vercel's global edge network. Your server lives in one region. A user in Sydney hitting your Frankfurt VPS pays a real latency tax on the first byte of every server-rendered page.

The standard mitigation is Cloudflare in front of your origin. Static assets, images, and cached HTML get served from Cloudflare's POPs worldwide, which recovers most of the perceived performance for most apps. Server-rendered, uncacheable pages still make the round trip to your origin. For a typical SaaS dashboard where users are concentrated in one or two regions, this is a non-issue. For a globally distributed content site with heavy SSR, it's a genuine trade-off you should measure before committing. We wrote up the full setup in using Cloudflare with Deploynix for CDN, DDoS protection, and SSL.

What Does It Actually Cost?

Numbers below are at the time of writing (August 2026) and assume a production app doing a few hundred thousand requests per month with moderate image traffic.

Item

Vercel Pro

Self-hosted VPS

Base platform

$20/seat/month

Compute

Included, then usage-billed

$12-24/month (2-4 vCPU VPS)

Bandwidth

1 TB included, ~$0.15/GB after

1-20 TB included with the VPS

Image optimization

Usage-billed after included quota

$0 (sharp) or $0 (Cloudflare free tier)

SSL

Included

$0 (Let's Encrypt)

Preview environments

Included

$0-12/month (staging site, optionally a second small VPS)

Analytics

Usage-billed add-on

$0-9/month (self-hosted Plausible/Umami)

Typical monthly total (5-person team)

$100-400+, usage-dependent

$15-40, fixed

The absolute numbers matter less than the shape. The Vercel column scales with usage and team size. The VPS column is flat until you deliberately resize it. For teams doing serious traffic, the gap widens: the median Vercel Enterprise contract of ~$45,000/year buys roughly two decades of a well-specced dedicated server.

What the table doesn't show is your time. Budget a day or two for the initial migration and an hour or two per month for maintenance (mostly unattended if you automate updates). If your loaded engineering cost makes those hours worth more than the savings, that's your answer, and it's a fine one.

How Do You Build Next.js for a VPS?

Next.js ships a build mode designed exactly for this: standalone output. Instead of requiring your full node_modules tree (often 500 MB+) on the production server, standalone mode traces exactly which files your server code actually imports and copies only those into .next/standalone, alongside a self-contained server.js.

Enable it in next.config.js:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
};

module.exports = nextConfig;

After next build, the .next/standalone directory contains everything needed to run the app: a minimal node_modules, your compiled server code, and server.js as the entry point. Two directories are deliberately excluded and must be placed manually: public/ and .next/static/. That exclusion is intentional, because the docs assume you'll serve those through a CDN or web server. We will, via nginx, in the next section.

Running the server is one command:

HOSTNAME=127.0.0.1 PORT=3000 NODE_ENV=production node server.js

Bind to 127.0.0.1, not 0.0.0.0. Nothing should reach the Node process except nginx on the same machine.

Pick a Node LTS and Pin It

Run the current LTS (Node 22 at the time of writing) and pin the major version in package.json engines and in your server provisioning. The failure mode you're avoiding: your CI builds on Node 22, your server runs Node 20, and you debug a native-module mismatch at 11 pm. Same major version everywhere, always.

The NEXT_PUBLIC_ Pitfall

This one bites almost every first migration, so read it twice. Next.js has two classes of environment variables:

Server-side variables (DATABASE_URL, API_SECRET) are read at runtime. Change them, restart the process, done.
NEXT_PUBLIC_* variables are inlined into the JavaScript bundle at build time. They are string-replaced into your client code during next build. Changing them on the server after the build does nothing.

On Vercel this distinction is invisible because every env change triggers a rebuild. On your VPS, it means NEXT_PUBLIC_ values must be present in the environment where next build runs, and changing one requires a new build, not a restart. Structure your deploy script accordingly, and resist the temptation to put anything in NEXT_PUBLIC_ that isn't truly public. It ships to every browser.

How Do You Keep the Process Running?

node server.js in a tmux session is not a production strategy. You need a process manager that starts the app on boot, restarts it on crash, and captures logs. Systemd works; PM2 works; we'll show Supervisor because its config is the most readable:

[program:nextjs-myapp]
command=/usr/bin/node server.js
directory=/var/www/myapp/current/.next/standalone
environment=NODE_ENV="production",HOSTNAME="127.0.0.1",PORT="3000"
user=deploy
autostart=true
autorestart=true
startretries=5
stopwaitsecs=10
stdout_logfile=/var/log/myapp/next.out.log
stderr_logfile=/var/log/myapp/next.err.log

Note the directory points at current/, a symlink we'll create in the deploy section. That symlink is the hinge that makes atomic releases work. Also note stopwaitsecs=10: Next.js handles SIGTERM gracefully, finishing in-flight requests before exiting, and you want to give it those seconds rather than SIGKILL-ing mid-request.

Runtime environment variables can live in the Supervisor stanza for simple setups, or in an env file loaded by a wrapper script for anything with secrets. Either way, they're runtime-only. The NEXT_PUBLIC_ values were already baked in at build time.

The nginx Layer: Where the Performance Lives

nginx sits in front of the Node process and does three jobs: TLS termination, reverse proxying dynamic requests, and serving static assets directly so Node never sees them. That last job matters more than people expect. Every request nginx answers from disk is a request your Node event loop doesn't handle.

Here's a production-ready server block:

server {
    listen 443 ssl http2;
    server_name myapp.com;

    ssl_certificate     /etc/letsencrypt/live/myapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem;

    client_max_body_size 25m;

    gzip on;
    gzip_types text/css application/javascript application/json image/svg+xml;
    gzip_min_length 1024;

    # Immutable build assets: serve from disk, cache for a year
    location /_next/static/ {
        alias /var/www/myapp/current/.next/static/;
        expires 1y;
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
    }

    location /public/ {
        alias /var/www/myapp/current/public/;
        expires 7d;
        access_log off;
    }

    # Everything else goes to the Node process
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 60s;
    }
}

A few deliberate choices worth explaining:

The **/_next/static/ location block** is the payoff for standalone mode's "bring your own static serving" design. Next.js fingerprints every file in that directory with a content hash, so the files are immutable by construction. max-age=31536000, immutable tells browsers to never revalidate them. Combined with Cloudflare in front, these assets get served from edge POPs and your origin barely sees them.

The Upgrade headers (proxy_http_version 1.1 plus the Upgrade/Connection pair) enable WebSocket passthrough. You need this for Next.js HMR if you ever proxy a dev server, and for any production WebSocket usage in the app itself. Leaving them out produces the classic symptom of connections that open and instantly die.

client_max_body_size 25m because nginx's 1 MB default will 413 your first file-upload feature and you'll spend an hour blaming Next.js.

If you want to go deeper on tuning, our guide to nginx configs that actually matter is Laravel-flavored but 80% of it, buffers, gzip levels, keepalive, applies unchanged here.

Enable brotli too if your nginx build includes the module; it compresses JS bundles 15-20% smaller than gzip. If it doesn't, don't recompile nginx just for this. Cloudflare applies brotli at the edge anyway.

How Does ISR Work on a Single Server?

Incremental Static Regeneration is the feature people assume won't survive off Vercel. It survives fine, with one operational detail you must get right.

Self-hosted Next.js implements ISR with a file-system cache in .next/cache. Rendered pages and their revalidation timestamps live there. revalidate intervals, on-demand revalidation via revalidatePath and revalidateTag, all of it works out of the box on a single Node process. No configuration required.

The detail that bites: the cache directory must persist across deploys. If every release ships a fresh .next/cache, you throw away every regenerated page on deploy. The first visitor to each page after a release eats a full render, and if you deploy often, ISR effectively stops existing. Worse, fetch() data cache entries vanish too, so your upstream APIs get hammered right after each deploy, exactly when you least want surprises.

The fix follows the same shared-storage pattern used in Capistrano-style deployments for years: keep the cache outside the release directory and symlink it in.

/var/www/myapp/
├── releases/
│   ├── 20260801121500/
│   └── 20260802093000/
├── shared/
│   └── next-cache/        # persists forever
└── current -> releases/20260802093000

Each release symlinks .next/cache (or specifically .next/cache/fetch-cache plus the ISR page cache, depending on your Next version) to shared/next-cache. Deploys swap the current symlink; the cache never moves. One caveat: after a build that changes a page's structure, Next's build ID changes and stale entries are ignored safely, so you don't need to invalidate manually.

If you later scale to multiple Node instances, the file-system cache stops being shared state, and you'll want Next's custom cacheHandler config pointed at Redis. On one server, the file system is simpler and fast. Don't add Redis before you need it.

What About Image Optimization?

next/image on Vercel silently uses their image optimization service, and it's a top-three source of surprise billing. Self-hosted, you have two good options.

Option one: optimize on the server. Install sharp as a production dependency (npm install sharp) and Next.js uses it automatically for on-the-fly resizing and WebP/AVIF conversion. Sharp is fast native code; a 2-vCPU VPS handles typical image workloads without drama. Optimized images land in that same .next/cache directory, which is another reason the shared-cache setup above matters.

Option two: offload to the CDN. If you're already putting Cloudflare in front (you should), Cloudflare's image resizing or simply caching your sharp-generated variants at the edge means each unique image size gets rendered on your origin exactly once, then served from POPs forever. For image-heavy sites this combination, sharp for generation, Cloudflare for delivery, gets you 95% of Vercel's image pipeline at a fixed cost.

One warning: configure images.remotePatterns in next.config.js strictly. An open image optimizer is a free resizing service for the entire internet, and people will find it.

Deploys: Atomic Releases, Zero Downtime, Rollback

This is where "run node on a VPS" becomes an actual production workflow. The requirements are simple to state: a deploy either fully succeeds or fully doesn't, users never see a half-deployed app, and rollback takes seconds.

The releases/current-symlink structure from the ISR section gives us all three. Here's a complete deploy script:

#!/usr/bin/env bash
set -euo pipefail

APP_DIR=/var/www/myapp
RELEASE=$(date +%Y%m%d%H%M%S)
RELEASE_DIR=$APP_DIR/releases/$RELEASE

# 1. Fetch code
git clone --depth 1 git@github.com:acme/myapp.git "$RELEASE_DIR"
cd "$RELEASE_DIR"

# 2. Build-time env (NEXT_PUBLIC_ vars must exist NOW, not later)
ln -sf $APP_DIR/shared/.env.build .env.production

# 3. Clean, reproducible install and build
npm ci
npx next build

# 4. Assemble the standalone runtime
cp -r public .next/standalone/public
cp -r .next/static .next/standalone/.next/static

# 5. Link the persistent ISR/image cache into the new release
rm -rf .next/standalone/.next/cache
ln -s $APP_DIR/shared/next-cache .next/standalone/.next/cache

# 6. Atomic switch: this line is the deploy
ln -sfn "$RELEASE_DIR" $APP_DIR/current

# 7. Graceful restart under the process manager
supervisorctl restart nextjs-myapp

# 8. Keep the last 5 releases for instant rollback
cd $APP_DIR/releases && ls -1t | tail -n +6 | xargs -r rm -rf

The atomicity lives in step 6. ln -sfn replaces the symlink in a single filesystem operation; there is no moment where current points at a half-built release. If the build fails at step 3, the script exits (set -e) and production never noticed a deploy was attempted.

Rollback is the same operation pointed backwards: ln -sfn to the previous release directory, restart, done. Under ten seconds, no rebuild.

The restart in step 7 causes a brief blip on a bare single process: Supervisor stops the old process gracefully, then starts the new one, so there's a window of a second or two where nginx gets connection refused. For most apps that's acceptable (nginx can even be configured to retry). For true zero-downtime you start the new process on an alternate port, health-check it, flip nginx's upstream, then drain the old one. That's the dance a deployment platform automates for you, and it's tedious enough by hand that it's usually the point where teams stop enjoying the DIY approach.

Preview Deploys Become Staging Sites

Vercel's per-PR preview URLs are genuinely excellent, and the self-hosted equivalent is more manual: a staging site. Same server (or a cheap second one), same deploy script pointed at a staging branch, staging.myapp.com in nginx, HTTP basic auth in front if the content is sensitive. You won't get a URL per pull request without building tooling for it. Most teams find one persistent staging environment plus local dev covers 90% of what they actually used previews for. Be honest with yourself about whether your team is in the other 10%.

Vercel vs. Self-Hosted: The Fair Comparison

Vercel

Strengths: The developer experience is the best in the industry, and that's not faint praise. Push to a branch, get a preview URL, merge, it's live globally in two minutes. The edge network is real infrastructure with real POPs, not marketing. Framework integration is perfect by definition, since the same company builds Next.js. Zero operational burden, ever.

Best for: Small teams with no ops appetite, spiky or unpredictable traffic, apps that genuinely exploit edge functions and middleware, agencies shipping many small sites, and anyone whose engineering time is worth far more than the hosting delta.

Considerations: Costs scale with usage and success, and the ceiling is high: Enterprise medians around $45K/year at the time of writing. Bandwidth and image optimization are the classic bill inflators. You're also accepting vendor coupling; features like edge config and their KV don't travel with you.

Self-hosted VPS

Strengths: Fixed, predictable cost that's often 5-10x lower at moderate scale. Full control: your nginx, your Node flags, your data location, your log retention. No usage anxiety. The stack (nginx + Node + a process manager) is boring, documented, twenty-years-mature technology that any Linux-literate engineer can debug at 2 am.

Best for: Steady traffic, bandwidth-heavy apps, data-residency requirements, cost-capped teams, and anyone already running a VPS for their backend who can co-locate the frontend. If you're pairing a Next.js frontend with a Laravel API, our walkthrough on deploying a Laravel API with a separate Next.js or Nuxt frontend covers that exact topology.

Considerations: You own the server: updates, monitoring, capacity. Single-region origin latency for far-away users (mitigated but not eliminated by Cloudflare). Preview environments are staging sites, not per-PR URLs. Edge-function-heavy apps need rearchitecting. The first migration costs a day or two of real engineering time.

Monitoring and the Scaling Path

Self-hosting without monitoring isn't self-hosting, it's gambling. The minimum viable setup: uptime checks on the public URL, process-level checks (is node server.js running, is memory stable), and disk/CPU/RAM alerts on the VPS itself. Next.js apps have one specific failure mode worth watching: slow memory growth from unbounded in-memory caching or leaky third-party SDKs. A memory graph with an alert at 85% catches it days before the OOM killer does.

The scaling path is refreshingly boring:

Vertical first. A standalone Next.js server is efficient; a 4-vCPU/8 GB VPS serves a surprising amount of SSR traffic. Resizing a VPS is a five-minute reboot. Our load-testing writeup on how much traffic a $5 server can actually handle used Laravel as the subject, but the headline finding, that small servers are wildly underestimated, applies at least as strongly to Node.
Cloudflare aggressively. Before adding servers, make sure cacheable responses are actually being cached at the edge. Many "we need to scale" moments are really "we're rendering the same page 10,000 times" moments.
Horizontal when vertical runs out. A load balancer in front of two or more Node instances. Here the ISR caveat returns: the file-system cache is per-machine, so two instances will regenerate pages independently and can serve briefly inconsistent versions. At this point, wire up Next's cacheHandler to Redis so all instances share one cache. This is the single biggest architectural difference between one server and several, and knowing it in advance makes the transition a config change instead of an incident.

Running Next.js on Deploynix

Everything above is exactly what Deploynix automates, so here's the concrete version of this guide on our platform. Next.js is one of 14 first-class project types (alongside Nuxt and SvelteKit for SSR), not a generic "Node app" you configure from scratch. When you create a Next.js site, it runs as a managed Node process with a sensible default start command and port, behind an nginx reverse proxy configured the way this article describes, static asset serving and proxy headers included.

Deploys pull from GitHub, GitLab, or Bitbucket and use the atomic release structure from the deploy section: zero-downtime switches, one-click rollback to a previous release, shared directories for cache persistence. SSL is free and automatic, monitoring and alerts are built in, and daemons and queue workers are managed the same way the Next process is, so a background job runner sits next to your app without hand-writing Supervisor stanzas. You bring the VPS from DigitalOcean, Vultr, Linode, Hetzner, AWS, or any custom server with root access; we provision it. When you outgrow one box, a load balancer is its own server type.

We built it because we got tired of maintaining the bash script above across a dozen servers. If you're coming from a managed platform, the mental model transfer is small; teams arriving from Railway, Render, or Fly.io will find the moving parts familiar, and we wrote a dedicated guide on migrating from Railway, Render, or Fly.io to a VPS covering that path.

FAQ

Do I lose ISR and on-demand revalidation by leaving Vercel?

No. ISR works out of the box in self-hosted Next.js via a file-system cache, including revalidatePath and revalidateTag. The one requirement is persisting .next/cache across deploys with a shared directory. On multiple servers, switch to a Redis-backed custom cache handler so instances share one cache.

What VPS size should I start with for a production Next.js app?

At the time of writing, a 2-vCPU/4 GB VPS ($12-24/month) comfortably runs a typical SSR app doing hundreds of thousands of requests per month, especially with Cloudflare caching in front. Start there, watch memory and CPU for two weeks, and resize vertically before considering anything more complex.

Can I keep using next/image without Vercel?

Yes. Install sharp as a production dependency and Next.js optimizes images on your server automatically. Put Cloudflare in front so each generated variant is cached at the edge and rendered only once. Lock down images.remotePatterns so strangers can't use your optimizer as a free service.

How do I replicate preview deployments?

The practical self-hosted equivalent is a persistent staging site: same deploy pipeline, staging branch, its own subdomain, basic auth if needed. Per-PR preview URLs are possible but require custom tooling. Most teams find one staging environment covers the real use case, which is "let a non-developer click through the change before merge."

Is a single-region VPS actually fast enough for global users?

For static assets and cacheable pages behind Cloudflare, yes, they're served from edge POPs regardless of where your origin lives. Uncached SSR requests pay the round trip to your region, typically 80-250 ms extra for far-away users. If most of your audience is in one or two regions, it's rarely noticeable. Measure with real-user monitoring before assuming either way.

Where to Go From Here

The short version of 3,000 words: leaving Vercel in 2026 is a well-trodden path, not a leap. The build (output: 'standalone'), the runtime (a process manager), the front door (nginx plus Cloudflare), and the deploys (atomic releases with a persistent cache) are all solved problems with boring, reliable answers. What you give up is a world-class DX and a global edge; what you get back is control and a hosting bill that never surprises you again. Whether that trade is right depends on your traffic shape and your team's ops appetite, and now you have the full picture to decide.

Your next step: run the numbers. Pull your last three Vercel invoices, put them next to a $24/month VPS, and price your own migration day honestly. If the math says move, spin up a test server, follow the build and nginx sections above against a staging domain, and see the whole stack working before you touch production DNS. The first deploy takes an afternoon. Every one after that takes a git push.

Expand-and-Contract: Safe Database Migrations for Zero-Downtime Laravel Deploys

Deploynix — Tue, 15 Sep 2026 11:03:02 +0000

Earlier this year we helped a team debug a deploy that should have been boring. They renamed users.name to users.full_name, updated every reference in the codebase, wrote a one-line migration with renameColumn(), and shipped. Their deploy pipeline was genuinely zero-downtime: new release directory, atomic symlink flip, graceful FPM reload. And yet their app returned HTTP 500 for roughly 40 seconds, right in the middle of business hours. Every request that touched a user record died with Column not found: 1054 Unknown column 'name'.

Nothing in their pipeline was broken. The migration ran before the symlink flipped, which meant the old release, the one still serving live traffic, spent 40 seconds querying a column that no longer existed. The deploy tooling did exactly what it promised. The migration was the problem, because it assumed code and schema change at the same instant. They never do.

That gap between "schema changed" and "code changed" is not a bug you can fix with better tooling. It's a structural property of any deploy that keeps serving traffic while it works. The only reliable answer is a discipline called expand-and-contract (sometimes "parallel change"): make every schema change in phases, so that every migration is compatible with both the release before it and the release after it. This post walks through the pattern end to end, with real Laravel migration code, two worked examples, the places where you can honestly skip the ceremony, and the guardrails that catch dangerous migrations before they reach production.

If you're new to zero-downtime deployment itself, our primer on what zero-downtime deployment is and why your Laravel app needs it covers the foundations. Here we're going one layer deeper, into the part of the deploy that atomic symlinks can't protect: your database.

Why Does "Just Run the Migration" Break Under Zero-Downtime Deploys?

A zero-downtime deploy never stops serving traffic, which means there is always a window where two versions of your application coexist against one database. Either the new schema serves old code (migrations run before the release flips) or the old schema serves new code (migrations run after). There is no ordering that avoids the overlap entirely.

Here's the timeline for a typical release-directory deploy, the same sequence we described in the anatomy of a zero-downtime deploy:

TimeDeploy stepCode serving trafficSchema in the databaseT+0sNew release directory created, code clonedOld releaseOldT+4scomposer install, config cachedOld releaseOldT+9s*Migrations run* (deploy hook)Old releaseNewT+14sSymlink flips to new release, FPM reloadsNew releaseNewT+14s onwardIn-flight requests on old workers drain*Old release (briefly)*New

Look at T+9s through the drain window. The old release is live against the new schema for several seconds, longer if migrations are slow, and longer still on multi-server fleets where the flip isn't perfectly simultaneous. If your migration removed or renamed anything the old code reads, every one of those requests fails.

Flip the ordering and you trade one problem for another. Run migrations after the symlink flip, and new code briefly runs against the old schema, crashing on columns that don't exist yet. Queue workers make the window wider: a worker mid-job during the deploy finishes that job on old code, against whatever schema exists at that moment.

Rollback makes the asymmetry worse. Code rollback is instant, the symlink just points back at the previous release. Schema rollback is not. migrate:rollback in a panic, against live traffic, on a table that just got rebuilt, is how small incidents become large ones. So the practical rule falls out naturally: every migration must be safe to run while the previous release is still serving traffic, and every release must run correctly against the next release's schema. One release of compatibility, in both directions. Expand-and-contract is just the systematic way to satisfy that rule.

Which Migration Operations Are Actually Dangerous?

Most migrations are fine. Adding a nullable column, adding a table, adding most indexes: old code ignores what it doesn't know about, and nothing breaks. The danger is concentrated in a small set of operations that change or remove something the running release depends on.

OperationWhy it breaks live trafficExpand-and-contract alternative*Rename a column or tableOld code still selects and writes the old name. Every query touching it fails the moment the migration commits.Add the new column, dual-write from code, backfill, flip reads, drop the old column in a later release.Drop a column or tableOld code (and cached SELECT * expectations, serialized queue jobs, in-flight requests) still references it.Stop referencing it in release N. Drop it in release N+1, once nothing running can touch it.Change a column typeThe ALTER often rebuilds the table (locks, replication lag), and old code may write values invalid under the new type, or read values it can't handle.Add a new column with the new type, dual-write, backfill, flip reads, drop the old column later.Add NOT NULL to an existing columnOld code inserts rows without that column and hits a constraint violation instantly. On Postgres, SET NOT NULL also takes an ACCESS EXCLUSIVE lock while it scans the table.Add the column nullable, dual-write, backfill, then enforce NOT NULL only after every writer populates it (using CHECK ... NOT VALID then VALIDATE on Postgres).Add a unique index to a big table*The build can lock writes, and old code may insert duplicates mid-build, failing the migration.Deduplicate first, then build the index without blocking writes: CREATE INDEX CONCURRENTLY on Postgres, ALGORITHM=INPLACE on MySQL.

A note on engine behavior, because "it's fast on my machine" hides real differences. MySQL 8 performs many ALTER TABLE operations as INSTANT or INPLACE: adding a nullable column at the end of a table is metadata-only and effectively free at any table size. But type changes and some NOT NULL additions still require a full table rebuild (ALGORITHM=COPY), which on a 50-million-row table means minutes of load and replication lag even when it technically doesn't block reads. Postgres gives you transactional DDL, which is a genuine safety net for failed migrations, but ALTER TABLE still takes an ACCESS EXCLUSIVE lock. A lock that waits behind one long-running query will queue every other query behind it, and a "fast" migration turns into a site-wide stall. Fast DDL is not the same as safe DDL.

What Is the Expand-and-Contract Pattern?

The pattern splits one breaking change into three non-breaking phases, shipped across separate releases. At no point does any deployed release depend on schema that the adjacent release can't tolerate.

Phase 1: Expand

Add the new thing without touching the old thing. New nullable column, new table, new index. Deploy code that writes to both old and new locations but still reads from the old one. This release is compatible with the old schema (the new column is nullable, so old rows are fine) and with the old code (which simply ignores the new column). Nothing can break, in either direction, including a rollback.

Phase 2: Migrate

Backfill existing rows from old to new, in chunks, from a queued command, never inside the migration itself. A migration that loops over 10 million rows holds your deploy hostage and, on some setups, times out halfway through with no clean resume point. Once the backfill completes and you've verified parity, flip reads to the new column. Gate the flip behind a config check or a feature flag if you want a kill switch; we covered that mechanism in rolling out changes safely with Laravel Pennant. Keep dual-writing. That's what makes this phase reversible.

Phase 3: Contract

Only when no deployed release reads or writes the old column, remove it. This is its own release, deliberately boring. The drop is safe precisely because releases N and N-1 both ignore the column. If you're tempted to fold the contract migration into the same release that flips reads, resist it: that's the exact shortcut that turns a rollback into an incident.

Three phases, three releases, minimum. It feels slow the first time. It stops feeling slow the first time a Phase 2 release gets rolled back at 5 p.m. and nothing happens, because the schema was compatible in both directions by construction.

Worked Example: Splitting `users.name` Into `first_name` and `last_name`

Let's do the exact change that burned the team in the intro, done properly. Goal: replace the single name column with first_name and last_name.

Release 1: Expand and dual-write

The migration adds the new columns, nullable, so existing rows and old code need no changes:

php

Do You Need Laravel Horizon? Plain Workers vs. Horizon in Production

Deploynix — Sun, 13 Sep 2026 11:03:04 +0000

There are two kinds of Laravel teams, and both are running on autopilot. The first kind runs composer require laravel/horizon on every new project, before a single job class exists, because that's just what you do. The second kind has been running php artisan queue:work under Supervisor for years and has never once stopped to ask whether they're missing anything. Both are unexamined defaults. Both camps are sometimes wrong.

Horizon is not "queues, but better". It's a specific tool that trades a hard Redis-protocol requirement and some real operational overhead for two things: visibility into your queue system, and load-based balancing of your worker pool. Whether that trade pays off depends on your queue driver, your queue topology, and, honestly, whether anyone on your team will ever open the dashboard after week two.

We've configured queue workers for a lot of Laravel apps, from single-server side projects on the database driver to dedicated worker fleets chewing through webhook storms. The pattern we keep seeing is that the Horizon decision is rarely made on the merits. So in this guide we'll lay out what plain workers already give you (it's more than most people think), what Horizon concretely adds and what each addition costs, and a decision framework that ends with an actual verdict for your situation. Not "it depends". A verdict.

What Do Plain Queue Workers Already Give You?

Here's the part the Horizon-by-default crowd tends to forget: queue:work is not the budget option. It's the same worker loop Horizon itself runs under the hood. Almost everything people credit to Horizon, retries, backoff, timeouts, failure handling, is core Laravel queue behavior that you get with zero extra packages.

A plain worker on any driver gives you automatic retries with --tries, exponential or fixed backoff via --backoff or a backoff() method on the job, per-job timeouts, and a failed_jobs table that captures the full exception and payload when a job exhausts its attempts. You can retry failed jobs from the CLI with queue:retry, inspect them with queue:failed, and prune them on a schedule.

Priority handling works too, and it's simpler than people expect. Pass a comma-separated queue list and the worker drains them strictly in order:

[program:app-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan queue:work redis --queue=payments,default,emails --sleep=3 --tries=3 --backoff=10 --max-time=3600
autostart=true
autorestart=true
user=deploynix
numprocs=4
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/worker.log
stopwaitsecs=120

That stanza gives you four workers that always check payments first, then default, then emails. Want more throughput on one queue? Add a second program block with numprocs=8 pinned to that queue alone. Per-worker tuning of memory limits, sleep intervals, and PHP versions is all right there in the command line. And critically, this works on every queue driver Laravel supports: database, Redis, Valkey, SQS, Beanstalkd. We covered the driver and retry mechanics in depth in our Laravel queues deep dive, and none of it requires Horizon.

What Plain Workers Don't Give You

So what's actually missing? Four things, and they're all about observation and adaptation rather than execution.

First, visibility. With plain workers, your window into the queue is redis-cli llen, database queries, or log grepping. There's no answer to "what's our p95 wait time on the exports queue" without building it yourself. Second, load-based balancing. Your numprocs allocation is static. If emails is empty and webhooks is drowning, those email workers sit idle. Third, tag-based search. Finding every job related to customer #4182 across pending, processing, and failed states is a manual archaeology project. Fourth, one-click retry from a UI, which matters more than it sounds when a non-CLI teammate is on support duty.

Strengths: Runs on any queue driver. Dead simple mental model: Supervisor keeps N processes alive, each process runs jobs. No extra package to update, no dashboard to secure, no extra memory overhead. Static allocation is predictable capacity planning.

Best for: Single-queue apps, database-driver apps, teams that alert on symptoms (queue depth, oldest-job age) rather than watching dashboards, and anyone who values fewer moving parts over richer tooling.

Considerations: Zero built-in observability. Worker allocation can't adapt to shifting load between queues. Operational queue questions get answered with ad-hoc CLI spelunking, usually during an incident, which is the worst time to be writing Redis commands from memory.

What Does Horizon Actually Add?

Horizon is a supervisor for your workers and a dashboard for your queues, in one package. Understanding the first half is the key to understanding its ops model: you don't run one Supervisor process per worker anymore. You run exactly one horizon process, and Horizon forks and manages its own pool of child workers according to your config. Supervisor watches Horizon; Horizon watches everything else.

That inversion is what makes the features possible. Because Horizon owns the pool, it can resize it. Let's go feature by feature, with the cost attached to each.

The dashboard. Real-time throughput, per-queue wait times, job runtime distributions, failed job details with full stack traces and payloads. Cost: it's a route in your app that must be auth-gated in production (more on that below), and the metrics have retention limits, so it complements rather than replaces real monitoring.

Auto-balancing. This is the killer feature, and we'll say that plainly. With balance => 'auto', Horizon shifts worker processes between queues based on current load and wait time. When webhooks spikes, workers migrate there; when it drains, they flow back. Cost: essentially none beyond running Horizon at all. This feature alone is the reason most teams who should adopt Horizon should adopt it.

Job tags. Jobs are auto-tagged with their Eloquent model IDs, and you can add custom tags. Searching "everything touching order 5512" becomes a text box. Cost: tag data lives in Redis, adding a bit of memory usage on your Redis or Valkey instance.

One-click retry and failed job UX. A support engineer can find and retry a failed job without SSH access. If you've ever lost an afternoon to debugging queue failures in production, you know what this is worth.

Metrics snapshots. Throughput and runtime trends over time, powered by a scheduled horizon:snapshot command. Cost: you must remember to schedule it, and plenty of teams don't, then wonder why the metrics tab is empty.

Now the bill for all of it. Horizon requires the redis queue driver, full stop. It works perfectly with Valkey because Valkey speaks the Redis wire protocol, but database, SQS, and Beanstalkd queues are out. Each Horizon-managed worker carries a bit more memory overhead than a bare queue:work process, which adds up on small servers running large pools. And you've added a package that must track your Laravel version on every upgrade.

Strengths: Load-adaptive worker allocation, genuine observability, tag search, humane failed-job workflow, and centralized worker config in a PHP file that ships with your code instead of living in server-side ini files.

Best for: Multi-queue apps on Redis or Valkey with uneven, shifting load, teams where multiple people interact with queue operations, and anyone running enough job volume that "what is the queue doing right now" is a daily question.

Considerations: Redis-protocol stores only. Extra memory per process. A dashboard that's a security hole if left ungated. One more dependency in every framework upgrade. And a subtle one: Horizon becomes a single point of failure for your whole worker pool, so you must monitor the monitor.

Plain Workers vs. Horizon: Side by Side

Before the decision framework, here's the full comparison in one place. We've split it into what the software does and what running it demands of you, because the second table is where most blog posts go quiet.

CapabilityPlain queue:workHorizonQueue driversDatabase, Redis/Valkey, SQS, BeanstalkdRedis/Valkey onlyRetries, backoff, timeoutsYes (core Laravel)Yes (same core mechanics)Failed job storagefailed_jobs tablefailed_jobs table + dashboard UIQueue priorityStatic, via --queue=a,b,c orderPriority order plus load-based balancingWorker allocationFixed numprocs per stanzaDynamic (auto), even (simple), or fixed (false)VisibilityCLI + logs, build your ownDashboard: wait times, throughput, runtimesJob search by tagNoYesRetry from UINoYesLong-term metricsNoSnapshots (with scheduled command)
Operational concernPlain queue:workHorizonSupervisor programs to manageOne per worker groupExactly oneWorker config lives inServer-side ini filesconfig/horizon.php, versioned with codeDeploy-time restartphp artisan queue:restartphp artisan horizon:terminateExtra scheduled tasksOptionally queue:prune-failedhorizon:snapshot every 5 min + pruningDashboard security workNone (no dashboard)Required: gate or Horizon::authMemory footprintBaselineBaseline + master process + per-child overheadFailure blast radiusOne dead process = one worker downHorizon dies = entire pool downPackage upgrade surfaceNoneTracks Laravel major versions

Read that second table honestly. Horizon centralizes and simplifies a lot, one process, config in git, but it concentrates risk and adds obligations. Neither column is free.

Which Three Questions Decide It?

Skip the twenty-point checklists. In practice, three questions settle this decision for almost every team we've worked with. Answer them in order.

Question 1: Are You Already on Redis or Valkey?

This is a gate, not a preference. Horizon requires a Redis-protocol queue store. If you're on the database driver and it's meeting your throughput needs, Horizon would force a driver migration first, and "install a dashboard" is a bad reason to change your queue's storage engine. If you're on SQS because you like managed infrastructure, same answer: Horizon is simply off the table.

If you're already on Redis, or on Valkey, which is wire-compatible and works with Horizon without any configuration difference, the gate is open and you move to question two. Unsure about the Valkey side of that sentence? We compared them directly in Valkey vs. Redis for Laravel caching and queues; the short version is that for queue workloads they behave identically.

Question 2: Do You Have Multiple Queues With Shifting Load?

One queue with steady volume gains almost nothing from auto-balancing, because there's nothing to balance. But the moment you're running mail, exports, webhooks, and default, and their relative load changes hour to hour, static numprocs allocation forces an ugly choice: overprovision every queue for its worst hour, or accept latency when the spike lands on the underweighted one.

Horizon's auto strategy dissolves that trade-off by moving workers to wherever the wait time is. In our experience this is the single feature that justifies Horizon on its own. If you answered yes here and yes to question one, you should probably be running Horizon, and the rest is implementation detail.

Question 3: Will Anyone Actually Look at the Dashboard?

Be honest. A dashboard nobody opens is negative value: it's attack surface, memory, and upgrade work in exchange for nothing. If your team's operational style is alert-driven, page me when queue depth exceeds X or the oldest job is older than Y, and nobody will browse queue graphs between incidents, then Horizon's observability features will rot quietly.

But if support engineers need to look up a customer's stuck export, or you review throughput trends when planning capacity, the dashboard earns its keep weekly. Two or three yes answers means install it. One yes, on question two, still usually means install it, because auto-balancing works whether or not anyone watches. Zero yes answers means plain workers, and you should feel good about that.

Which Setup Fits Your Team Profile?

The three questions generalize, but most teams recognize themselves in one of a few profiles. Here's how we'd call each one.

ProfileDriverQueuesVerdictSolo dev, small appDatabaseOne default queuePlain workers, full stopSmall team, modest volumeRedis/Valkey1-2 stable queuesPlain workers, revisit at 3+ queuesSaaS with mixed workloadsRedis/ValkeyMail, exports, webhooks, spikyHorizon, it earns its keepHigh-scale worker fleetRedis/ValkeyMany queues, multiple serversHorizon per worker server

The solo developer with a single default queue on the database driver should not install Horizon, and we'd go further: doing so is a small mistake. You'd take on a Redis migration, a security obligation, and an upgrade dependency to get a dashboard for a queue you can fully understand with php artisan queue:failed and a depth check. Spend that effort on your product.

The SaaS profile is Horizon's home turf. Mail must go out promptly, exports are heavy and bursty, webhooks arrive in storms you don't control. This is exactly the shifting multi-queue load that auto-balancing was built for, and the tag search pays for itself the first time support asks "did customer X's report ever generate?"

The high-scale fleet, dedicated worker servers processing serious volume, runs one Horizon process per worker server, all pointed at the same Redis or Valkey backend. Each Horizon instance balances its local pool; the dashboard aggregates across all of them. Capacity beyond that is a horizontal scaling story, which we walked through in processing 1 million jobs a day. The one caution at this scale: Horizon's metrics are queue-level, not host-level, so you still need real server monitoring underneath it.

How Do You Run Each Well in Production?

Whichever side you land on, the difference between a solid setup and a flaky one comes down to a handful of details. Here they are for both paths.

Supervising Horizon Correctly

The most common Horizon mistake we see is treating it like a plain worker in Supervisor. It isn't. You run exactly one process, and because Horizon forks children, the stop settings matter enormously:

[program:horizon]
process_name=%(program_name)s
command=php /var/www/app/artisan horizon
autostart=true
autorestart=true
user=deploynix
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/horizon.log
stopwaitsecs=3600
stopasgroup=true
killasgroup=true

Three lines carry the weight here. stopwaitsecs must exceed your longest-running job, or Supervisor will SIGKILL Horizon mid-job during a restart and you'll get mysterious half-completed work. If your biggest export takes 40 minutes, 3600 seconds is right; a default of 10 is a data-corruption machine. stopasgroup and killasgroup ensure signals reach the child workers Horizon spawned, not just the master, so you never orphan a pool of zombie workers processing jobs nobody is supervising.

Then the pool itself lives in config/horizon.php, versioned with your code:

'environments' => [
    'production' => [
        'supervisor-1' => [
            'connection' => 'redis',
            'queue' => ['mail', 'webhooks', 'default'],
            'balance' => 'auto',
            'minProcesses' => 2,
            'maxProcesses' => 12,
            'balanceMaxShift' => 2,
            'balanceCooldown' => 3,
            'tries' => 3,
            'timeout' => 90,
        ],
        'supervisor-exports' => [
            'connection' => 'redis',
            'queue' => ['exports'],
            'balance' => false,
            'processes' => 3,
            'tries' => 1,
            'timeout' => 2400,
        ],
    ],
],

Note the three balance strategies in action. auto shifts processes between mail, webhooks, and default based on load. simple (not shown) would split them evenly and never move them. false gives the exports queue its own dedicated fixed-size supervisor, which is the right call for long-running jobs whose timeout profile differs wildly from everything else. Mixing strategies across supervisors like this is normal and encouraged; the official Horizon docs cover the full option set.

Deploys, Dashboard Security, and Snapshots

Deploys must tell workers to finish their current job and restart on the new code. For plain workers that's php artisan queue:restart; Horizon's parallel is horizon:terminate, and Supervisor's autorestart brings it back up on the fresh release:

# deploy hook, after the new release is linked
php artisan config:cache
php artisan migrate --force
php artisan horizon:terminate   # graceful: finishes in-flight jobs, then exits
# plain-worker equivalent: php artisan queue:restart

Two more obligations that plain workers don't have. First, gate the dashboard. Out of the box Horizon is only accessible in the local environment; in production you define who gets in via the viewHorizon gate in HorizonServiceProvider (or Horizon::auth). Ship it ungated and you've published your job payloads, which routinely contain emails, IDs, and tokens, to the internet. Second, schedule horizon:snapshot every five minutes, or your metrics tab stays empty forever:

Schedule::command('horizon:snapshot')->everyFiveMinutes();

Who Watches the Watcher?

Here's the failure mode nobody plans for: Horizon itself dies. Because it supervises your entire pool, its death takes every worker with it, and the dashboard that would have told you can't load because the process behind it is gone. Supervisor's autorestart handles crashes, but not a wedged process, a full disk, or an OOM-killed master on a memory-starved box.

So monitor the monitor. Alert on queue depth and oldest-job age from outside the Horizon process, and watch host-level CPU and memory on your worker servers so you catch the OOM spiral before it kills the pool. We've found that queue-level metrics and host-level server monitoring fail at different times, which is exactly why you want both.

Running Both Paths on Deploynix

Since we build deployment infrastructure for Laravel, here's concretely how the two paths look on our platform. This maps one-to-one onto everything above, so it doubles as a worked example even if you're provisioning by hand.

The plain-worker path is the queue workers UI. You define a worker per app: connection, queue list, process count, timeout, tries, sleep, and PHP version, and Deploynix generates and installs the corresponding Supervisor config on the server. It's the exact stanza pattern from earlier in this post, just without hand-editing ini files over SSH. Change the process count in the UI, and Supervisor reloads with the new allocation.

The Horizon path deliberately does not use that feature. Because Horizon supervises its own pool, you run it as a daemon instead: one managed long-running php artisan horizon process with the group-signal and stop-timeout semantics handled for you. Your pool sizing then lives where it should, in config/horizon.php in your repository. The driver requirement is already met, since Deploynix app servers ship with Valkey, which Horizon treats identically to Redis. For dedicated fleets, the worker server type gives you hosts whose only job is running Horizon against your queue backend, and zero-downtime deploys can run horizon:terminate in a deploy hook so releases never kill in-flight jobs.

One thing we'd flag from experience: teams sometimes assume Horizon's dashboard means they can skip server monitoring on worker boxes. It can't. Horizon sees queues; it doesn't see the memory pressure that's about to OOM-kill it. Our server monitoring watches CPU, memory, and load on the host, which is precisely the layer that catches Horizon's own failure modes. If you go the Horizon route, we've written up the full production setup in running Laravel Horizon on Deploynix.

How Hard Is It to Migrate Between the Two?

Good news: this decision is cheap to reverse, in both directions. Your job classes, retry logic, backoff methods, and failed_jobs table are identical under both systems, because Horizon reuses Laravel's core queue mechanics rather than replacing them. Migration is an infrastructure swap, not a rewrite.

Going from plain workers to Horizon: get on Redis or Valkey if you aren't already (the only potentially non-trivial step), install the package, translate each Supervisor stanza into a Horizon supervisor block with matching queue lists and process counts, then replace your N worker programs with the single Horizon program. Swap queue:restart for horizon:terminate in your deploy script, gate the dashboard, schedule snapshots. Start with balance => 'simple' to reproduce your old static allocation exactly, confirm throughput matches, then switch to auto and watch the wait times drop.

Going the other way is even simpler, and yes, teams do it, usually after realizing nobody opened the dashboard in six months. Read your process counts out of config/horizon.php, write the equivalent queue:work stanzas, stop Horizon, start the workers, swap the deploy command back. You lose tags, balancing, and the UI; you keep every job, every retry policy, and every failed-job record. Either migration is an afternoon, not a quarter. That's worth internalizing, because it means you should decide for the team you are now, not the team you might be in three years.

FAQ

Does Horizon work with Valkey?

Yes, without any special configuration. Valkey speaks the Redis wire protocol, so Laravel's Redis queue driver, and therefore Horizon, can't tell the difference. Point your redis connection at a Valkey instance and Horizon's balancing, tags, and metrics all work exactly as they do on Redis.

Can I use Horizon with the database or SQS queue driver?

No. Horizon requires the Redis queue driver; that's a hard dependency, not a soft recommendation. If you're on database or SQS and happy, stay on plain queue:work workers, which support every driver. Adopting Horizon means migrating your queue store first, and that migration should be justified on its own merits.

Is Horizon faster than plain queue:work?

Not per job. Individual jobs execute through the same worker mechanics either way, and Horizon's children actually carry slightly more memory overhead. Where Horizon improves real-world latency is allocation: auto-balancing moves workers to backed-up queues, so jobs wait less even though they don't run faster.

Do I still need Supervisor if I use Horizon?

Yes, just less of it. Something must keep the horizon master process alive across crashes and reboots, and that's Supervisor (or systemd, or a platform-managed daemon). The difference is you supervise one process instead of one per worker, and Horizon manages the pool beneath it.

What happens to my failed jobs if I switch to or from Horizon?

Nothing. Both setups write failures to the same failed_jobs table with the same payloads and exceptions, and queue:retry works identically in both worlds. Horizon adds a UI over that table; removing Horizon removes the UI, not the data.

The Verdict

Here's the framework compressed to its core. On the database driver or SQS with no pain? Plain workers, and don't let anyone make you feel behind for it. On Redis or Valkey with multiple queues and shifting load? Horizon, primarily for auto-balancing, with the dashboard as a bonus. Somewhere in between? Default to plain workers and let a real problem, not a habit, pull you toward Horizon. The migration is cheap, so decide for today.

Whichever way you land, the production details decide whether it works: correct stop timeouts, graceful restarts on deploy, a gated dashboard, and host-level monitoring underneath it all. Your next step is a fifteen-minute audit of your current setup against the stanzas in this post, starting with stopwaitsecs versus your longest job. In our experience, that one line is where most queue setups are quietly broken.

Migrating a Laravel App From MySQL to PostgreSQL: A Practical Guide

Deploynix — Fri, 11 Sep 2026 11:03:04 +0000

Let's start with the honest part: most Laravel apps do not need to switch databases. MySQL powers an enormous share of production Laravel deployments, it's fast, it's well understood, and Eloquent abstracts away most of the differences anyway. If your app is healthy on MySQL and your team knows it well, the highest-value move is usually to stay put and invest in better indexes and query hygiene instead.

But some apps do outgrow MySQL in specific, identifiable ways. Heavy JSON workloads that want real indexing. Migration files that can't be rolled back atomically because MySQL commits DDL implicitly. Deadlocks from gap locking that nobody can quite explain. Reporting queries that would be two lines with a partial index or a proper string_agg. If you've hit two or three of those, PostgreSQL starts earning its migration cost.

This post is a runbook, not advocacy. We've helped teams move Laravel apps between engines on Deploynix, and the pattern is consistent: the data transfer is the easy part, and the dialect differences hiding in your codebase are the hard part. We'll cover how to decide, how to audit, how to convert the schema with pgloader, how to fix the Laravel layer, and how to cut over with a rollback path you'd actually trust at 2 a.m.

Key Takeaways- Switch for concrete wins (transactional DDL, JSONB, partial indexes), not because Postgres is fashionable - Run your test suite against real PostgreSQL in CI weeks before any data moves - pgloader handles ~90% of schema conversion; enums, fulltext, and spatial need hand-work - Verify with row counts, checksums, and sequence resets before flipping .env - Keep MySQL warm as a rollback target for at least a week

Should You Switch at All?

This decision deserves more scrutiny than it usually gets. A database migration touches every query your app runs, so the reasons need to be specific to your workload, not aspirational. Here are the reasons that actually justify the work, in our experience.

Transactional DDL. PostgreSQL wraps schema changes in transactions. If a Laravel migration fails halfway through on MySQL, you're left with a partially applied schema and a migrations table that disagrees with reality. On Postgres, the whole migration rolls back cleanly. For teams that deploy schema changes frequently, this alone removes a whole category of production incidents.

JSONB with GIN indexes. MySQL's JSON type works, but querying inside it at scale is painful. Postgres jsonb stores a parsed binary representation and supports GIN indexes, so WHERE payload @> '{"status": "failed"}' can use an index instead of scanning the table. If you have JSON columns in WHERE clauses today, this is probably your biggest single win.

Partial and expression indexes. CREATE INDEX ... WHERE deleted_at IS NULL indexes only the rows you query. An index on lower(email) gives you case-insensitive uniqueness without hacks. MySQL has functional indexes now, but Postgres's implementation is more mature and more flexible.

Richer types and stricter conformance. Native arrays, ranges, inet, real booleans, and a query planner that follows the SQL standard closely. Postgres rejects garbage like zero-dates instead of storing it, which surfaces bugs earlier.

No gap-lock surprises. InnoDB's default REPEATABLE READ isolation uses gap locks that cause deadlocks in insert-heavy workloads under conditions that are genuinely hard to reason about. Postgres's MVCC model under READ COMMITTED behaves more predictably for typical web traffic.

Now the reasons not to switch, which are just as real. Your team knows MySQL: its EXPLAIN output, its tuning knobs, its failure modes. That operational knowledge has value, and you're throwing it away. Your ecosystem tooling (backup scripts, monitoring dashboards, that one replication setup someone built in 2023) all assumes MySQL. And "Postgres is trendy" is not a reason. Neither is a conference talk. If you can't name the specific feature that fixes a specific problem you have today, don't migrate. If you're still weighing engines for a new project, our comparison of MySQL vs MariaDB vs PostgreSQL on Deploynix is the better starting point, because greenfield choice and production migration are very different decisions.

What Should You Audit Before Touching Anything?

The pre-flight audit is where migrations are won or lost. Eloquent-generated queries mostly translate cleanly between engines. Raw SQL does not, and every Laravel codebase over a couple of years old has more raw SQL than its authors remember.

Grep for raw SQL

Start by building an inventory of every place your code bypasses the query builder's dialect abstraction:

# Every raw SQL escape hatch in the codebase
grep -rEn "DB::raw|whereRaw|orderByRaw|selectRaw|havingRaw|groupByRaw|DB::statement|DB::select\(|DB::unprepared" \
  app/ database/ --include="*.php" > raw-sql-inventory.txt

# Known MySQL-isms that will break or silently misbehave on Postgres
grep -rEin "FIELD\(|GROUP_CONCAT|IFNULL\(|DATE_FORMAT\(|ON DUPLICATE KEY|STRAIGHT_JOIN|SQL_CALC_FOUND_ROWS|RAND\(\)|UNIX_TIMESTAMP" \
  app/ database/ --include="*.php" >> raw-sql-inventory.txt

wc -l raw-sql-inventory.txt

Every line in that file needs a decision: rewrite portably, rewrite for Postgres, or delete. Don't guess at the count. We've seen a "we barely use raw SQL" app produce 140 hits.

Inventory the behavior differences

Beyond raw SQL, the engines simply behave differently in ways that Eloquent cannot paper over. This table is the checklist we work from:

Behavior

MySQL

PostgreSQL

What breaks

String comparison

Case-insensitive by default (utf8mb4_*_ci)

Case-sensitive

Logins, search, unique emails

LIKE

Case-insensitive

Case-sensitive (use ILIKE)

Every search box

GROUP BY

Lenient unless only_full_group_by

Strict, always

Reporting queries error out

Zero dates (0000-00-00)

Accepted in lax modes

Rejected

Import fails on dirty data

Booleans

tinyint(1) with 0/1

Native boolean, true/false

Raw WHERE flag = 1 clauses

Auto-increment

AUTO_INCREMENT counter

Sequences

Duplicate-key errors if not reset

ENUM columns

Native column type

Check constraint or custom type

pgloader output needs review

Fulltext search

FULLTEXT index, MATCH ... AGAINST

tsvector + GIN, @@ operator

Search features need rewriting

Upserts

ON DUPLICATE KEY UPDATE

ON CONFLICT ... DO UPDATE

Raw upsert statements

Ordering by list

FIELD(col, ...)

CASE WHEN or array_position

Custom sort orders

String aggregation

GROUP_CONCAT

string_agg

Report exports

DDL in transactions

Implicit commit

Fully transactional

Actually a Postgres win

Identifier quoting

Backticks

Double quotes

Raw queries with backticks

Note that upsert() in Laravel's query builder abstracts the upsert syntax correctly on both engines. The danger is exclusively in raw statements someone wrote by hand.

Check package compatibility and JSON usage

Go through composer.json and confirm every package that touches the database supports Postgres. Most first-party and popular packages do, but audit anything that ships its own migrations or raw queries: search packages, analytics packages, anything doing spatial work. While you're in there, list every json column and how it's queried. Columns that only store-and-retrieve are a non-event. Columns queried with whereJsonContains or ->>' extraction are your JSONB-plus-GIN upgrade candidates, and worth flagging now so you add the indexes after import.

Finally, confirm your backups are current and tested before you change anything. If your backup story is "we think cron is running it," fix that first; our guide to automated database backups covers the setup for both engines.

Converting the Schema With pgloader

pgloader is the workhorse for MySQL-to-Postgres moves, and it's genuinely good. It reads the MySQL schema, creates equivalent Postgres tables, streams the data across in parallel, converts types on the fly, rebuilds indexes, and resets sequences. For a straightforward schema it can be a one-command migration.

A production run deserves a real config file rather than command-line flags, because you'll run it several times (staging dry-runs, then the final sync) and you want it reproducible:

LOAD DATABASE
     FROM mysql://app:secret@10.0.0.11:3306/app_production
     INTO postgresql://app:secret@10.0.0.12:5432/app_production

 WITH include drop, create tables, create indexes,
      reset sequences, foreign keys,
      workers = 8, concurrency = 1,
      rows per range = 50000

 SET PostgreSQL PARAMETERS
      maintenance_work_mem TO '512MB',
      work_mem TO '64MB'

 SET MySQL PARAMETERS
      net_read_timeout  = '600',
      net_write_timeout = '600'

 CAST type json to jsonb drop typemod,
      type tinyint when (= precision 1) to boolean
           drop typemod using tinyint-to-boolean,
      type datetime to timestamptz drop typemod

 ALTER SCHEMA 'app_production' RENAME TO 'public'
;

The CAST rules are where you encode the decisions from your audit. json becomes jsonb (take the win). tinyint(1) becomes real boolean, which is correct but is exactly why you audited raw = 1 comparisons earlier. Whether datetime becomes timestamp or timestamptz depends on your app; if everything runs in UTC (as Laravel defaults encourage), timestamptz is the safer long-term choice.

What pgloader handles well, and what it mangles

It handles tables, data, most types, standard indexes, foreign keys, and sequence resets reliably. Three areas need hand-review every time:

Enums. MySQL ENUM columns become custom Postgres enum types by default, which are awkward to alter later. Most Laravel teams are better off casting them to varchar with a check constraint, or just varchar if validation lives in a PHP enum anyway. Add an explicit CAST rule so the choice is deliberate.

Fulltext indexes. FULLTEXT indexes don't translate. pgloader will skip them, and your MATCH ... AGAINST queries were going to break regardless. Plan a tsvector column with a GIN index as follow-up work, or move that feature to Meilisearch via Scout and sidestep the problem.

Spatial columns. MySQL spatial types need PostGIS on the Postgres side and manual mapping. If you have them, budget real time here.

Run pgloader against staging first, read its summary table line by line, and treat every warning as a defect to investigate. The dry-run is not optional. It's where you discover the zero-dates in a 2019-era table that Postgres will refuse, and you fix the source data before cutover night instead of during it.

Fixing the Laravel Layer

With a converted staging schema in hand, the work moves into the application, and it should start weeks before any production data moves.

Point CI at real Postgres first

Most Laravel test suites run on SQLite in memory. That's fast, and it's also exactly why your tests will pass while your app is broken: SQLite hides the dialect differences between MySQL and Postgres. The single highest-leverage step in this whole migration is switching CI to run the suite against a real PostgreSQL service and fixing failures one by one:

# .github/workflows/tests.yml (excerpt)
services:
  postgres:
    image: postgres:16
    env:
      POSTGRES_DB: testing
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    ports: ["5432:5432"]

Every red test is a dialect bug found in CI instead of in production. Strict GROUP BY errors, case-sensitivity assumptions, boolean comparisons: they all surface here, on your schedule. Budget two to four weeks of this running in parallel with normal feature work.

The config change

The Laravel side of the connection is refreshingly boring. Add (or update) the pgsql connection in config/database.php and drive it from .env:

// config/database.php
'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'app_production'),
    'username' => env('DB_USERNAME', 'app'),
    'password' => env('DB_PASSWORD', ''),
    'charset' => 'utf8',
    'search_path' => 'public',
    'sslmode' => 'require',
],

// .env, at cutover time
// DB_CONNECTION=pgsql
// DB_HOST=10.0.0.12
// DB_PORT=5432

Make sure the pdo_pgsql PHP extension is installed on every app server before cutover night, not during it.

Fixing the queries CI surfaces

The fixes follow a handful of patterns. Prefer the portable version where one exists, so you're not just trading one dialect lock-in for another:

// FIELD() ordering: MySQL only. Rewrite with CASE WHEN (portable).
->orderByRaw("FIELD(severity, 'critical', 'warning', 'ok')")          // before
->orderByRaw("CASE severity WHEN 'critical' THEN 0
              WHEN 'warning' THEN 1 ELSE 2 END")                      // after

// Case-insensitive search: MySQL LIKE ignores case, Postgres doesn't.
->where('email', 'like', "%{$term}%")                                 // silently case-sensitive now
->whereRaw('email ILIKE ?', ["%{$term}%"])                            // Postgres-native
->whereRaw('lower(email) like ?', ['%'.mb_strtolower($term).'%'])     // portable

// Booleans in raw SQL: tinyint(1) took 0/1, Postgres boolean won't.
->whereRaw('is_active = 1')                                           // fails on Postgres
->where('is_active', true)                                            // builder handles both engines

// String aggregation
DB::raw("GROUP_CONCAT(name SEPARATOR ', ')")                          // MySQL
DB::raw("string_agg(name, ', ')")                                     // Postgres

Two more to check by hand. First, unique email columns: if your app relied on MySQL's case-insensitive collation to prevent Sam@ and sam@ registering twice, add a unique index on lower(email) (or use citext) after import, or that protection is gone. Second, any raw ON DUPLICATE KEY UPDATE statements need rewriting as ON CONFLICT; queries using Laravel's upsert() are already fine.

Which Cutover Strategy Fits Your App?

There are two sane ways to move the data, and the right one depends on how much downtime you can buy and how big the database is.

Factor

Maintenance window (big-bang)

Dual-run (replicate, then flip)

Downtime

Minutes to a few hours

Near zero

Complexity

Low: one pgloader run

High: CDC tooling, drift monitoring

Rollback

Trivial: point .env back at MySQL

Trivial early, harder once writes diverge

Data volume sweet spot

Up to ~50-100 GB

Hundreds of GB and up

Verification

Once, during the window

Continuous, before the flip

Team effort

One rehearsed evening

Days to weeks of parallel operation

The maintenance window approach.

Strengths: Simple, rehearsable, and verifiable in one sitting. One tool, one data pass, one moment where the truth moves. The rollback story is as clean as it gets because MySQL never stops being complete and consistent; it's just frozen.

Best for: The majority of Laravel apps. If pgloader moves your staging copy in under an hour, you can buy a window (we schedule 3x the rehearsed duration) and your users tolerate a short read-only period, do this.

Considerations: The window must be rehearsed on staging with a production-sized dataset, and you need a hard abort time agreed in advance. If the rehearsal takes four hours, this strategy is telling you something.

The dual-run approach.

Strengths: Near-zero downtime. You replicate changes from MySQL to Postgres continuously (pgloader for the initial load, then CDC tooling or an application-level double-write for the delta), verify at leisure, and flip when the two sides have matched for days.

Best for: Large databases where a full pgloader pass takes many hours, or apps with genuine 24/7 write traffic and no tolerable window.

Considerations: Substantially more moving parts, and every moving part is a place for silent drift. Double-writing from the app is deceptively hard to get right under failure conditions. Don't choose this for a 20 GB database because zero downtime sounds nicer; you're trading a one-hour window for weeks of operational risk.

The runbook for the window

Rehearse this end to end on staging, with timings written down, before you book the window:

Announce the window; put the app in maintenance mode or flip it read-only. Freeze all writes, including queue workers and scheduled jobs. Verify the freeze by watching MySQL's write counters go flat.
Run the final pgloader pass against the frozen source.
Verify. Row counts, checksums, sequences (queries below). This is the go/no-go gate.
Flip .env to the pgsql connection and deploy the config change to all app servers.
Smoke test the critical paths with real requests: login, checkout or the equivalent, one queued job, one scheduled command.
Reopen traffic. Watch error rates and slow-query logs like a hawk for the first hour.

Step 3 deserves its own code block, because "it looks right" is not verification:

-- 1. Row counts: run per table on BOTH sides and diff the results.
--    (information_schema.TABLES row counts are estimates; use COUNT(*).)
SELECT COUNT(*) FROM orders;

-- 2. Checksums on critical tables: order-independent XOR of row hashes.
-- MySQL
SELECT BIT_XOR(CRC32(CONCAT_WS('|', id, user_id, status, total))) FROM orders;
-- PostgreSQL (compare that both sides produce stable, matching values
-- for a seeded staging dataset before trusting this in production)
SELECT BIT_XOR(hashtext(concat_ws('|', id, user_id, status, total))) FROM orders;

-- 3. Sequences: pgloader's "reset sequences" should handle this. Verify anyway,
--    because an unreset sequence means duplicate-key errors on the first INSERT.
SELECT setval(
    pg_get_serial_sequence('orders', 'id'),
    (SELECT COALESCE(MAX(id), 1) FROM orders)
);

-- 4. Fresh planner statistics before any traffic hits the database.
VACUUM ANALYZE;

Write down your rollback criteria before the window: which failures trigger an abort, and who makes the call. And read our post on recovering from a failed database migration in production before you need it, not after.

Running the Migration on Deploynix

Here's how this looks in practice on our own platform, since the database server type supports MySQL, MariaDB, and PostgreSQL and the pieces line up naturally with the runbook above.

Provision a new PostgreSQL database server alongside your existing MySQL one. Nothing about the MySQL server changes; both run in parallel for the whole migration. Because app servers can connect to any database server, staging can point at the new Postgres box weeks early for the CI-and-fixes phase while production traffic continues on MySQL untouched.

Lock the new server down before any data lands on it. Use firewall rules to restrict the Postgres port to your app servers' IPs only, exactly as your MySQL server should already be configured. A half-migrated database with production data on it is still production data.

Enable automated backups to S3-compatible storage on the Postgres server from day one, so your first pgloader import is followed by your first restorable backup, and keep the MySQL backup schedule running unchanged. During the transition you're effectively running the 3-2-1 backup rule across two engines, which is mildly annoying and entirely worth it.

The cutover itself is a config change, which means zero-downtime deploys handle the flip: update the environment to point at the Postgres host, deploy, and every app server picks up the new connection on release. If smoke tests fail, deploy the previous environment and you're back on MySQL in one release cycle. Keep the MySQL server provisioned, firewalled, and backed up for at least a week after cutover. It's your rollback target, and a week of monitoring data is what earns the decision to decommission it.

What Happens After the Cutover?

The migration isn't done when the site comes back up. The first week on Postgres is an active monitoring period, not a victory lap.

Statistics first. If you skipped it during the window, run VACUUM ANALYZE immediately. Postgres's planner is flying blind on a freshly imported database until statistics exist, and "Postgres is slower than MySQL was" complaints in week one are very often just missing stats or a missing index, not the engine.

Index review. Diff the index list on both sides table by table. Fulltext indexes didn't translate, prefix indexes (INDEX (col(10))) didn't translate, and anything pgloader warned about needs rebuilding by hand. Then go further: this is the moment to add what MySQL couldn't give you, like partial indexes on soft-deleted tables and GIN indexes on the JSONB columns you flagged in the audit. The principles from our MySQL indexing guide carry over almost entirely; the syntax and the extra options are what changed.

Watch query performance daily. Enable pg_stat_statements, sort by total time each morning, and compare against your mental model of what was slow on MySQL. The planners are different, and a query MySQL handled fine can pick a bad plan on Postgres (and vice versa, pleasantly often). The workflow we describe in finding and fixing slow queries in Laravel applies directly; only the EXPLAIN output format changes.

Keep MySQL warm. Frozen, firewalled, backed up, and one config deploy away. After a full week of clean error rates, stable p95 latencies, and successful Postgres backups you've actually test-restored, decommission it and reclaim the spend.

When Should You Abort?

Every good runbook has abort criteria, and deciding them under pressure is how bad nights get worse. Ours, roughly in order of when they'd trigger:

Before the window: if the staging rehearsal can't produce matching row counts and checksums twice in a row, you don't have a migration, you have a science experiment. Fix it in staging or don't book the window. Likewise if the raw-SQL fix list is still growing the week before cutover.

During the window: any checksum mismatch on a critical table is an automatic abort. Don't debug data integrity at 1 a.m. against a ticking clock; unfreeze MySQL, reopen, and investigate in daylight. Same if you blow through the hard time limit you set in advance. The whole point of the big-bang strategy is that aborting costs almost nothing: MySQL was never modified.

After the window: the calculus shifts the moment real writes land in Postgres, because rolling back now means losing or hand-porting that data. This is why the smoke-test step exists between the flip and reopening traffic. If errors surface in the first minutes, roll back and lose nothing. If a subtle bug surfaces on day three, you'll almost always fix forward on Postgres rather than roll back, and that's precisely why the week of monitoring with MySQL warm matters: it converts "we think it works" into evidence before the rollback option quietly expires.

An aborted migration that reruns cleanly a month later is a success story. A forced migration that limps into production is not.

FAQ

How long does a MySQL to PostgreSQL migration take for a typical Laravel app?

Plan for four to eight weeks end to end, with most of it in the audit and CI-fixing phases, not the data move. pgloader itself typically streams tens of gigabytes per hour depending on hardware and index counts. Your staging rehearsal gives you the real number for the window itself.

Can I keep using SQLite for local tests after moving to Postgres?

For fast local feedback, sure, but CI must run the full suite against real PostgreSQL, permanently. SQLite hides dialect behavior like strict GROUP BY, ILIKE, and boolean handling, which is exactly the class of bug this migration introduces. Postgres-in-CI is the safety net; keep it forever.

Does Eloquent just work on PostgreSQL?

Eloquent and the query builder support Postgres as a first-class driver, so standard where, join, upsert(), and pagination calls translate correctly. Every DB::raw, whereRaw, orderByRaw, and selectRaw in your codebase is on you, which is why the grep audit comes before everything else.

What's the single most common post-migration bug?

Case sensitivity. MySQL's default collations compare strings case-insensitively; Postgres does not. Logins, email uniqueness, and search boxes all quietly change behavior. Audit every LIKE, add lower() unique indexes where MySQL's collation was doing invisible work, and test authentication flows explicitly during the smoke test.

Should I migrate MySQL to MariaDB instead as a smaller step?

If your pain is licensing or minor feature gaps, maybe, since MariaDB is a much smaller jump. But it won't give you transactional DDL, JSONB, or partial indexes; those are the Postgres-specific reasons to migrate. If your driver list looks like this post's, MariaDB just postpones the same project.

Where to Go From Here

You don't need to commit to anything today. The first step is cheap and reversible: run the grep audit from this post against your codebase and count the raw SQL you'd have to touch. If the inventory is short and the reasons-to-switch list resonated, spin up a Postgres server next to your MySQL one, point a staging copy at it, and let pgloader and your CI pipeline tell you how hard this migration really is for your app. The data will make the decision more honestly than any blog post can, ours included.

Database Connection Pooling for Laravel: When You Need It and How to Set It Up

Deploynix — Wed, 09 Sep 2026 11:03:03 +0000

It usually happens during a traffic spike, a deploy, or a queue backlog you're frantically draining. The app that ran fine for months suddenly starts throwing FATAL: sorry, too many clients already on every third request, and your error tracker lights up while you're trying to figure out what changed. Nothing changed, really. You just crossed a line that was always there: PostgreSQL's default cap of 100 connections, or MySQL's 151. Every Laravel app running on more than one server is quietly walking toward that line.

The frustrating part is that connection exhaustion looks like a database problem but is really an architecture problem. PHP-FPM doesn't share database connections between workers the way a JVM app shares a pool. Every FPM worker opens its own connection for the duration of each request. Multiply that across app servers, queue workers, Horizon, the scheduler, and maybe Octane and Reverb, and the numbers get big fast, even when your actual query load is modest.

Connection pooling, via PgBouncer for PostgreSQL or ProxySQL for MySQL, is the standard fix. But in our experience it's reached for too early about as often as it's reached for too late. Pooling adds a moving part, and transaction-mode pooling in particular breaks a handful of things Laravel developers use without thinking about them, like advisory locks and session variables.

This post walks through the whole decision: why Laravel apps hit connection limits, what to fix before you install a pooler, when pooling genuinely becomes the answer, and how to set up PgBouncer end-to-end on Ubuntu 24.04 without breaking your migrations.

Key Takeaways- PHP-FPM gives every worker its own DB connection, so connection count scales with worker count, not query load. - PostgreSQL forks a process per connection (historically ~5-10MB+ each) and defaults to 100 max connections (PostgreSQL docs). - Fix pm.max_children, idle transactions, and slow queries before installing a pooler. - PgBouncer in transaction mode is the right default for multi-server Postgres setups; ProxySQL matters later for MySQL.

Why Do Laravel Apps Run Out of Database Connections?

The root cause is PHP's execution model. A Java or Go application runs as one long-lived process that maintains a small internal pool of connections, maybe 10 or 20, shared across thousands of concurrent requests. PHP-FPM works differently: each worker process handles one request at a time, opens its own database connection (or reuses a persistent one), and holds it for the entire request. There is no application-level pool. Twenty busy FPM workers means twenty database connections, full stop.

That model is fine on a single small server. It stops being fine the moment you scale horizontally, because every process you add anywhere in your stack brings its own connection with it. Have you ever actually added up everything that connects to your database? Most teams haven't until the day it fails.

The Connection Multiplication Problem

Here's the math for a fairly ordinary two-app-server Laravel setup:

App server 1:  pm.max_children = 30      → up to 30 connections
App server 2:  pm.max_children = 30      → up to 30 connections
Worker server: Horizon, 20 processes     → 20 connections (held constantly)
Scheduler:     overlapping tasks         → 2-5 connections in bursts
Reverb:        websocket server          → 1-2 connections
Deploy window: migrations, cache warm    → 2-3 connections
                                          -------------------------------
Practical peak:                            ~85-90 connections

Against PostgreSQL's default max_connections = 100, that leaves almost no headroom. One traffic spike that pushes both FPM pools to their limits, one queue backlog that makes every Horizon worker busy simultaneously, and you're at the ceiling. The next connection attempt gets FATAL: sorry, too many clients already, and it doesn't discriminate: your health checks, your deploy migrations, and your psql debugging session all get refused too.

Note what's absent from that math: query volume. You can hit this wall at 50 requests per second or 500. Connection count tracks process count, which is why the problem tends to appear right after you split your stack across servers. We cover that transition in detail in our guide to multi-server Laravel architecture, and connection budgeting is one of the first things it forces you to think about.

Queue workers deserve special mention because they're the silent consumers. An FPM worker releases its connection between requests, at least logically, but a queue worker is a long-running process that holds its connection for hours. Twenty Horizon processes are twenty connections around the clock, even at 3 a.m. when they're processing nothing.

Why Are PostgreSQL Connections So Expensive?

PostgreSQL's connection cost is the reason this topic is mostly a Postgres conversation. Postgres forks a dedicated operating system process for every single connection. Each backend process has historically consumed roughly 5-10MB or more of memory depending on workload, work_mem settings, and what it has touched, and the fork itself costs real CPU time. This per-process design is also why the default max_connections is a conservative 100 (PostgreSQL docs).

The process model has real advantages, isolation being the big one, but it means idle connections are not free. A Postgres server with 300 connections, of which 250 are idle, is still carrying 300 processes worth of memory and scheduler overhead. Past a few hundred connections, throughput can degrade even when most of those connections do nothing.

MySQL is a different story. MySQL uses a thread per connection rather than a process, and threads are much cheaper to create and carry. The default max_connections is 151, and raising it into the several-hundreds range is routine and mostly safe on reasonable hardware (MySQL docs). This is why MySQL shops often go years without thinking about pooling, while Postgres shops hit the wall in month six. If you're still choosing an engine, this trade-off is one of several we compare in MySQL vs MariaDB vs PostgreSQL on Deploynix.

The asymmetry shapes the advice in the rest of this post: for PostgreSQL, pooling is a when, not an if, once you run multiple servers. For MySQL, it's a tool you reach for later, and often for reasons beyond raw connection counts.

What Should You Try Before Installing a Pooler?

A pooler is another daemon to configure, monitor, and debug. Before adding one, it's worth an hour checking whether you have a real capacity problem or just waste. We've found that maybe half of "we need PgBouncer" conversations end with one of the four fixes below instead.

Right-Size pm.max_children

FPM worker counts are the biggest lever, and they're frequently set by copy-paste rather than measurement. If your app server has pm.max_children = 50 but never serves more than 15 concurrent requests, you've reserved 50 potential database connections to cover load that needs 15. Size FPM from actual memory usage and real concurrency, not from a blog post's default. Our PHP-FPM tuning guide walks through the measurement process; the connection budget falls out of it almost for free.

The same logic applies to queue workers. Ten Horizon processes that are busy 5% of the time are ten permanent connections you could cut to four with no throughput loss.

Raise max_connections, But Do the Memory Math

Raising max_connections is legitimate as a first response, if you do it with a calculator rather than hope. The rough budget for Postgres:

Server RAM:               8 GB
shared_buffers:           2 GB
OS + page cache reserve:  2 GB
Remaining for backends:   4 GB

At ~10 MB per active backend:
4096 MB / 10 MB ≈ 400 theoretical max
Safe setting with margin:  max_connections = 200-250

Doubling from 100 to 200 on an 8GB dedicated database server is reasonable and buys real headroom. Going from 100 to 1,000 is not; you'd be one busy afternoon away from the OOM killer choosing your database as its victim. If the math says you need 500+ connections on Postgres, that's the signal that you've outgrown raising limits and need a pooler.

Kill Idle-in-Transaction Leaks

Connections stuck in idle in transaction are pure waste with extra damage: they hold locks and block vacuum. They usually come from application code that opens a transaction and then does slow work, an HTTP call, a file upload, a long loop, before committing. Find them:

SELECT pid, state, now() - state_change AS stuck_for, query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY stuck_for DESC;

Then set a server-side backstop so leaks can't accumulate: idle_in_transaction_session_timeout = '60s'. In Laravel code, the fix is keeping DB::transaction() closures tight. Do slow work outside the transaction, then transact only around the writes.

Fix the Slow Queries Holding Connections

Connection demand is concurrency times duration. A query that takes 2 seconds holds a connection 40 times longer than one that takes 50ms, so a handful of slow queries can inflate your concurrent connection count dramatically at the same request rate. Before buying capacity for slow queries, make them fast. We've written a full workflow for finding and fixing slow queries before they hit production, and for MySQL specifically, proper indexing is usually where the biggest wins hide.

When Does Pooling Become the Actual Answer?

Once you've right-sized workers and cleaned up leaks, the remaining question is structural: does your legitimate peak process count exceed what your database can comfortably hold? For PostgreSQL, that tends to happen at two-plus app servers. Here's our honest read on when to bother:

Your setup

Postgres

MySQL/MariaDB

1 app server, no separate workers

No pooler. Tune FPM, defaults are fine

No pooler

1 app server + Horizon worker server

Probably not yet; raise max_connections to ~200

No pooler

2-3 app servers + workers

Yes, PgBouncer in transaction mode

Usually still no; raise max_connections, consider thread pool

4+ app servers, autoscaling, or Octane fleet

Definitely, non-negotiable

ProxySQL worth evaluating (pooling + read/write split)

Serverless/ephemeral compute against Postgres

Always, from day one

ProxySQL or managed proxy from day one

The other trigger is connection churn rather than count. Because Postgres forks per connection, an app opening and closing hundreds of connections per second burns meaningful CPU on connection setup alone. PgBouncer turns that churn into cheap reuse of a small warm pool. FPM without persistent connections generates exactly this pattern under load.

What a pooler buys you, concretely: your 90 client connections from the earlier math collapse onto perhaps 20-25 actual Postgres backends, because at any instant only a fraction of those clients are mid-query. The database does the same work with a quarter of the processes, and you gain enormous headroom for adding app servers without touching max_connections again.

Which PgBouncer Pooling Mode Should You Use?

PgBouncer (pgbouncer.org) sits between your app and Postgres, maintaining a small pool of real server connections and multiplexing client connections onto them. How aggressively it multiplexes depends on the pooling mode, and choosing the mode is the single most important configuration decision.

Mode

Server connection assigned for

Multiplexing benefit

Session state safe?

session

The client's entire connection lifetime

Minimal (mostly saves connect/fork cost)

Yes, everything works

transaction

One transaction at a time

High, the sweet spot

No, breaks session-level features

statement

One statement at a time

Maximum

No, even multi-statement transactions break

Strengths: Session mode is fully transparent; nothing in your app needs auditing. Transaction mode delivers the actual consolidation, letting hundreds of clients share tens of backends. Statement mode squeezes out slightly more sharing for pure autocommit workloads.

Best for: Session mode fits apps that need session features (LISTEN/NOTIFY, advisory locks) but want cheaper connection setup. Transaction mode is the right default for Laravel behind FPM, and it's what the rest of this guide assumes. Statement mode is a niche tool; almost no Laravel app should use it, since it forbids explicit transactions entirely.

Considerations: Transaction mode means consecutive queries from the same client may run on different server connections. Anything that assumes "my connection remembers me" breaks: SET session variables, advisory locks held across transactions, LISTEN/NOTIFY, and, before PgBouncer 1.21, server-side prepared statements. PgBouncer 1.21+ added protocol-level prepared statement tracking, which removed the biggest Laravel pain point. More on the audit below.

How Do You Set Up PgBouncer on Ubuntu 24.04?

The recommended placement is on the database server itself, next to Postgres, listening on port 6432. One pooler, one place to configure and monitor, and it protects the database from every current and future client. (We'll discuss the alternative, a PgBouncer per app server, in the Deploynix section.)

Install and Authenticate

sudo apt update && sudo apt install -y pgbouncer

Ubuntu 24.04 ships PgBouncer 1.21+, so you get native prepared statement support. Authentication is the fiddly part. PgBouncer authenticates clients itself, then logs into Postgres on their behalf. With modern Postgres defaulting to SCRAM-SHA-256, you have two workable options.

Option one, auth_file: put the SCRAM verifier (not the plaintext password) in /etc/pgbouncer/userlist.txt. Extract it from Postgres:

SELECT usename, passwd FROM pg_shadow WHERE usename = 'laravel';

"laravel" "SCRAM-SHA-256$4096:...paste the full verbatim value..."

Option two, auth_query, which scales better with multiple users: create a dedicated pgbouncer role in Postgres with a SECURITY DEFINER function that looks up verifiers, and let PgBouncer query for them on demand. The PgBouncer docs have the canonical function. For a single-app server with one database user, auth_file is simpler and fine.

The pgbouncer.ini That Matters

[databases]
myapp = host=127.0.0.1 port=5432 dbname=myapp

[pgbouncer]
listen_addr = 10.0.0.5          ; private network IP of the DB server
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt

pool_mode = transaction
default_pool_size = 20          ; real Postgres backends per user/db pair
min_pool_size = 5
reserve_pool_size = 5           ; emergency backends under burst
reserve_pool_timeout = 3
max_client_conn = 500           ; total app-side connections accepted
max_prepared_statements = 200   ; PgBouncer 1.21+ prepared stmt tracking

log_connections = 0
log_disconnections = 0

The sizing logic: default_pool_size is how many actual Postgres backends this pool may use, so it must fit within max_connections alongside anything else connecting directly. Twenty backends comfortably serve the 90-client scenario from earlier because clients only occupy a backend while a transaction is in flight. max_client_conn = 500 gives your FPM fleet room to grow several-fold before you touch this file again. Start with default_pool_size around 20-25 and adjust from SHOW POOLS data, not guesswork.

Restart and verify: sudo systemctl restart pgbouncer, then connect through it with psql -h 10.0.0.5 -p 6432 -U laravel myapp.

Point Laravel at Port 6432

The application change is deliberately boring: same driver, different port.

// config/database.php
'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '6432'),   // PgBouncer, not Postgres
    'database' => env('DB_DATABASE', 'myapp'),
    'username' => env('DB_USERNAME', 'laravel'),
    'password' => env('DB_PASSWORD', ''),
    'charset' => 'utf8',
    'search_path' => 'public',
    'sslmode' => 'prefer',
],

Then set DB_PORT=6432 in .env on every app and worker server. On PgBouncer versions older than 1.21 you'd also add PDO::ATTR_EMULATE_PREPARES => true to the connection's options array to sidestep server-side prepared statements; on 1.21+ with max_prepared_statements set, you don't need it.

One useful escape hatch: keep a second Laravel connection named pgsql_direct pointing at port 5432. Use it for the rare session-dependent work below.

What Breaks in Transaction Mode: The Laravel Audit

Before flipping production traffic, grep your codebase for the session-state features transaction pooling breaks:

Advisory locks. pg_advisory_lock() acquires a lock tied to a session; in transaction mode your next query may land on a different backend that doesn't hold it. Laravel land examples: some concurrency guards and packages use advisory locks, and schema-migration lock strategies on Postgres can too. Use pg_advisory_xact_lock() (transaction-scoped, safe) or run that code on the direct connection.
SET session variables. Anything doing DB::unprepared("SET statement_timeout = ...") or setting search_path at runtime is configuring a backend another request will inherit, or losing the setting immediately. Use SET LOCAL inside a transaction, or set values per-role with ALTER ROLE ... SET.
LISTEN/NOTIFY. LISTEN is inherently session-bound. Any pgsql pub/sub listener must connect directly to 5432. This is a per-process daemon anyway, so pooling it gains nothing.
Migrations, generally. We simply run php artisan migrate against the direct connection. Migrations are one connection during a deploy; they don't need pooling, and DDL plus session-dependent lock behavior is the exact category of thing you don't want multiplexed.
Prepared statements, only if you're on PgBouncer < 1.21. Upgrade instead of working around it; the emulation flag changes PDO behavior subtly.

If that audit comes back clean, and for most Laravel CRUD apps it does, transaction mode is transparent.

What About MySQL? ProxySQL and Thread Pools

MySQL's cheap threads mean the "too many clients" cliff sits much further out. Raising max_connections from 151 to 500 on a dedicated MySQL box with adequate RAM is a config change, not a project, and it carries nothing like Postgres's per-process penalty. Our honest guidance: most MySQL-backed Laravel apps under roughly 4-5 servers need no middleware at all.

Two situations change that. First, genuinely large fleets, where thousands of connections start to hurt even MySQL through thread scheduling overhead and per-thread buffers. Second, and more commonly, you want capabilities beyond pooling: query routing, read/write splitting to replicas, or query-level failover. That's ProxySQL's (proxysql.com) actual selling point, connection multiplexing comes along for the ride.

ProxySQL is configured through a SQL admin interface rather than a flat file. The minimum viable setup, with a primary in hostgroup 10 and read replicas in hostgroup 20:

-- via mysql -u admin -padmin -h 127.0.0.1 -P 6032
INSERT INTO mysql_servers (hostgroup_id, hostname, port)
VALUES (10, '10.0.0.5', 3306), (20, '10.0.0.6', 3306);

INSERT INTO mysql_users (username, password, default_hostgroup)
VALUES ('laravel', 'secret', 10);

-- Route SELECTs to replicas, keep locking reads on the primary
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*FOR UPDATE', 10, 1),
       (2, 1, '^SELECT', 20, 1);

LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL USERS TO RUNTIME;   SAVE MYSQL USERS TO DISK;
LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;

Laravel then points at ProxySQL on port 6033 exactly as it pointed at PgBouncer on 6432. Note that Laravel's own read/write config arrays can do read/write splitting in-app; ProxySQL does it transparently for every client and adds failover, but if splitting is your only goal, try the framework feature first.

Strengths: Multiplexing, read/write splitting, per-query routing rules, connection admission control, and rich stats tables, all hot-reloadable at runtime.

Best for: MySQL fleets of 4+ app servers, replica setups where you want routing outside the application, and teams that need failover handling between the app and the database.

Considerations: It's a substantially more complex system than PgBouncer, with its own database of config. Multiplexing silently disables itself for sessions using certain features (user variables, SQL_CALC_FOUND_ROWS, transactions in progress), which can surprise you in the stats. Don't deploy it for pooling alone unless connection counts are demonstrably hurting.

Also worth knowing: MariaDB ships a built-in thread pool (thread_handling = pool-of-threads), and Percona Server offers the same, which decouples client connections from worker threads inside the server itself. For "many mostly-idle connections" on MariaDB, enabling the thread pool is a one-line change that postpones any proxy conversation considerably.

How Do Octane and Long-Lived Workers Change the Math?

Laravel Octane inverts the FPM equation. Octane workers are long-lived processes that boot the framework once, and each worker holds its database connection persistently across requests rather than reconnecting per request. Connection churn drops to nearly zero, which is a genuine win, but the connections become permanent occupants, exactly like queue workers.

The math shifts accordingly. Sixteen Octane workers per server across four servers is 64 permanent connections before you count Horizon. The good news: Octane worker counts are usually far lower than equivalent FPM max_children, because each worker is faster. The subtle news: because connections are held while idle, Postgres carries their full process cost around the clock, and PgBouncer's transaction mode helps less than you'd expect for the web tier, since a small warm set of app-held connections was sort of the goal anyway.

Where pooling still earns its keep with Octane: consolidating the web fleet plus queue workers plus scheduler plus deploy tasks behind one budget, and protecting the database when a worker restart storm (deploys, octane:reload) reconnects everything at once. One caveat we've learned to respect: combining Octane's persistent connections with transaction-mode PgBouncer means a session-state mistake persists across many requests instead of one, so the transaction-mode audit above matters more, not less, under Octane.

Queue workers behave the same either way: one held connection per process, forever. Budget them explicitly. If you're planning worker counts alongside app growth, our scaling playbook from 1 to 100,000 users includes connection budgets at each stage.

How Does This Look on Deploynix?

Deploynix provisions a dedicated database server type (MySQL, MariaDB, or PostgreSQL) alongside app and worker server types, on DigitalOcean, Vultr, Linode, Hetzner, AWS, or your own custom servers. The multi-server pattern that triggers this whole topic, an FPM fleet multiplying connections against one database box, is exactly the architecture the platform encourages, so it's worth being explicit about where the pooler fits.

Our recommendation is to install PgBouncer on the database server itself. All servers in a Deploynix architecture talk over private networking, and the platform's firewall rules already lock database access down to your app servers' private IPs; pointing those same rules at 6432 instead of 5432 is the only change. One pooler on the DB box gives you a single pool to size against max_connections, a single SHOW POOLS to watch, and automatic coverage for every app server you add later. Since the database server type gives Postgres the whole machine, PgBouncer's own footprint (a few tens of MB) is negligible next to the backend processes it eliminates.

The alternative, a PgBouncer instance on each app server, has real advocates: connections from FPM to a local pooler over a Unix socket are essentially free, and there's no extra network hop. The cost is N poolers whose default_pool_size values must jointly fit the database's limits, and re-doing that arithmetic every time the fleet grows. For most teams the operational simplicity of one pooler wins; consider per-app-server pooling only when you're chasing the last milliseconds of connection latency.

Two platform details make the rollout less nervy. Queue workers are managed through the UI, so counting your permanent connection consumers is a matter of reading the workers page rather than grepping supervisor configs across servers. And server monitoring shows memory and load on the database box, so you can watch Postgres's footprint drop as backends consolidate after the cutover.

How Do You Monitor the Pool Once It's Running?

An unmonitored pooler just moves the outage one layer up: instead of too many clients, requests queue silently inside PgBouncer. Connect to its admin console and make SHOW POOLS part of your routine:

psql -h 10.0.0.5 -p 6432 -U pgbouncer pgbouncer -c "SHOW POOLS;"

database | user    | cl_active | cl_waiting | sv_active | sv_idle | maxwait
----------+---------+-----------+------------+-----------+---------+---------
 myapp    | laravel |        84 |          0 |        14 |       6 |       0

The columns that matter: cl_active is connected clients, sv_active/sv_idle are real Postgres backends in use and warm, and the two saturation signals are cl_waiting and maxwait. If cl_waiting is persistently above zero and maxwait climbs past a few hundred milliseconds, clients are queuing for backends: raise default_pool_size (checking max_connections headroom first) or go fix whatever made transactions slower, because pool saturation is very often a slow-query symptom wearing a new costume.

Alert on three things: cl_waiting > 0 sustained for more than a minute, maxwait above one second, and total client connections approaching max_client_conn. SHOW STATS adds per-database query and transaction throughput with average times, which is useful for spotting the moment average transaction duration creeps up. On the ProxySQL side, the stats_mysql_connection_pool table plays the same role. Feed whichever you use into the same dashboards as your server metrics; pool saturation next to CPU and memory graphs tells you immediately whether the bottleneck is the pool or the database behind it.

FAQ

Does Laravel have built-in connection pooling?

No. Under PHP-FPM, each worker opens its own connection per request; there's no shared pool to configure in the framework. Octane holds one persistent connection per long-lived worker, which reduces churn but isn't multiplexed pooling. Real pooling for PHP means external middleware: PgBouncer for PostgreSQL, ProxySQL for MySQL.

Should queue workers and Horizon connect through PgBouncer too?

Yes, with one caveat. Workers hold connections permanently, so routing them through transaction-mode PgBouncer lets dozens of mostly-idle workers share a handful of backends, which is a bigger win than the web tier gets. The caveat: jobs using advisory locks or other session state need the transaction-mode audit, or a direct connection.

Can I run migrations through PgBouncer in transaction mode?

Often it works, but we don't recommend it. Migration tooling can rely on advisory locks and session-scoped behavior that transaction pooling breaks in confusing ways. Define a second Laravel connection on port 5432 and run php artisan migrate --database=pgsql_direct. It's one connection during deploys; pooling it saves nothing.

Is pgbouncer worth it on a single-server setup?

Usually not. With app and database on one box, tuned pm.max_children plus default max_connections rarely conflict, and a Unix-socket connection to local Postgres is already cheap. The exception is heavy connection churn under high traffic, where even a local session-mode PgBouncer saves fork overhead. Fix FPM sizing and slow queries first.

What's the MySQL equivalent of "too many clients already"?

ERROR 1040 (HY000): Too many connections, hit when you exceed max_connections (default 151). The first response differs from Postgres: because MySQL threads are cheap, raising the limit to 300-500 on adequate RAM is usually the right move, before considering MariaDB's thread pool or ProxySQL.

Where to Go From Here

The one-hour version of this post: add up your real connection consumers (FPM children × app servers, plus every queue worker, plus Octane and Reverb if you run them), compare the total against your database's max_connections, and check pg_stat_activity for idle-in-transaction waste. If your honest peak sits under 60% of the limit, tune and move on. If it doesn't, or you're about to add app servers, put PgBouncer in transaction mode on the database box, run the session-state audit, and point DB_PORT at 6432.

Do the counting exercise this week, before growth does it for you at 2 a.m. And if the numbers tell you it's time to split your stack properly, start with our guide to building a multi-server Laravel architecture; the connection budget you just calculated is the first input it asks for.

Configuring Valkey Persistence: RDB vs. AOF for Laravel Caching, Sessions, and Queues

Deploynix — Mon, 07 Sep 2026 11:03:03 +0000

A few months ago we helped a team debug a mystery. Their host had rebooted a VPS for maintenance at 3 a.m. The server came back cleanly, Nginx was up, PHP-FPM was up, Valkey was up. Everything looked healthy. Except 4,000 queued jobs, invoices, welcome emails, webhook deliveries, had simply ceased to exist. No errors, no failed_jobs rows, no trace. Valkey had been running with persistence disabled, so every job sitting in those queue lists lived only in RAM. The reboot didn't crash anything. It just quietly forgot.

That's the thing about the persistence decision: most Laravel teams never consciously make it. You install Valkey (or you used to install Redis), point CACHE_STORE, SESSION_DRIVER, and QUEUE_CONNECTION at it, and move on. The defaults you inherited, often just RDB snapshots, or nothing at all inside a container, silently become your durability policy for three workloads with completely different requirements. Losing cache is a shrug. Losing sessions is an annoyance. Losing queues is data loss, full stop.

The timing matters more in 2026 than it used to. Redis 7.2, the last BSD-licensed release line, reached end-of-life on February 28, 2026 (dev.to fork retrospective), and Valkey is now the default in-memory store on AWS ElastiCache. Valkey 9.1, released in May 2026, benchmarks at roughly 2.1 million requests per second with a further ~10% memory reduction over the previous release (DanubeData). Performance is a solved problem. Durability is the part you still have to configure yourself, and this post walks through exactly how.

Key Takeaways- Persistence needs differ per workload: cache can lose everything, queues can lose nothing. - RDB snapshots are cheap but lose minutes of writes; AOF with appendfsync everysec bounds loss to ~1 second. - Hybrid mode (aof-use-rdb-preamble yes) is the modern default for anything durable, and it's on by default in Valkey (Valkey docs). - Run separate Valkey instances for cache and queues, with allkeys-lru for cache and noeviction for queues. - Redis 7.2 hit end-of-life February 2026, so this config now lives in valkey.conf for most of us (dev.to).

What's Actually at Stake When Valkey Loses Its Data?

The blast radius of losing Valkey's dataset depends entirely on what Laravel stores in it. A cold cache costs you seconds of elevated database load. A lost queue costs you real work that customers paid for. Before touching a single config directive, you need to sort your keys into "annoying to lose" versus "unacceptable to lose", because the right persistence mode follows directly from that.

Pure cache. If CACHE_STORE=redis and the instance vanishes, Laravel simply regenerates every cache entry on the next request. Your database eats a thundering herd for a few minutes, response times spike, and then everything settles. For most applications this is a non-event. Persistence for a pure cache is optional, and arguably counterproductive on small servers, because you're paying disk I/O to protect data that was designed to be disposable.

Sessions. With SESSION_DRIVER=redis, losing the dataset logs out every user simultaneously. Nobody's data is corrupted, but every cart is emptied, every multi-step form is reset, and your support inbox knows about it within minutes. This sits in the middle: not catastrophic, but embarrassing enough that some durability is worth a little disk I/O.

Queues. This is the horror story from the intro. Laravel queues on the Redis driver are lists and sorted sets: queues:default, plus the delayed and reserved sorted sets that hold retries and scheduled jobs. There is no upstream copy. If Valkey forgets them, the jobs are gone, and unlike an exception in a worker, nothing lands in failed_jobs, so debugging the disappearance is miserable because there's literally nothing left to debug. Queues demand the strongest persistence you can afford.

Horizon metadata. Horizon stores its dashboard metrics, job history, and supervisor state in the same store as your queues. Losing it resets your graphs and recent-jobs list, which is tolerable, but since it usually shares an instance with queue data, it inherits queue-grade persistence for free.

If you're still weighing whether Valkey is the right engine for these workloads at all, we've covered why Valkey took over from Redis for Laravel caching and queues separately. The short version: for persistence purposes, everything in this post behaves identically to Redis 7.2.

How Does RDB Snapshotting Work?

RDB is Valkey's point-in-time snapshot mechanism, unchanged in concept since early Redis: at configured thresholds, Valkey forks a child process that writes the entire dataset to a compact binary file, dump.rdb, while the parent keeps serving traffic (Valkey docs). The catch is in that sentence twice. "Point-in-time" means everything written after the snapshot is unprotected. "Forks" means a memory and latency cost you must plan for.

The snapshot schedule lives in valkey.conf as save rules, each one meaning "snapshot if at least N changes happened in M seconds":

# /etc/valkey/valkey.conf

# Snapshot after 900s if >=1 key changed,
# after 300s if >=10 changed, after 60s if >=10000 changed
save 900 1
save 300 10
save 60 10000

dbfilename dump.rdb
dir /var/lib/valkey

# Abort writes if the last snapshot failed (safe default)
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

With those defaults, your worst case is losing up to 15 minutes of writes. For a busy queue processing hundreds of jobs a minute, "up to 15 minutes" can mean thousands of jobs. That's the fundamental RDB trade: excellent operational characteristics, weak durability guarantees.

The Fork and Copy-on-Write Spike

Here's the part that bites small VPSes. When Valkey forks, the child shares memory pages with the parent via copy-on-write. Pages only get duplicated when the parent modifies them during the snapshot. Under light write load that's a few megabytes. Under heavy write load, a meaningful fraction of the dataset gets copied, and in the worst case memory usage approaches double the dataset size for the duration of the snapshot.

We've seen this take down a 2 GB droplet running a 1.2 GB Valkey dataset: BGSAVE fires during a traffic spike, copy-on-write balloons, the kernel OOM killer picks a victim, and the victim is Valkey itself. Two mitigations. First, set vm.overcommit_memory = 1 in sysctl so the fork itself never fails. Second, size the server so the dataset stays comfortably under half of RAM if you rely on RDB under write-heavy traffic, and watch latest_fork_usec (more on that below) because fork time also grows linearly with dataset size and stalls the main thread while it runs.

Strengths: Compact single-file backups that are trivial to copy off-server; fastest possible restart times since loading an RDB file is much quicker than replaying a log; minimal steady-state I/O; great fit for disaster-recovery snapshots shipped to object storage.

Best for: Pure cache instances where you'd merely like a warm cache after a planned restart; session stores where losing a few minutes is acceptable; the backup layer underneath AOF in hybrid setups.

Considerations: You will lose everything written since the last snapshot on a crash or hard reboot; fork-based copy-on-write can transiently spike memory toward 2x on write-heavy instances; fork pauses grow with dataset size; the save thresholds mean quiet periods can leave data unprotected for the full 15-minute window.

How Does AOF Persistence Work?

AOF (append-only file) takes the opposite approach: instead of periodic snapshots, Valkey logs every write command to a file as it happens, and on restart replays the log to reconstruct the dataset (Valkey docs). Durability now depends on one question: how often does the log actually reach the disk? That's the appendfsync directive, and it's the single most consequential line in a queue server's config.

# /etc/valkey/valkey.conf

appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"

# fsync policy: always | everysec | no
appendfsync everysec

# Rewrite (compact) the AOF when it doubles in size, min 64mb
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# Don't block writes if a rewrite is fsyncing (trade tiny risk for latency)
no-appendfsync-on-rewrite no

The three appendfsync policies map to three honesty levels about data loss:

always: fsync after every write. You can lose at most one command on a crash, but throughput drops hard because every LPUSH waits on the disk. On commodity VPS storage this can cut write throughput by an order of magnitude. Reserve it for genuinely irreplaceable data where Valkey is the system of record.
everysec: fsync once per second in the background. You lose at most about one second of writes on a hard crash. This is the default and the right answer for almost every Laravel queue. One second of jobs is a bounded, explainable loss; fifteen minutes is not.
no: let the kernel decide, typically flushing every 30 seconds. Barely better than RDB for durability. Skip it.

AOF Rewrites and Restart Times

An append-only log grows forever, so Valkey periodically compacts it. A rewrite forks a child (same copy-on-write caveats as RDB) that writes the minimal set of commands to rebuild the current dataset, while new writes buffer and get appended at the end. The auto-aof-rewrite-* directives above trigger this automatically when the file doubles. Between rewrites, budget real disk for growth: a write-heavy queue instance can add hundreds of megabytes of AOF per day, and a full disk stops Valkey from accepting writes entirely. That failure mode deserves its own runbook, which we wrote up in our guide to disk-space prevention, detection, and recovery.

The other cost is restarts. Replaying a large command log is much slower than loading an RDB snapshot, and on big datasets a pure-AOF restart can take minutes while your workers throw connection refused. Hybrid mode, next, exists precisely to fix this.

Strengths: Bounded, tunable data loss (down to ~1 second with everysec); the log is human-auditable with valkey-check-aof; a partially written tail from a crash can usually be truncated and recovered rather than lost wholesale.

Best for: Queue instances, Horizon metadata, and any dataset where Valkey is the only copy of the data; session stores on applications where mass logout is a real business problem.

Considerations: Larger files and steady write I/O; rewrite forks carry the same copy-on-write memory spike as BGSAVE; slower restarts in pure-AOF form; appendfsync always is usually overkill and can bottleneck queue throughput below what your workers need.

Why Is Hybrid Persistence the Modern Default?

Hybrid persistence gives you RDB's fast restarts and AOF's tight durability in one mode, and Valkey ships it enabled by default whenever AOF is on (Valkey docs). The mechanism is simple: during each AOF rewrite, the child writes the dataset in RDB binary format as a preamble, and only commands received after the rewrite get appended as a plain-text log tail.

# /etc/valkey/valkey.conf

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes

On restart, Valkey bulk-loads the compact RDB preamble, then replays only the short tail of recent commands. Restart times land close to pure RDB while data loss stays bounded by your appendfsync policy. Since the preamble regenerates on every rewrite, file growth stays managed too.

We treat this as the default answer for any instance holding data you can't regenerate. The honest question is no longer "RDB or AOF?" but "does this instance need durability at all?" If yes, hybrid with everysec. If no, RDB alone or nothing. If you're migrating from Redis, note that aof-use-rdb-preamble has defaulted to yes since Redis 5, so many teams are already running hybrid without knowing it, which is one of the few pleasant surprises in this area.

Strengths: Near-RDB restart speed with AOF-grade durability; automatic compaction keeps disk usage predictable; it's the upstream default, so you're not fighting the tooling.

Best for: Queue and Horizon instances, which is to say, the instance whose loss would have made this article's intro about you.

Considerations: Still fork-based rewrites, so the copy-on-write memory math still applies; the AOF file's mixed binary/text format means you can't casually grep the preamble portion; requires AOF enabled, so pure-RDB-only setups need two directive changes, not one.

RDB vs. AOF vs. Hybrid vs. No Persistence: The Comparison

One table, four options, the trade-offs that actually matter on a production Laravel box:

RDB only

AOF only (everysec)

Hybrid (RDB preamble + AOF)

No persistence

Max data loss (crash)

Up to full save interval (minutes)

~1 second

Everything

Restart speed

Fast

Slow (full log replay)

Fast (bulk preamble + short tail)

Instant (empty)

Steady-state disk I/O

Bursty (snapshot only)

Continuous appends

None

Disk footprint

Small, compact

Large between rewrites

Moderate, managed

None

Fork memory spike

Yes (BGSAVE)

Yes (rewrite)

Backup story

Excellent (copy one file)

Workable

Good

N/A

Fit for Laravel queues

Risky

Good

Recommended

Never

Fit for pure cache

Fine (warm restarts)

Wasteful

Fine

Read the first row twice. It's the row the 3 a.m. reboot cares about.

Which Persistence Mode Fits Each Laravel Workload?

The clean answer is per-workload, which means the clean architecture is per-instance. Here's the recommendation table we apply to our own infrastructure:

Laravel workload

Persistence

appendfsync

maxmemory-policy

Notes

Cache (CACHE_STORE=redis)

None, or RDB only

n/a

allkeys-lru

Cold cache is a performance blip, not data loss

Sessions (SESSION_DRIVER=redis)

Hybrid

everysec

noeviction

Evicted sessions = random logouts under memory pressure

Queues (QUEUE_CONNECTION=redis)

Hybrid

everysec (or always for payments-grade jobs)

noeviction

The one you cannot get wrong

Horizon metadata

Hybrid (shares queue instance)

everysec

noeviction

Inherits queue settings

Broadcasting (Reverb pub/sub)

None

n/a

Pub/sub messages are never stored; persistence is irrelevant

Separate Instances Beat SELECT n

Laravel's default config/database.php nudges you toward one Valkey server with logical databases: default on database 0, cache on database 1, selected via SELECT n. That works, but it forces one persistence policy and one eviction policy onto every workload, because both appendonly and maxmemory-policy are server-wide, not per-database. You can't snapshot database 1 casually while fsyncing database 0 religiously. In our experience, logical databases are how teams end up with cache-grade durability protecting their queues without realizing it.

Running two valkey-server processes on different ports (or a dedicated cache host) costs a few megabytes of overhead and buys you independent persistence, independent eviction, independent maxmemory, and independent restarts. Restarting a misbehaving cache instance no longer risks your queue backlog. We covered wiring multiple connections into Laravel's queue config in our queues deep dive on connections, workers, and retry strategies, and the pattern is a few extra lines in config/database.php pointing each connection at its own port.

The Eviction Policy Trap

Persistence protects you from restarts. Eviction policy protects you from memory pressure, and it can destroy queue data while the server stays up. With maxmemory set and allkeys-lru active, Valkey evicts the least-recently-used keys when memory fills. On a cache, that's the whole point. On a queue instance, "least recently used" can be the list holding your job backlog, and Valkey will delete it silently to make room for new writes. No crash, no restart, jobs gone, persistence intact and faithfully persisting the deletion.

# Cache instance
maxmemory 512mb
maxmemory-policy allkeys-lru

# Queue instance: refuse writes rather than evict jobs
maxmemory 1gb
maxmemory-policy noeviction

With noeviction, a full queue instance rejects new writes with an error your application can actually see and alert on. A visible failure beats silent data loss every time.

How Persistence Works on Deploynix Servers

When Deploynix provisions servers, on DigitalOcean, Vultr, Linode, Hetzner, AWS, or a custom box, Valkey shows up in two places, and the separate-instances advice above maps directly onto them. Every app server includes a local Valkey instance alongside Nginx, PHP 8.4, and Supervisor, the stack we described in setting up a production-ready Laravel stack. And the dedicated cache server type runs Valkey as its sole job, TLS-enabled out of the box, so cache traffic between your app servers and the cache host is encrypted in transit without extra certificate wrangling.

That two-tier layout gives you the split for free: keep the pure cache on the dedicated cache server with allkeys-lru and light or no persistence, and keep queues on the app server's local instance (or a second dedicated instance) with hybrid persistence and noeviction. Database servers (MySQL, MariaDB, PostgreSQL) stay on their own boxes, so a fork-related memory spike on the Valkey side never competes with InnoDB's buffer pool.

On a provisioned server, the config lives at /etc/valkey/valkey.conf and the service runs under systemd as valkey. For applying changes, we'd suggest this order of preference. First, runtime changes with CONFIG SET, which take effect instantly with zero downtime:

valkey-cli CONFIG SET appendonly yes
valkey-cli CONFIG SET appendfsync everysec
valkey-cli CONFIG SET maxmemory-policy noeviction
valkey-cli CONFIG SET save "900 1 300 10 60 10000"

# Persist the runtime state back into valkey.conf
valkey-cli CONFIG REWRITE

CONFIG REWRITE is the step people forget: without it, your carefully applied runtime settings evaporate on the next restart, which is a particularly ironic way to lose your persistence config. If you edit valkey.conf by hand instead, restart deliberately, and only after confirming a fresh snapshot or AOF sync exists, because restarting a non-persistent instance is exactly the reboot scenario from the intro, self-inflicted. Deploynix's server monitoring also raises memory and disk alerts, which is where fork spikes and AOF growth surface first in practice; a memory alert that coincides with rdb_bgsave_in_progress:1 tells you the copy-on-write math is getting tight. Queue workers themselves are managed from the UI, so once the underlying store is durable, restarting workers after a deploy doesn't touch the data layer at all.

How Do You Monitor and Test Persistence in Production?

A persistence config you've never tested is a hypothesis, not a safety net. Two habits close the gap: watch the right metrics continuously, and rehearse the restart before reality schedules one for you.

INFO persistence is the primary instrument:

valkey-cli INFO persistence

# Persistence
loading:0
rdb_changes_since_last_save:1204
rdb_bgsave_in_progress:0
rdb_last_save_time:1754121600
rdb_last_bgsave_status:ok
aof_enabled:1
aof_rewrite_in_progress:0
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
latest_fork_usec:41250

Four fields earn alerts. rdb_last_bgsave_status and aof_last_write_status must be ok; anything else means snapshots or fsyncs are failing, usually because the disk is full, and with stop-writes-on-bgsave-error yes your application is about to find out loudly. rdb_changes_since_last_save tells you exactly how many writes are currently unprotected by RDB, useful for judging whether your save thresholds match reality. And latest_fork_usec is your fork-cost gauge: it reports the last fork's duration in microseconds, and since the entire server stalls during the fork itself, a value creeping past ~500,000 (half a second) on a growing dataset is an early warning that snapshot pauses will soon be user-visible.

LASTSAVE gives you a quick freshness check, and pairing it with BGSAVE makes a tidy pre-maintenance ritual:

# Unix timestamp of the last successful RDB save
valkey-cli LASTSAVE

# Force a snapshot now, then confirm the timestamp advanced
valkey-cli BGSAVE
valkey-cli LASTSAVE

Then there's the test almost nobody runs: the controlled durability drill. On a staging box, or during a quiet window with a maintenance page up, push a handful of marker jobs onto a queue, restart the service, and count them afterward:

valkey-cli LPUSH queues:durability-test job1 job2 job3
sudo systemctl restart valkey
valkey-cli LLEN queues:durability-test   # expect: 3
valkey-cli DEL queues:durability-test

If the count comes back 0, your persistence config is theater, and you've learned it for the price of three fake jobs instead of four thousand real ones. While you're at it, verify disk headroom for AOF growth: ls -lh /var/lib/valkey/appendonlydir weekly, or let disk alerts do it for you. One more production note: if your Valkey instance is reachable over the network rather than localhost, TLS isn't optional, since queue payloads routinely contain user data; terminate it in Valkey itself (tls-port, tls-cert-file, tls-key-file) rather than bolting on a proxy.

What Changes If You're Migrating From Redis?

Nothing, and that's the point. Valkey is wire-compatible with Redis on both RESP2 and RESP3, and every directive in this article, save, appendonly, appendfsync, aof-use-rdb-preamble, maxmemory-policy, carries over character for character (dev.to fork retrospective). Your existing redis.conf persistence block can be pasted into valkey.conf unmodified, and Valkey will even load an existing dump.rdb or AOF directory produced by Redis 7.x, which makes the migration itself a stop-copy-start operation rather than a data export.

Laravel doesn't notice either: phpredis and Predis speak to Valkey exactly as they spoke to Redis, so config/database.php needs a host change at most. With Redis 7.2 past its February 2026 end-of-life and Valkey 9.1 posting ~2.1M requests/second with another ~10% memory trim (DanubeData), the migration question has mostly answered itself; the compatibility details, RESP protocol versions, data formats, module edge cases, are in our technical deep dive on Valkey vs. Redis compatibility if you want the full audit before switching.

FAQ

Can I just enable both RDB and AOF instead of hybrid mode?

Yes, and it's a legitimate setup: AOF drives recovery (Valkey prefers it on restart because it's more complete), while standalone RDB snapshots give you clean, compact files to ship off-server as backups. Hybrid mode with aof-use-rdb-preamble yes additionally embeds the RDB format inside the AOF for fast restarts, and the three directives coexist happily. Most durable production instances end up running all of it.

How much data do I actually lose with appendfsync everysec?

At most about one second of acknowledged writes, and only on a hard crash or power loss, not on a clean systemctl restart, which fsyncs on shutdown. For a queue pushing 50 jobs per second, that's a worst case of ~50 jobs, versus thousands under RDB's multi-minute windows. If even one second is unacceptable, use appendfsync always for that instance and accept the throughput cost, or reconsider whether that workload belongs in a database-backed queue instead.

Do I need persistence on a cache-only Valkey instance?

No, and skipping it is often the better call: you save the fork spikes, the disk I/O, and the restart-time snapshot loading. The one argument for RDB on a cache is warm restarts, since reloading a recent snapshot avoids the thundering-herd effect of a fully cold cache after planned maintenance. If your database shrugs off a cold cache, run the cache instance with no persistence and a clear conscience.

Why is noeviction safe for queues? Won't Valkey just fall over when memory fills?

It refuses writes with an explicit error, which your application sees as a failed dispatch, something you can catch, retry, and alert on. That's the failure mode you want, because the alternative under allkeys-lru is Valkey silently deleting your backlog to make room. Pair noeviction with a maxmemory set well below server RAM (leaving fork headroom) and a memory alert, and a filling queue instance becomes a paged engineer instead of a postmortem.

Does any of this apply to Laravel Reverb broadcasting?

Mostly no. Broadcasting rides on pub/sub, and pub/sub messages pass through Valkey without ever being stored, so no persistence mode retains them; a subscriber that's offline misses the message regardless. The only broadcast-adjacent data worth persisting is whatever your app stores about presence or state in regular keys, which follows the normal cache-or-durable decision like everything else.

Where to Start This Week

The whole decision compresses into three moves. Split cache from queues so each gets its own policy: separate instances, not SELECT n. Give the queue instance hybrid persistence (appendonly yes, appendfsync everysec, aof-use-rdb-preamble yes) with noeviction, and let the cache instance stay fast and disposable with allkeys-lru. Then prove it: run the marker-job restart drill and watch INFO persistence come back clean.

Your next step is a five-minute audit that costs nothing: run valkey-cli CONFIG GET appendonly and valkey-cli CONFIG GET maxmemory-policy against whatever instance backs your production queues, today. If the answers are no and allkeys-lru, you're one host reboot away from the story this post opened with, and now you know exactly which four lines of valkey.conf fix it.

SOC 2 for a Laravel SaaS: What Infrastructure Evidence You'll Actually Need

Deploynix — Sat, 05 Sep 2026 11:03:05 +0000

The deal was almost done. A mid-market company loved your Laravel product, the champion had budget approval, and the contract was sitting in legal. Then procurement sent over a security questionnaire with 240 questions, and question three asked: "Please attach your most recent SOC 2 Type II report." You don't have one. The deal doesn't die, but it stalls, and every week it sits in review is a week your competitor with a report in hand looks safer to buy from.

If you're a small Laravel team, this is almost always how SOC 2 enters your life. Not through regulation, not through a security incident, but through a sales blocker. And the way it's usually explained, by auditors, for auditors, makes it sound far more mystical than it is. Strip away the vocabulary and SOC 2 is a structured way of answering one question: can you prove that you actually operate the security controls you claim to operate?

The good news is that a well-run VPS-based Laravel stack already produces most of the evidence an auditor wants. Key-only SSH, firewall rules, git history, deploy logs, automated backups, monitoring alerts: these aren't compliance artifacts bolted on later, they're the exhaust of running production responsibly. The hard part isn't doing the work. It's capturing proof that you did it, continuously, for months.

This post walks through SOC 2 the way we'd want it explained to us as engineers: when you actually need it, what evidence maps to what criteria, where teams get caught out (restore drills, offboarding), and what a realistic timeline looks like for a team of two to ten people.

Key Takeaways- SOC 2 is an AICPA framework audited by licensed CPA firms; only the Security criterion is mandatory in scope. - Type I assesses control design at a point in time; Type II proves operation over a 3-12 month window. - Auditors want evidence, not claims: restore logs beat backup configs, access reviews beat access policies. - A hardened VPS Laravel stack already generates most required evidence if you capture it.

What Is SOC 2, and When Does a Laravel SaaS Actually Need One?

SOC 2 is an attestation framework created by the AICPA, the American Institute of Certified Public Accountants. It is not a certification you self-declare and not a government regulation. A licensed CPA firm examines your controls and issues a report stating whether those controls are designed properly and, for Type II, whether they operated effectively over an observation period.

The framework is built on five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Only Security is mandatory. The other four are optional scope you add based on what your customers care about. Most small SaaS companies start with Security alone or Security plus Availability, because those are the two that enterprise procurement teams actually ask about. Adding Privacy or Processing Integrity expands the audit surface considerably, and unless your buyers demand it, there's little reason to volunteer for it in year one.

So when do you need it? Honestly: when sales tells you that you do. SOC 2 is an enterprise sales gate, not a legal requirement. If you sell to individual developers and small agencies, nobody will ever ask. The moment your average contract value climbs into the range where procurement departments get involved, the questionnaires start, and "we take security seriously" stops being an acceptable answer. If you're seeing security questionnaires on more than one deal per quarter, or a specific large deal is blocked on it, that's your signal. Before that point, your time is better spent on the underlying security work itself, which is why we'd point any Laravel team at a production security checklist long before an audit is on the calendar. Everything you fix now becomes evidence later.

One more thing worth internalizing early: SOC 2 doesn't prescribe specific technology. There is no rule that says "use AWS" or "use this framework." The auditor evaluates whether your controls meet the criteria, not whether your stack matches some enterprise template. A Laravel monolith on a well-managed VPS can pass the same audit as a Kubernetes fleet, and often with a cleaner story, because there's less surface to explain.

Type I or Type II: Which Report Should You Get First?

The two report types answer different questions, and the difference matters more than most first-timers realize.

Type I

Type II

What it assesses

Control design at a single point in time

Control operating effectiveness over a period

Observation window

None (snapshot date)

Typically 3-12 months

Auditor asks

"Do these controls exist and make sense?"

"Did these controls actually run, every time, all period?"

Evidence burden

Policies, configurations, one-time screenshots

Continuous logs, tickets, reviews, drill records

Time to obtain

Weeks after readiness

Observation window plus audit time

Weight with enterprise buyers

Moderate; often accepted as a bridge

Strong; the default procurement ask

Typical use

First-year milestone while Type II window runs

The report you renew annually

Type I

Strengths: Fast to obtain once your controls are designed and documented. Gives sales something real to attach to a questionnaire within weeks instead of months. Forces you to write down policies and close obvious gaps.

Best for: Teams with an enterprise deal stalling right now who can't wait out an observation window, or teams using it as a forcing function to get their house in order.

Considerations: Sophisticated buyers know a Type I only proves your controls existed on one day. Some procurement teams accept it as a bridge with a committed Type II date; others won't. Budget-wise you're paying for two audits in your first year if you do both.

Type II

Strengths: The report buyers actually want. Proves your controls operated over a real window, which is a fundamentally stronger claim. Renewing it annually becomes routine once evidence collection is automated.

Best for: Teams that can start their observation window now and close enterprise deals in six to twelve months, or teams whose buyers have explicitly said Type I won't cut it.

Considerations: The observation window is a minimum wait, not a formality. A control that lapsed for three weeks mid-window becomes an exception in your report. You need evidence discipline for the entire period, which is exactly where compliance automation platforms earn their fee.

The pragmatic path we see most small teams take: start the readiness work immediately, open a Type II observation window as soon as controls are stable, and optionally grab a Type I along the way if a specific deal demands paper sooner.

What Infrastructure Evidence Do Auditors Actually Ask For?

Here's the part nobody explains well. Auditors don't inspect your servers. They request evidence: exports, logs, screenshots, tickets, and records that demonstrate each control operated. For a VPS-based Laravel stack, the mapping looks like this.

Trust Services Criterion

In scope?

Concrete infrastructure evidence from a Laravel VPS stack

Security

Mandatory

SSH key inventories, firewall rules, fail2ban logs, patching records, access review sign-offs, deploy logs, encrypted secrets configuration

Availability

Common add-on

Uptime monitoring history, alert logs, backup schedules, restore drill records, incident post-mortems, rollback records

Confidentiality

Common add-on

Encryption-at-rest evidence, TLS configuration, access scoping by role, data classification notes

Processing Integrity

Rare for small SaaS

Job queue monitoring, data validation controls, reconciliation records

Privacy

Rare; overlaps GDPR

Data retention schedules, deletion records, subprocessor list, server location documentation

If you've already done GDPR work, some of this will feel familiar; our post on GDPR for Laravel developers covers the data-location and deletion side, and that documentation is reusable if you ever add Privacy to scope. Now let's go domain by domain through what the Security and Availability criteria actually demand from your infrastructure.

Access Control: Who Can Touch Production, and How Do You Know?

This is the first thing every auditor probes, and the first place small teams fail. The questions are simple. Who has SSH access to production? How is it granted? How is it revoked when someone leaves? Can two people be told apart in your logs?

The engineering answers are ones you should already have: key-only SSH with password authentication disabled, no shared root credentials, one key per human, and a defined offboarding step that removes keys and platform access on the person's last day. The evidence answers are the exports that prove it. A dump of authorized_keys entries mapped to named people. A record showing the departed contractor's key was removed within your stated window. Quarterly access review sign-offs where someone actually looked at the list and confirmed everyone on it still belongs there.

Shared accounts are the classic finding here. If three engineers all log in as deploy with the same key, your logs can't attribute actions to individuals, and the auditor will flag it. Individual keys plus a platform layer with per-user accounts and roles solves this cleanly. Offboarding is the second classic finding: teams that have never once removed an ex-employee's access, because nobody ever left before, discover mid-audit that they have no process and no record.

Change Management: Can You Show How Code Reaches Production?

Auditors want to see that changes to production are authorized, reviewed, and traceable. If you're using git with pull requests, you already run a change management system; you just haven't been calling it that.

Your git history is the change record. PR reviews are the authorization step. Deploy logs, with timestamps, the deploying user, and the commit deployed, tie the change record to production. Rollback capability is your answer to "what happens when a change goes wrong," and a log showing you actually rolled back a bad deploy is better evidence than any policy paragraph about rollback procedures.

What trips teams up: direct pushes to main with no review, hotfixes applied by SSHing in and editing files on the server (which bypasses the entire change record), and deploys with no log of who triggered them. The fix isn't process theater. It's making the pipeline the only path to production and letting the pipeline's own logs be your evidence.

# A surprising amount of change-management evidence is one command away
git log --merges --since="2026-01-01" --pretty=format:"%h %an %ad %s" --date=short

# Show that branch protection forces review (GitHub CLI)
gh api repos/OWNER/REPO/branches/main/protection --jq '.required_pull_request_reviews'

Vulnerability Management: How Do Patches Actually Happen?

The control here is a patching routine that runs whether or not anyone remembers it. On Ubuntu, that means unattended security upgrades, and the evidence is the configuration plus the logs showing it ran.

# Confirm unattended upgrades are enabled
cat /etc/apt/apt.conf.d/20auto-upgrades
# APT::Periodic::Update-Package-Lists "1";
# APT::Periodic::Unattended-Upgrade "1";

# Evidence that it has actually been running
grep "Packages that will be upgraded" /var/log/unattended-upgrades/unattended-upgrades.log | tail -20

On the application side, composer audit checks your dependency tree against known advisories, and running it in CI on every build turns it from a good habit into a logged, recurring control:

composer audit --format=json > audit-$(date +%F).json

Keep the outputs. A folder of dated audit results showing you scanned weekly and remediated findings is exactly the kind of evidence that makes a Type II observation window painless. Auditors also like to see that findings go somewhere: a ticket that says "bumped guzzlehttp/psr7 for advisory X, deployed on this date" closes the loop from detection to fix to production.

Backup and Recovery: Auditors Want Restore Evidence, Not Backup Evidence

Read that heading twice, because this is the single most common gap we see. Teams show auditors a backup schedule and a bucket full of dumps and consider the control satisfied. The auditor's next question: "Show me the last time you restored one."

A backup you've never restored is a hypothesis. The control auditors actually care about is recoverability, and the evidence is a restore drill record: a dated log showing someone pulled a backup, restored it to a scratch database, verified row counts or ran the test suite against it, and recorded how long it took. Do this quarterly, write down the date, duration, and outcome each time, and you've turned twenty minutes of work into some of the strongest Availability evidence in your report.

# A minimal quarterly restore drill, logged
aws s3 cp s3://backups/db/latest.sql.gz ./drill/ --endpoint-url $S3_ENDPOINT
gunzip drill/latest.sql.gz
mysql -h 127.0.0.1 restore_drill < drill/latest.sql
mysql -h 127.0.0.1 restore_drill -e "SELECT COUNT(*) FROM users; SELECT MAX(created_at) FROM orders;"
echo "$(date -u +%FT%TZ) restore drill OK, 14m22s, verified users+orders tables" >> drills.log

Retention matters too: state a retention policy (say, 30 daily backups) and be able to show the bucket actually reflects it. If you want the full setup, our guide on automated database backups covers schedules, retention, and off-server storage; the drill habit is what upgrades that setup from good practice to audit evidence.

Monitoring and Incident Response: What Happens When Things Break?

The Availability criterion wants proof that you detect problems and respond to them in a structured way. Three artifacts cover most of it: monitoring with alert history, a written incident response playbook, and post-mortems for incidents that actually happened.

Alert history is the underrated one. A log of every alert fired over the observation window, with timestamps showing when it fired and when it resolved, demonstrates that your monitoring is real and that someone responds. A playbook doesn't need to be long; ours fits the shape we described in the incident response playbook for server outages: detect, triage, communicate, fix, review. What matters to an auditor is that it exists, names roles, and that your post-mortems reference it.

And here's a counterintuitive tip from the trenches: incidents help your audit. A team with two documented incidents, each with a post-mortem and a follow-up fix, tells a stronger story than a team claiming a spotless record with no evidence their process has ever been exercised. Don't hide your outages from the auditor. Show them the paper trail.

Encryption: In Transit, at Rest, and in Your Secrets

The expectations here are unambiguous. TLS on every public endpoint, with certificates that renew automatically. Secrets not sitting in plaintext in a repo or a shared doc. Backups encrypted before they land in object storage. Provider API tokens and SSH private keys encrypted at rest wherever they're stored.

For a Laravel app, the secrets story deserves specific attention because .env files are the soft underbelly of most stacks. Laravel's encrypted environment files (php artisan env:encrypt) and a defined process for who can read production secrets go a long way; we wrote up the full approach in secrets management for Laravel. Evidence-wise, the auditor wants your TLS configuration (an SSL Labs result or certificate inventory works), your encryption-at-rest description for the database and backups, and your answer to "who can see production credentials, and how is that access logged?"

The firewall and intrusion-prevention layer rounds out the Security picture, and the evidence is literally command output:

ufw status verbose
# Status: active
# Default: deny (incoming), allow (outgoing)
# 22/tcp  ALLOW IN  Anywhere
# 80,443/tcp  ALLOW IN  Anywhere

fail2ban-client status sshd
# |- Currently banned: 3
# `- Total banned: 412

That Total banned counter, captured monthly, is a tidy little proof that the control isn't just configured but actively working.

The Gap Between "We Do This" and "We Can Prove We Do This"

Every domain above has the same failure mode. The engineering is done, the control operates, and yet the audit is painful, because nothing was captured. Closing that gap is mostly about building three habits before your observation window opens, not after.

First, prefer pulled evidence over posed evidence. A screenshot of a firewall config proves the config existed the moment you took the screenshot. A log exported from an API proves the control operated over time, can't be quietly staged, and doesn't require a human to remember anything. Wherever your infrastructure can emit evidence programmatically, wire that up; save screenshots for the handful of things that have no export. This is also the core value proposition of compliance automation platforms like Vanta, Drata, and Secureframe: they connect to your systems and collect evidence continuously so the observation window documents itself.

Second, run quarterly access reviews and write them down. Fifteen minutes, four times a year: list everyone with production access, SSH keys, database credentials, and admin roles in your platform tooling; confirm each person still needs it; remove what's stale; record who reviewed and when. This single ritual satisfies a surprising number of audit requests, and it's the ritual most teams skip because "we're only four people, we know who has access." The auditor doesn't know that, and in a year you won't remember either.

Third, keep policies short and true. You will need written policies: information security, access control, change management, incident response, business continuity. The temptation is to download a 40-page template and adopt it wholesale. Resist it. Auditors test whether you follow your policies, so every aspirational sentence you didn't need becomes a control you can fail. A two-page policy that accurately describes what your team actually does will serve you better than an impressive binder describing a company you aren't. Write down reality, then improve reality, then update the document.

If you want a structured way to find the gaps before an auditor does, a self-run security audit of your own servers is the closest thing to a dress rehearsal: every item you verify is an item you now know how to evidence, and every item you can't verify just told you where your first exception would come from.

How Deploynix Features Double as Audit Evidence

We built Deploynix as a provisioning and deployment platform, not a compliance product. But somewhere around the third customer who asked us for evidence exports, we realized that a platform which manages your servers is, almost by accident, an evidence collection system. Here's the honest mapping.

Access control. Deploynix teams have organization roles, so "who can deploy to production" is a defined, reviewable list rather than tribal knowledge, and the quarterly access review becomes reading one screen. Servers are provisioned with key-only SSH from day one, so there's no password-auth finding waiting to happen.

Audit trail. Every server action taken through the platform, provisioning, deploys, config changes, is recorded in server logs with the acting user and timestamp. That's the attributable, per-person action history the access control and change management criteria both lean on.

Change management. Deploys are logged with commit, user, and time, which turns each release into a change record that reconciles against your git history. Zero-downtime deploys with rollback give you the "what happens when a change is bad" answer, and a rollback that actually happened is sitting right there in the deploy log as evidence.

Vulnerability management. Unattended security upgrades are enabled by default on provisioned servers, alongside UFW in deny-by-default mode and fail2ban. The hardened baseline isn't something you configure for the audit; it's the starting state.

Backup and recovery. Automated database backups run on schedule to S3-compatible storage with retention, giving you the schedule and retention evidence directly. The restore drills are still on you, and they should be; no platform can honestly automate away the act of verifying your own recoverability.

Monitoring. Server monitoring keeps alert history with 30-day metric retention, so "show me your alerting worked during the window" is an export rather than an archaeology project.

Encryption. Provider credentials and SSH private keys are encrypted at rest in the platform, which is one line in your confidentiality narrative you don't have to build yourself.

Everything above is also reachable through the API, which matters more than it sounds: when your auditor or your compliance automation platform asks for evidence, a scripted export beats an afternoon of screenshots every single time. None of this makes you SOC 2 compliant on its own; no tool does. It means the infrastructure layer of your evidence list is largely handled, and your remaining work concentrates on policies, reviews, drills, and the application layer.

How Long Does It Take, and What Does It Cost?

Plan in months, not weeks, and plan for two cost centers: the auditor and the tooling.

A realistic sequence for a small Laravel team looks like this. One to two months of readiness work: hardening gaps, policies, access reviews started, evidence collection wired up. Then the Type II observation window opens, typically three months for a first report (buyers sometimes discount a three-month window; six or twelve carries more weight on renewal). During the window, your job is simply to keep the controls running and the evidence flowing. After the window closes, the CPA firm performs fieldwork and writes the report, which adds several more weeks. End to end, six to nine months from "we should do this" to a Type II PDF in the sales team's hands is a sane expectation. Teams that need paper sooner slot a Type I in after readiness.

On cost, we'll stay general rather than quote numbers that vary widely by firm and scope: you're paying a licensed CPA firm for the audit itself, usually annually, plus a subscription if you use a compliance automation platform. Together they're a meaningful line item for a small company, which is exactly why the trigger should be real enterprise demand rather than ambient anxiety.

Compliance automation platform (Vanta, Drata, Secureframe)

Strengths: Continuous, API-pulled evidence collection; policy templates; auditor marketplaces; dramatically less manual gathering during the window.

Best for: Teams going for Type II who want the observation window to document itself, and teams without a dedicated compliance person, which is every small team.

Considerations: A real recurring cost, and the templates still need editing down to your reality. The platform collects evidence; it doesn't operate your controls for you.

Manual evidence collection

Strengths: No subscription cost. Forces deep familiarity with your own controls. Viable for a Type I with narrow scope.

Best for: Teams testing the waters with a Type I, or teams whose auditor provides a simple evidence request list and whose stack is small.

Considerations: For a Type II window, manual collection means months of remembering to capture things on schedule. One forgotten month is an exception in your report. Most teams that start manual switch before renewal.

What Do Auditors Not Care About?

Knowing what's out of scope saves real anxiety, so let's clear a few things up.

They don't care that you use Laravel. Framework choice is invisible to the criteria. Nobody loses points for PHP, and nobody gains points for Rust. The auditor cares whether changes are reviewed, dependencies are scanned, and secrets are protected, in whatever stack you run.

They don't care which cloud or VPS provider you use. DigitalOcean, Hetzner, AWS, a European provider chosen for data residency: all fine. What they'll ask for is your subprocessor list and your providers' own compliance reports (major infrastructure providers publish these), which slot into your evidence as inherited controls.

They don't care that your team is small. There's no minimum headcount for SOC 2. Small teams do face specific friction, like separation of duties when the person writing code is also the person approving deploys, but auditors handle this constantly and there are accepted compensating controls, like logged self-review with after-the-fact spot checks.

And they don't care about perfection. A report can include exceptions and still be valuable; a noted exception with a documented remediation reads as a functioning program, not a failing one. The report is a narrative of how you operate, not a pass/fail exam with a trophy at the end.

FAQ

Do we need SOC 2 if we're a two-person Laravel startup?

Not until your buyers ask for it. SOC 2 is a sales instrument, not a legal obligation. Do the underlying security work now, start keeping evidence habits early because they're cheap, and pull the trigger on an audit when enterprise questionnaires start arriving or a specific deal is gated on a report.

Can we pass SOC 2 on a VPS, or do we need a big cloud provider?

You can absolutely pass on a VPS. The criteria are provider-agnostic; auditors evaluate your controls, not your vendor's logo. You'll list your infrastructure provider as a subprocessor and reference their compliance documentation, then evidence your own layer: access, patching, backups, monitoring, and change management.

Type I first or straight to Type II?

If no deal is burning, go straight for Type II: start the readiness work, open a three-month observation window, and you'll have the stronger report in roughly two quarters. If a deal is stalled today, a Type I plus a committed Type II date is a common and often accepted bridge.

What's the most commonly missing piece of evidence?

Restore drills. Nearly every team can show backups exist; far fewer can show a dated record of restoring one and verifying the data. Quarterly drills with a one-line log entry each are the cheapest audit win available. Second place goes to offboarding records and quarterly access reviews.

Does using Deploynix make us SOC 2 compliant?

No, and be wary of any tool that claims otherwise. Deploynix gives you a hardened default baseline and exportable evidence for the infrastructure layer: action logs, deploy history, backup schedules, alert history. Policies, access reviews, drills, and the audit itself remain your work with a CPA firm.

Where to Start This Week

You don't start SOC 2 by calling an auditor. You start it by making your infrastructure provably boring: attributable access, logged changes, automatic patching, tested restores, and monitoring with a paper trail. Everything in this post compounds; evidence habits started this quarter are observation-window gold next year, and every gap you close is one less finding when a CPA firm finally looks.

If you do one thing this week, make it a dry run: work through a step-by-step security audit of your server, and for every control you verify, ask the auditor's question instead of the engineer's one. Not "does this work?" but "could I prove this worked in March?" The distance between those two answers is your entire SOC 2 project, measured honestly, before anyone bills you for the measuring.

DigitalOcean vs. Vultr vs. Linode for Laravel: A Price and Performance Breakdown

Deploynix — Thu, 03 Sep 2026 16:46:53 +0000

Ask around any Laravel community where people host and you'll hear the same three names, with DigitalOcean usually first — a split that has less to do with performance than with marketing budgets and muscle memory. All three providers sell the same basic product: a KVM virtual machine with NVMe or SSD storage, a public IP, and an API. The differences that actually matter for a Laravel app hide in the details, and in 2026 those details are no longer on the pricing page headline.

Here's the thing we've noticed provisioning servers on all three providers week in, week out: the entry prices have converged almost completely. Vultr's cheapest Cloud Compute plan costs $4 per month for 0.5 GB of RAM and 10 GB of NVMe storage, DigitalOcean's basic Droplet also starts around $4, and Linode's minimum sits near $5 but ships with a full 1 GB of RAM, the best price-to-memory ratio at the bottom tier (Valebyte comparison, 2026). A dollar here or there won't decide anything. Egress fees, snapshot pricing, backup surcharges, and managed database costs will.

So this isn't a generic VPS review. It's a Laravel-specific breakdown: what your app actually demands from a virtual machine, which provider wins at each budget, where the hidden costs live, and a real verdict for three common situations. If you want the wider decision framework first, our guide to choosing a cloud provider in 2026 covers the full field. Here, we're putting just these three head to head.

What Does a Laravel App Actually Need From a VPS?

A Laravel app has a specific resource profile, and it's not the one most VPS marketing targets. Independent testing at VPSBenchmarks shows all three providers trading blows on synthetic CPU scores, but Laravel cares about four things in a particular order: single-core speed, disk IOPS, RAM headroom, and egress allowance.

Single-core speed for PHP-FPM. PHP executes one request on one core. A request that takes 80ms on a fast core takes 140ms on a slow one, and no amount of extra cores fixes that for an individual user. This is why Vultr's High Frequency line and DigitalOcean's Premium (Intel/AMD) Droplets exist: same specs on paper, noticeably faster clock speeds and NVMe under load. When you benchmark, run a single-threaded test, not just a multi-core score.

NVMe IOPS for MySQL. Your database is the usual bottleneck in a Laravel app, and MySQL under write load is brutally sensitive to storage latency. All three providers now offer NVMe on their current-generation plans, but older "regular" tiers on Vultr and standard Droplets on DigitalOcean still use plain SSD. A quick way to check what you actually got:

fio --name=randwrite --ioengine=libaio --iodepth=16 \
    --rw=randwrite --bs=4k --size=1G --numjobs=1 \
    --direct=1 --runtime=30 --group_reporting

As a rough expectation rather than a hard rule: tens of thousands of random write IOPS is comfortable for a small production MySQL instance, while results in the low thousands will make themselves felt in queue processing and migrations. Compare your own numbers across the tiers you're considering — the relative gap matters more than any absolute threshold.

RAM headroom. PHP-FPM workers, OPcache, MySQL's buffer pool, and Redis or Valkey all compete for memory. On a 1 GB box you're rationing. On 4 GB you can give MySQL a real buffer pool and still run 10 to 15 FPM workers. This is why the 4 GB tier, not the entry tier, is where most production Laravel apps end up.

Egress for asset-heavy apps. If you serve images, video, or large downloads directly from the server instead of a CDN or object storage, transfer allowance stops being a footnote. The three providers differ here more than anywhere else, and we'll put numbers on it below.

Snapshots deserve an honorable mention too. Taking a snapshot before a risky deploy or a major version upgrade is cheap insurance, but only if snapshot pricing doesn't punish you for using it. More on that in the hidden costs section.

Entry Tier: Who Wins Under $6 for Side Projects?

At the bottom of the price list, all three providers are within a dollar of each other, but the specs are not equal. At the time of writing, here's what your first $4 to $5 buys (Valebyte comparison, 2026):

ProviderPlanPrice/movCPURAMStorageTransferDigitalOceanBasic Droplet~$41512 MB10 GB SSD500 GBVultrCloud Compute$41512 MB10 GB NVMe~1 TBLinodeNanode 1 GB~$511 GB25 GB SSD1 TB

Read that RAM column twice. Linode charges roughly a dollar more and hands you double the memory and more than double the storage. For a Laravel app, 512 MB is genuinely tight: after the OS, Nginx, PHP-FPM, and a minimal MySQL instance, you're flirting with the OOM killer every time Composer runs. We've watched composer install fail on 512 MB boxes purely because MySQL and the install process couldn't coexist without swap.

Our honest guidance for this tier: it's for side projects, staging boxes, and demos, and Linode's Nanode is the best Laravel fit of the three because 1 GB of RAM is the practical floor for running the full stack on one machine. Vultr's $4 plan wins if you offload the database elsewhere, since NVMe makes it snappy for what it is. DigitalOcean's $4 Droplet is the weakest deal on paper but comes attached to the best documentation ecosystem, which matters more than specs when it's your first server.

Don't underestimate what these small boxes can do, though. We load tested this exact class of machine in how much traffic a $5 server can handle, and a tuned Laravel app with OPcache and proper caching served hundreds of requests per second before falling over. The entry tier isn't a toy. It's just not where you want your database living long-term.

The 4 GB / 2 vCPU Tier: Where Most Production Laravel Apps Live

Ask us where the median production Laravel app runs and the answer is boring: one server, 4 GB RAM, 2 vCPUs, everything on it. That's enough for MySQL with a 1 GB buffer pool, Valkey or Redis for cache and sessions, a dozen PHP-FPM workers, a queue worker or two, and the scheduler. At the time of writing, the class shakes out like this:

ProviderPlanPrice/movCPURAMStorageTransferDigitalOceanBasic Droplet (Regular)$2424 GB80 GB SSD4 TBDigitalOceanBasic Droplet (Premium NVMe)$2824 GB80 GB NVMe4 TBVultrCloud Compute (Regular)$2024 GB80 GB SSD3 TBVultrHigh Frequency$2424 GB128 GB NVMe3 TBLinodeLinode 4 GB (Shared)$2424 GB80 GB SSD4 TB

Three observations from running Laravel workloads on all five of those plans.

First, Vultr is the price aggressor. Twenty dollars for the regular plan undercuts everyone, and the High Frequency plan at $24 gives you 128 GB of NVMe, 60% more storage than the equivalent Droplet, at the same price. If raw specs per dollar decide your purchase, Vultr takes this tier, which matches its reputation for the most aggressive pricing in the segment (SSD Nodes comparison).

Second, DigitalOcean's Premium NVMe surcharge is worth paying for Laravel. The $4 difference between regular and Premium buys newer CPUs and NVMe storage, and in our experience that translates to visibly lower p95 response times under database load. If you're on DigitalOcean, don't provision the regular plan for production in 2026.

Third, Linode's 4 TB transfer at $24 quietly matters. It matches DigitalOcean and beats Vultr by a terabyte, and Linode has historically been generous when pooling transfer across servers on the same account. For an app serving user uploads or media without a CDN in front, that extra headroom is real money.

Performance-wise, independent trials at VPSBenchmarks show the three providers within a band of each other on web workloads, with rankings shifting between test runs and regions. Nobody wins this tier on performance alone. The differentiation is price (Vultr), transfer and support (Linode), and ecosystem (DigitalOcean).

DigitalOcean: The Ecosystem Default

DigitalOcean is where most Laravel developers start, and there's a defensible reason: no provider has invested more in documentation. The community tutorial library covers nearly every Nginx, MySQL, and PHP configuration question you'll ever have, and it's usually the first search result when something breaks at 2 a.m. Industry comparisons consistently rank DigitalOcean first on ecosystem, docs, and marketplace breadth among these three (SSD Nodes).

Beyond Droplets, the product surface is the widest here: managed MySQL and Postgres, Spaces object storage with a built-in CDN, load balancers, VPC networking, a container registry, and a marketplace of one-click images. For a Laravel team, that means your app server, your S3-compatible backup target, and your managed database can all live in one account with private networking between them.

The API is the best of the three in practice. It's consistent, well-documented, versioned, and wrapped by mature client libraries in every language that matters, including solid PHP SDKs. Terraform and Packer support is first-class. If you automate infrastructure, DigitalOcean is the least likely to surprise you.

Strengths: Best documentation and community content in the industry; broadest product ecosystem (managed databases, Spaces, load balancers, VPC); most polished API and tooling; Premium NVMe Droplets are genuinely fast for PHP workloads.

Best for: Teams and agencies that value predictability and ecosystem over squeezing the last dollar; developers who want managed MySQL and object storage from the same vendor; anyone who leans on community tutorials when debugging.

Considerations: Rarely the cheapest option at any tier; the regular (non-Premium) Droplets use older hardware you should avoid for production; 500 GB transfer on the entry Droplet is the stingiest of the three; support responsiveness on lower tiers is ticket-based and can be slow.

Vultr: The Price and Regions Aggressor

Vultr's pitch is simple: more locations and lower prices than anyone else in this weight class. At the time of writing it operates 30+ regions, the most of the three by a wide margin, with locations the others don't touch, including São Paulo, Johannesburg, Mumbai, Seoul, and multiple Australian cities (SSD Nodes). If your users are in a geography DigitalOcean and Linode treat as an afterthought, Vultr may be the only one of the three with a data center nearby.

The pricing aggression is real, not just marketing. The $4 entry plan with NVMe, the $20 regular 4 GB plan, and the High Frequency line all undercut or out-spec the equivalent products next door. Vultr also sells niche products the others don't at this price point: bare metal servers, GPU instances, and dedicated-CPU plans with fine-grained sizing.

Where does Laravel fit? The High Frequency plans are the sweet spot. Fast clocks help PHP-FPM directly, and the oversized NVMe allocation gives MySQL room to breathe. We've found Vultr instances perform very close to DigitalOcean Premium Droplets at a slightly lower price, with the caveat that performance consistency varies more by region than it does on the other two.

Strengths: Most aggressive pricing of the three at nearly every tier; most regions by far, with real APAC, South America, and Africa coverage; High Frequency NVMe plans are excellent for PHP and MySQL; broad product range including bare metal and GPU.

Best for: Cost-sensitive builders who compare spec sheets; apps whose users live outside the US/EU corridor; developers who offload the database and want the cheapest fast app server possible.

Considerations: Ecosystem and documentation depth trail DigitalOcean noticeably; performance consistency varies more between regions; snapshots and some features that were once free are now billed; support reputation is adequate rather than praised.

Linode (Akamai): The Steady Operator

Linode is the oldest of the three, and since the Akamai acquisition it's become the "boring in a good way" option. Comparisons consistently highlight two things: generous transfer allowances and a long-standing reputation for reachable, human support (SSD Nodes). Both matter more in month twelve of running an app than they do on day one.

The entry tier is where Linode's value is most obvious. The ~$5 Nanode's 1 GB of RAM makes it the best price-to-memory deal at the bottom of the market (Valebyte, VPSBenchmarks), and 1 GB is precisely the line where a full single-server Laravel stack becomes comfortable instead of precarious. For staging environments and client demo servers, we reach for Nanodes constantly.

The Akamai connection adds something the other two can't match: the backbone. Linode traffic rides Akamai's network, which shows up as consistently good routing and peering, particularly for globally distributed users hitting a single origin. Akamai has also been expanding Linode's region list into its edge footprint, closing what used to be Linode's biggest gap against Vultr.

Strengths: Best RAM per dollar at the entry tier; generous 4 TB transfer at the 4 GB tier with account-level pooling; support reputation is the best of the three; Akamai's network and backbone; predictable, stable pricing history.

Best for: Hobby projects and staging servers where 1 GB of RAM at $5 is the whole decision; transfer-heavy apps serving media from the origin; teams that want to talk to a human when something breaks.

Considerations: Managed database offering has had a bumpy history (paused, then relaunched under Akamai), so verify current availability in your region before depending on it; the product ecosystem is narrower than DigitalOcean's; the dashboard and marketplace feel a generation behind.

Where Do the Hidden Costs Hide?

Here's the 2026 nuance that changed how we advise people: the headline compute price stopped being the whole story. Egress overages, snapshot storage, backup surcharges, and managed add-ons now decide the real monthly bill more often than the base plan does (apicalculators, 2026). Two identical $24 servers can produce $24 and $47 invoices depending on how you use snapshots and where your traffic goes.

At the time of writing, the side costs stack up like this:

Cost itemDigitalOceanVultrLinodeEgress overage (per GB)$0.01$0.01$0.005Snapshots$0.06/GB/mo$0.05/GB/moNo standalone snapshots (use Images at ~$0.10/GB/mo)Automated backups+20% of plan (weekly), +30% (daily)+20% of planFlat fee per plan size (e.g., ~$5/mo on a 4 GB Linode)Included transfer (4 GB tier)4 TB3 TB4 TB (pooled)

A worked example makes it concrete. Take a $24 server, weekly provider backups, one 60 GB snapshot kept as a pre-upgrade restore point, and 1 TB of overage because your app serves user-uploaded video:

DigitalOcean: $24 + $4.80 (backups) + $3.60 (snapshot) + $10.00 (overage) = $42.40
Vultr:        $24 + $4.80 (backups) + $3.00 (snapshot) + $10.00 (overage) = $41.80
Linode:       $24 + $5.00 (backups) + $6.00 (image)    + $5.00  (overage) = $40.00

The gap between providers is small. The gap between the sticker price and the real bill is not: that's a 67% to 77% markup over the base plan in every case. Three practical mitigations, whichever provider you pick: put a CDN in front of anything asset-heavy so overage never triggers, delete snapshots after the upgrade they were insuring succeeds, and consider replacing the provider's percentage-based backup product with your own dump-and-ship pipeline to S3-compatible storage, which typically costs $1 to $2 per month for the same data.

One more subtle difference: Linode's per-GB egress overage is half the price of the other two. For origin-served media at scale, that halves your most unpredictable line item.

Managed Database or a Second VPS?

At some point every growing Laravel app faces the same fork: move MySQL to the provider's managed database product, or self-host it on a second VPS. The price gap is bigger than most people expect.

At the time of writing, DigitalOcean's managed MySQL starts around $15 per month for a 1 GB single-node cluster, with high-availability configurations (a primary plus standby) starting north of $50. Vultr and Linode's managed database offerings land in a similar band, with entry plans in the $15 to $35 range depending on engine and region, though Linode's product has been through a pause-and-relaunch cycle under Akamai and deserves a current-availability check before you commit.

Compare that to self-hosting: a dedicated $6 to $12 VPS running only MySQL, with the buffer pool tuned to the box, private networking to your app server, and nightly dumps shipped off-site. Roughly half the cost of the cheapest managed tier, and a quarter of the HA tier.

So what does the managed premium buy? Automated failover, point-in-time recovery, patching, and one less thing to page you. Those are real. But be honest about what the entry-level managed plans actually include: the $15 single-node plans have no standby, so you're paying the premium without getting the failover. In our experience, the managed option earns its cost at the HA tier and above, when downtime is measured in lost revenue. Below that, a second VPS with automated backups covers the same risk for less, and it's the pattern we see most $10-to-$50-per-month Laravel apps settle on. Teams doing cloud repatriation from AWS to a $10 VPS make exactly this trade deliberately, swapping RDS convenience for a bill that's an order of magnitude smaller.

The Laravel-specific footnote: whichever route you choose, keep the database in the same region and on the same private network as the app server. A 30ms round trip between app and database turns a 12-query page into a 360ms page before PHP does any work at all.

Regions and Latency: Who Covers Your Users?

Region choice is a Laravel performance decision disguised as a dropdown menu. TTFB for an uncached page is dominated by the round trip to your origin, so put the server near your users, not near you.

The coverage differences at the time of writing are stark. Vultr fields 30+ locations, the widest map of the three, with meaningful presence in South America (São Paulo), Africa (Johannesburg), India (Mumbai, Delhi region), Korea, Japan, and Australia (SSD Nodes). DigitalOcean runs a tighter list of around 15 regions: strong US and EU coverage, plus Singapore, Bangalore, Sydney, and Toronto, but nothing in South America or Africa. Linode's classic list (US, EU, Singapore, Tokyo, Mumbai, Sydney) has been expanding under Akamai into new metros riding the Akamai backbone, and routing quality on that backbone is a quiet advantage even where the region count is lower.

Practical translations:

US or EU audience: all three cover you well; pick on price and ecosystem, not geography.
APAC audience: Vultr's breadth wins (Seoul, Osaka, multiple Australian cities); Linode's Tokyo and Singapore locations are solid seconds with excellent peering.
South America or Africa: Vultr is the only one of the three with in-region compute; the others route you to US East or EU, adding 100 to 200ms per round trip.
Latency-sensitive split audiences: consider two small servers in two regions behind GeoDNS rather than one big server in the middle. Two Nanodes cost $10.

And if your audience is European and budget is the top priority, we'd be doing you a disservice not to mention that Hetzner undercuts all three on price-to-performance in the EU, often by 2x or more at the same price point. That's a separate post because it's a separate conversation, but it's the honest asterisk on this entire comparison for EU-first apps.

Does API Quality Actually Matter?

If you ever provision more than one server, yes. The API is the difference between infrastructure you can rebuild from a script and infrastructure that exists because someone clicked buttons eighteen months ago.

All three providers expose full REST APIs and official CLIs, and all three are fully supported by Terraform. Creating a server is a one-liner on each:

# DigitalOcean
doctl compute droplet create app-01 --size s-2vcpu-4gb \
  --image ubuntu-24-04-x64 --region fra1

# Vultr
vultr-cli instance create --plan vhf-2c-4gb \
  --os 2284 --region fra --label app-01

# Linode
linode-cli linodes create --type g6-standard-2 \
  --image linode/ubuntu24.04 --region eu-central --label app-01

The differences show up past the happy path. DigitalOcean's API is the most consistent and best documented, with predictable pagination, useful error messages, and mature SDKs; it's the one we'd hand to a junior engineer without a walkthrough. Linode's API v4 is clean and well-designed, arguably the nicest REST semantics of the three, with an excellent official CLI. Vultr's API covers everything but carries more legacy quirks: some operations behave asynchronously without clearly saying so, and you'll write more polling loops than you would against the other two.

For a solo developer this is a tiebreaker at most. For an agency provisioning a server per client, or a platform (like ours) that talks to all three APIs every day, it compounds: webhook reliability, rate limit sanity, and error clarity determine how much retry-and-reconcile code you end up maintaining. Ecosystem rankings that put DigitalOcean first on tooling reflect our experience exactly (SSD Nodes).

Running All Three on Deploynix

We'll declare our position: we don't think you should have to marry a provider. DigitalOcean, Vultr, and Linode are all first-class providers on Deploynix, alongside Hetzner, AWS, and custom servers, and the provisioning flow is identical on each. You connect an API token, pick a server type (app, web, database, cache, worker, Meilisearch, or load balancer), pick a plan and region, and get the same hardened stack with monitoring, free SSL, backups to S3-compatible storage, and zero-downtime deploys, regardless of whose logo is on the invoice.

That symmetry changes the economics of this whole comparison. When switching costs are near zero, you can pick per workload instead of per vendor: a Vultr High Frequency box for the app server because the price is right, a Linode for the staging environment because the Nanode is the best $5 in the business, and DigitalOcean managed MySQL because the ecosystem argument won for your database. One dashboard, one deploy pipeline, three providers. We wrote up how that works day-to-day in managing servers across six cloud providers from one dashboard.

It also makes migration boring, which is the highest compliment infrastructure can receive. Moving a Laravel app from DigitalOcean to Vultr (or the reverse) is: provision an equivalent server on the new provider, deploy the same app to it from the same Git repo, import the database, and cut DNS over once you've verified the new box. No re-learning a provisioning system, no rewritten deploy scripts, no config drift between the old and new servers, because both were built from the same recipe. Teams do this to chase a better price, escape a noisy region, or consolidate billing, and it's an afternoon, not a quarter.

The Verdict: Match the Provider to the Job

We promised real verdicts, so here they are, based on the numbers above and our own operational experience across all three.

Hobby project or side project: Linode. The ~$5 Nanode's 1 GB of RAM is the entire argument. It's the only entry-tier plan of the three that runs a full Laravel stack (Nginx, PHP-FPM, MySQL, Redis) without constant memory anxiety, and the price-to-memory math is the best at the bottom of the market (Valebyte). Vultr's $4 NVMe plan is the runner-up if your database lives elsewhere.

Small SaaS in production: Vultr High Frequency, with DigitalOcean Premium a close second. At the 4 GB / 2 vCPU tier where most Laravel apps live, Vultr's $24 High Frequency plan pairs fast clocks with 128 GB of NVMe and the lowest effective price. Choose DigitalOcean instead if you want managed MySQL, Spaces, and load balancers from the same account, and accept a few dollars of ecosystem tax. Watch the transfer line: if you serve heavy assets from the origin, Linode's pooled 4 TB and half-price overage quietly wins the real-bill comparison.

Agency running many client servers: DigitalOcean. When you're operating twenty servers for twelve clients, docs, API polish, and product breadth beat a $4-per-server saving. The best tutorial library in the industry reduces your support burden, and the cleanest API reduces your automation burden (SSD Nodes). Keep Vultr in your pocket for clients with users in regions DigitalOcean doesn't reach.

EU-first and budget-driven: none of the above. Hetzner beats all three on raw price-to-performance in Europe, and pretending otherwise would make the rest of this post less trustworthy. The full Hetzner breakdown has the numbers.

The pattern behind all four verdicts: compute prices converged, so pick on the second-order factors that fit your situation, and keep your setup portable enough that the decision stays reversible.

FAQ

Which provider is fastest for Laravel specifically?

There's no consistent winner. Independent tests at VPSBenchmarks show the three trading places by region and test run. What moves the needle for Laravel is plan generation, not vendor: pick NVMe-backed, current-CPU plans (Vultr High Frequency, DigitalOcean Premium, Linode's current shared tier) and you'll be within a few percent either way.

Is 1 GB of RAM enough to run Laravel in production?

For a low-traffic app, yes, if the whole stack is tuned for it: 3 to 4 PHP-FPM workers, a capped MySQL buffer pool, and OPcache enabled. It's the practical floor, which is why Linode's 1 GB entry plan beats the 512 MB plans from DigitalOcean and Vultr for single-server setups. For anything with real users or queue volume, budget for the 4 GB tier.

Should I use managed MySQL or run the database on my own VPS?

Self-host until downtime costs you real money. Entry managed plans (from roughly $15/month at the time of writing) are single-node, so you pay the premium without getting failover. A $6 to $12 dedicated database VPS with automated off-site backups covers the same risk for half the price. Move to managed once you need the HA tier with a standby node.

Can I mix providers, say the app on Vultr and staging on Linode?

Yes, and it's more practical than it sounds. Since Deploynix provisions DigitalOcean, Vultr, Linode, Hetzner, AWS, and custom servers through the identical flow, mixed setups behave like one environment: same deploy pipeline, same monitoring, same backup targets. The only real constraint is keeping the app and its database in the same region and network, whichever provider that is.

How painful is it to switch providers later?

If your server was built from a reproducible recipe, it's an afternoon: provision the new server, deploy from the same repo, import the database, verify, and cut DNS over with a low TTL. The pain people remember comes from hand-configured servers where nobody knows what's on them. Keep the setup scripted or platform-managed and provider choice stays a reversible decision.

Pick One and Ship

Here's our closing advice: the cost of deliberating over these three for another week is higher than the cost of picking the "wrong" one. The prices are within dollars of each other, the performance is within percent, and a well-scripted setup makes the choice reversible in an afternoon. Apply the verdicts above (Linode for the $5 experiment, Vultr or DigitalOcean for the production 4 GB box, DigitalOcean for the agency fleet), then spend your energy on the app instead of the vendor.

Where to go from here: pick the provider that matched your situation, grab an API token, and deploy your first Laravel app in under 10 minutes. You'll learn more from one deployed server than from ten more comparison posts, including this one.

Migrating From Laravel Vapor to Deploynix: Trading Serverless for Servers

Deploynix — Thu, 27 Aug 2026 19:39:33 +0000

There is a specific moment when serverless economics invert, and most teams can name the month it happened. Your Laravel app used to have spiky, unpredictable traffic, and Lambda's pay-per-millisecond model was a bargain. Then the product found its audience. Traffic became steady: a predictable daily curve, the same few thousand users, the same queue volume every hour. From that point on, you are paying a premium for elasticity you no longer use. The bill stops scaling to zero because your traffic never does.

We have talked to a lot of Laravel teams in exactly this position. They chose Vapor for good reasons, and Vapor delivered. But somewhere between product-market fit and the third month of a four-figure AWS invoice, someone opens Cost Explorer, squints at the NAT gateway line item, and asks the uncomfortable question: what would this cost on two ordinary servers?

Usually the answer is 60 to 80 percent less, with faster p50 latencies and a log file you can actually tail. This post is the honest version of that conversation. We will cover when Vapor is still the right call, how to audit your app before moving, a step-by-step migration runbook including a queue cutover that does not lose jobs, and a worked cost comparison at steady load. If you want the broader argument first, we made it in the serverless hype vs. reality for Laravel apps. This post assumes you have already decided to look seriously at moving.

When Vapor Is the Right Call

Let's be fair before we get to the migration, because Vapor is a genuinely well-built product and some teams should absolutely stay on it.

Strengths:

True burst handling. If your traffic goes from 50 requests per minute to 5,000 in thirty seconds, Lambda absorbs it without you touching anything. No autoscaling groups, no capacity planning, no 3 a.m. pages about load. This is the killer feature, and no fixed-size server setup matches it.
Zero server operations. No OS patching, no PHP upgrades on a box, no disk space alerts, no SSH. For a solo founder or a team with no infrastructure appetite, that has real value.
Per-millisecond billing on idle apps. A staging environment or an internal tool that gets ten requests a day costs almost nothing on Lambda. A VPS costs the same whether it serves one request or one million.
First-party Laravel integration. Vapor is built by the Laravel team. Queues, scheduled tasks, environment management, and deployments all work the way the framework documentation assumes.

Best for: Apps with genuinely spiky or unpredictable traffic (ticket sales, viral consumer products, campaign-driven marketing sites), teams with zero ops capacity, and low-traffic apps where the bill really does round to pocket change.

Considerations: Steady traffic means you pay the serverless premium continuously for elasticity you use twice a year. Cold starts of 500ms to 2 seconds hit your least-trafficked endpoints hardest, which are often admin panels and API routes your paying customers notice. Lambda's 15-minute execution ceiling is a hard wall for long imports, big report generation, and video processing. NAT gateway hours and data processing charges appear as surprise line items the moment your functions talk to the internet from inside a VPC. And debugging means CloudWatch Logs Insights queries instead of tail -f storage/logs/laravel.log, which sounds minor until you are doing it during an incident.

The pattern is not unique to Vapor users. A Barclays CIO survey found that 83% of enterprises plan to repatriate at least some workloads from public cloud (via Northflank), and teams that repatriate strategically report infrastructure savings of 30 to 60 percent (MassiveGRID). Worth stressing, though: only around 5% plan a full exit from the cloud (Advanced Hosting). Repatriation is a workload-by-workload decision, not an ideology. Your steady-traffic Laravel monolith is exactly the kind of workload where it pays off. Your S3 buckets and maybe your RDS instance can stay right where they are.

How Do You Know You've Hit the Crossover Point?

The crossover is rarely one dramatic invoice. It creeps. Here are the signals we see most often in teams that eventually migrate, roughly in the order they appear.

Your warming bill exists at all. Vapor's warm setting keeps Lambda containers alive so users do not eat cold starts. Read that again: you are paying for idle compute to simulate a server. Once warming instances run around the clock, you have reinvented a fixed server with worse economics. The moment warm: 10 feels necessary in production, the elasticity argument has already lost.

Cold starts hit the endpoints you can least afford. High-traffic routes stay warm naturally. It is the low-traffic ones that go cold: the admin panel your biggest customer's ops team uses, the API endpoint a partner polls hourly, the password reset flow. A 1.5-second stall on a checkout-adjacent route is a support ticket; on a sales demo, it is worse.

The queue backlog keeps hitting the 15-minute wall. If your team has ever chunked a job, not because chunking was good design but because Lambda would kill it at minute fifteen, count how many of those workarounds exist. Each one is architecture bent around a billing model.

The invoice needs a translator. When "why did the NAT gateway cost $60 this month?" is a real question in your Slack, and answering it takes an hour in Cost Explorer, add that engineering time to the bill. Same for incidents: if reconstructing one request means stitching together three CloudWatch log groups, your mean-time-to-understanding is paying the serverless tax too.

Traffic graphs look like sine waves, not earthquakes. Pull 90 days of request metrics. If peak hour is within 3 to 5x of the quiet hour, every week, you have a capacity-plannable app. Provision a server for peak with headroom and pocket the difference.

Two or three of these and you are past the crossover. All five, and this migration is overdue.

What Does the Vapor-to-Server Concept Mapping Look Like?

The good news: nothing about Vapor changes your application code in ways that block a move. Laravel was built for servers first. Vapor adapted it to Lambda; you are adapting it back. Every Vapor concept has a direct server-side equivalent.

Vapor / AWS concept

Server equivalent

Notes

Lambda HTTP function

Nginx + PHP-FPM worker pool (or Octane)

Always warm. No cold starts, no per-invocation billing.

SQS queues

Database or Valkey/Redis queue + Supervisor-managed workers

QUEUE_CONNECTION=database or redis. Workers restart automatically.

vapor.yml build/deploy steps

Deploynix deploy config + deploy hooks

Same idea: composer install, npm build, migrate, cache.

RDS database

Stays on RDS initially, or moves to a database server later

Connecting to RDS from a VPS is fine. Decouple this decision from the migration.

CloudFront

Cloudflare (or any CDN) in front of your server

Free tier covers most Laravel apps.

Vapor environment variables and secrets

.env per environment, managed in the dashboard

Same values, different transport.

Scheduled tasks (scheduler: true)

Cron entry running php artisan schedule:run

One line, managed via UI.

ElastiCache / Vapor cache

Valkey on the same box or a dedicated cache server

Sub-millisecond, no network hop for single-server setups.

CloudWatch Logs

storage/logs/laravel.log + log shipping if you want it

You can tail it again.

Two things on this table deserve emphasis. First, RDS can stay. A common migration mistake is trying to move compute and data on the same day. Don't. Deploynix provisions servers on AWS as well as DigitalOcean, Vultr, Linode, and Hetzner, so you can put your app server in the same AWS region as your RDS instance, keep single-digit-millisecond database latency, and defer the database decision entirely. Second, S3 stays S3. Your FILESYSTEM_DISK=s3 config does not care whether the code calling it runs on Lambda or a VPS. Do not migrate object storage as part of this project.

The Pre-Migration Audit

An afternoon of auditing saves a weekend of firefighting. Before provisioning anything, work through your vapor.yml and your codebase.

Inventory your vapor.yml

Your vapor.yml is the map of everything the migration has to replace. A typical mid-size app looks something like this:

id: 12345
name: acme-app
environments:
  production:
    memory: 1024
    cli-memory: 512
    runtime: php-8.3
    queues:
      - default
      - notifications
    queue-memory: 1024
    queue-timeout: 300
    warm: 10
    scheduler: true
    database: acme-production
    cache: acme-cache
    build:
      - 'composer install --no-dev'
      - 'php artisan event:cache'
      - 'npm ci && npm run build && rm -rf node_modules'
    deploy:
      - 'php artisan migrate --force'
  staging:
    memory: 512
    queues:
      - default
    scheduler: true

For each environment, write down: the queue names and their timeouts, whether the scheduler is on, the attached database and cache, every build and deploy step, and the warming configuration (that warm: 10 line is ten Lambda containers being pinged around the clock; it becomes irrelevant on a server, and it was costing you money). Then pull the environment variables and secrets for each environment:

vapor env:pull production
# secrets are listed in the Vapor dashboard; export them alongside the env file

Store the result somewhere safe. This file becomes your server .env almost verbatim.

Find Lambda-shaped code assumptions

Vapor forced some patterns onto your codebase. Most of them are harmless on a server, and a few actually become opportunities:

Ephemeral /tmp workarounds. Code that streams uploads straight to S3 because local disk did not persist keeps working unchanged. But jobs that awkwardly chunked work through S3 to dodge the missing filesystem can be simplified: you have a persistent local disk again.
The 15-minute ceiling. Search for jobs that were split into chains purely to fit under Lambda's timeout. On a server, a queue worker can run a four-hour job if you let it. You do not have to refactor these on day one, but flag them.
Package and image size limits. Vapor's Docker runtime caps images at 10GB and the standard runtime is far tighter, so you may have excluded binaries like wkhtmltopdf, FFmpeg, or heavy PHP extensions. On a server you just install them.
Runtime assumptions. Check for hardcoded references to Vapor helpers or the VAPOR_* environment variables, and confirm TRUSTED_PROXIES handling once you are behind Cloudflare instead of CloudFront.

Decide where the database lives (for now)

The right answer during migration is: exactly where it is today. Add your VPS's IP to the RDS security group, point DB_HOST at the RDS endpoint, and move on. Once the migration has been stable for a month, you can evaluate moving to a Deploynix-provisioned database server with automated backups shipped to S3-compatible storage. That is a separate project with its own dump-and-restore cutover, and we cover the economics of it in the real cost of running a Laravel SaaS.

The Migration Runbook

Here is the sequence we recommend, in order, with the queue cutover treated as the delicate part it is.

Step 1: Provision the app and worker servers

Connect a cloud provider to Deploynix (DigitalOcean, Vultr, Linode, Hetzner, AWS, or a custom server) and provision two servers: an app server (Nginx, PHP-FPM, your PHP version) and a worker server for queues and scheduled tasks. Small teams can run everything on one box; separating web and worker traffic means a runaway job cannot starve your HTTP requests. If you are staying near RDS, provision on AWS in the same region.

Connect your GitHub, GitLab, or Bitbucket repository, and translate your vapor.yml build and deploy steps into the deploy configuration and deploy hooks. The mapping is almost one-to-one:

# Deploy script (runs on each release)
composer install --no-dev --optimize-autoloader
npm ci && npm run build
php artisan migrate --force
php artisan config:cache
php artisan event:cache
php artisan queue:restart

Deploys are zero-downtime by default: each push builds a new release directory, and a symlink swap makes it live, with one-click rollback to the previous release. This replaces Vapor's deploy pipeline, including the rollback story.

Step 2: Move environment variables

Take the file from vapor env:pull and load it into your server's environment through the dashboard. The changes are small and predictable:

APP_ENV=production
APP_URL=https://app.example.com

DB_CONNECTION=mysql
DB_HOST=acme-production.xxxx.eu-west-1.rds.amazonaws.com  # RDS stays, for now

QUEUE_CONNECTION=database   # was sqs
CACHE_STORE=redis           # Valkey on the worker/cache server, was ElastiCache
SESSION_DRIVER=database     # survives the cutover across both platforms

FILESYSTEM_DISK=s3          # unchanged, S3 stays S3

Delete the SQS_* and VAPOR_* variables only after the cutover is complete. During the parallel window, both platforms run with their own queue connection, which is exactly what makes the next step safe.

Step 3: Cut over the queues without losing a job

This is the step people worry about, and the strategy is simple: new jobs go to the new queue, old jobs drain from the old one, and for a while both sets of workers run.

On the new servers, configure queue workers through the Deploynix UI: connection, queue names (default, notifications, matching your vapor.yml), process count, timeout, and retry settings. Deploynix writes the Supervisor configuration for you, so workers restart on failure and on deploy.
Deploy the app to the new servers with QUEUE_CONNECTION=database (or redis). At this point the new stack is dispatching to and consuming from its own queues.
Leave Vapor's queue workers running. They keep consuming whatever is still in SQS, including delayed and released jobs.
Watch the SQS console until ApproximateNumberOfMessages and the not-visible count both sit at zero, and stay there. Remember delayed jobs: if you dispatch jobs with long delays, the drain window must be at least as long as your longest delay.
Only then disable Vapor's queue processing.

Mind your failed_jobs table during the window: jobs can fail on either platform, and you want queue:retry run from the side that owns the job. If you have not already built retry and timeout discipline into your jobs, do it before the migration, not after; our queues deep dive on connections, workers, and retry strategies covers the settings that matter, and debugging Laravel queue failures without losing messages is the companion piece for when something does go sideways mid-cutover.

Step 4: Move the scheduler

On Vapor, scheduler: true ran your schedule through a CLI Lambda. On the worker server, it is one cron entry, configured through the UI:

* * * * * php /home/deploynix/app/current/artisan schedule:run >> /dev/null 2>&1

One caution for the parallel window: if the scheduler runs on both platforms simultaneously, tasks fire twice. Use ->onOneServer() with a shared cache store, or simpler, disable Vapor's scheduler at the moment you enable cron. For most apps a sixty-second gap in scheduling is harmless; double execution often is not.

Step 5: DNS cutover and the parallel window

Drop your DNS TTL to 60 seconds a day before the cutover. Issue the SSL certificate for your domain on the new server (Deploynix handles Let's Encrypt issuance and renewal for free), and verify the new stack end to end using a hosts-file override or a temporary subdomain: login, checkout, webhooks, file uploads, a full queue round-trip.

Then switch DNS from Vapor's CloudFront distribution to the new server (or to Cloudflare proxying the new server, which replaces CloudFront's CDN role). Because sessions are in the database and both stacks talk to the same RDS instance, users whose DNS resolves to either side during propagation get a consistent experience.

Keep Vapor fully deployed and warm for at least a week. That is your rollback: if anything is wrong, point DNS back and you are on the old stack within minutes. Rollback for bad deploys on the new stack is separate and faster: one click back to the previous release. Only delete the Vapor environments when the new stack has survived a full weekly cycle, including your heaviest scheduled jobs.

If parts of this runbook feel familiar, it is because the shape is the same for any platform exit; we walked through the PaaS variant in migrating Laravel from Railway, Render, or Fly.io to a VPS.

What Do You Actually Get Back?

The cost savings get the headlines, but talk to teams six months after this migration and they lead with the capabilities.

A persistent local disk. Temporary files, on-disk caches, generated exports that live for an hour before download: all trivially possible again. You stop paying S3 round-trip latency for scratch work.

Long-running jobs. The 15-minute ceiling is gone. A nightly report that takes 40 minutes is just a queue job with $timeout = 3600 and a worker that is allowed to take its time.

Real-time WebSockets on the same box. This one is binary: Vapor cannot host persistent socket connections, so Reverb is off the table there and you are pushed to Pusher or Ably as a paid external dependency. On a Deploynix server, Reverb runs as a daemon under Supervisor next to your app, and broadcasting works the way the Laravel docs describe, with no per-message pricing.

First-class queue tooling. SQS through Vapor works, but you give up Laravel Horizon, which requires Redis. On a server with Valkey as your queue connection, Horizon runs as a daemon and gives you per-queue throughput, wait times, and failed-job retries in a dashboard your whole team can read. For queue-heavy apps, this alone changes how quickly you diagnose problems.

Boring, predictable bills. Two fixed-price servers cost the same in your busiest month and your quietest one. Finance can forecast it. Nobody audits Cost Explorer looking for the line item that doubled.

Direct debuggability. SSH in, tail -f the log, run php artisan tinker against production with appropriate care, watch htop during an incident. CloudWatch is powerful, but during an outage, immediacy beats query languages.

What You Take On, and How It's Mitigated

Honesty cuts both ways: leaving Vapor means someone is responsible for servers again. The real question is how much of that responsibility gets automated.

Security and patching. A public server needs a firewall, SSH hardening, fail2ban, and regular updates. Deploynix provisions servers hardened by default (key-only SSH, UFW configured, automatic security updates) so the baseline does not depend on you remembering it.

Backups. On Vapor, RDS snapshots were your safety net; if your database eventually moves off RDS, backups become your problem. Automated database backups to S3-compatible storage, on a schedule, with retention, are built in. Test a restore once a quarter regardless of platform.

Monitoring and capacity. Lambda scaled silently; a server has finite CPU, RAM, and disk. Built-in monitoring with alerts covers the basics (load, memory, disk, service health), so you hear about a filling disk days before it becomes an incident. And when you genuinely outgrow one app server, you add a second behind a Deploynix-provisioned load balancer. That is a scaling step, not an emergency.

The elasticity trade. This is the one real loss. If your traffic can spike 50x in a minute, fixed servers need headroom or a CDN absorbing the burst, and neither is as effortless as Lambda. Be honest about whether that describes your traffic. For most steady-state SaaS apps, it does not, and provisioning 3x headroom still costs a fraction of the serverless equivalent.

Worked Example: What Does Steady Load Cost on Each?

Numbers make this concrete. Take a representative mid-size Laravel SaaS at steady load: about 5 million HTTP requests a month averaging 250ms at 1GB memory, 2 million queue jobs a month averaging 2 seconds, an RDS MySQL instance, a small Redis cache, CDN in front, and functions inside a VPC (which means a NAT gateway). Approximate monthly costs at current us-east/eu-west pricing:

Line item

Vapor stack

Two-server Deploynix stack

HTTP compute

Lambda: ~$21 + API Gateway: ~$5

App server (4 vCPU / 8GB, DigitalOcean): $24

Queue compute

Lambda workers: ~$66 + SQS: ~$1

Worker server (2 vCPU / 4GB): $18

Warming (10 instances)

~$8

n/a (always warm)

NAT gateway

~$42 (hours + data processing)

n/a

Database

RDS db.t4g.medium + storage: ~$58

Same RDS instance: ~$58 (unchanged)

Cache

ElastiCache t4g.micro: ~$12

Valkey on worker server: $0

CDN

CloudFront: ~$10

Cloudflare free tier: $0

Logging

CloudWatch: ~$15

Local logs: $0

Platform fee

Vapor: $39/project

Deploynix plan

Total

~$277 + traffic growth

~$100 + flat

Two observations. First, the compute you actually think about (Lambda HTTP) is not the expensive part; the queue workers, NAT gateway, warming, and observability plumbing around it are. Second, the server column barely moves as traffic grows: the same $24 app server that handles 5 million requests a month handles 15 million, while every Lambda line item scales linearly. At steady load, that roughly $175 monthly gap is the serverless premium, and it widens every month your traffic grows. Squeeze further by moving the database off RDS later, or by provisioning on Hetzner, and the gap gets embarrassing; the fuller teardown lives in cloud repatriation for Laravel: from AWS to a $10 VPS.

Your numbers will differ. Run yours before deciding; the audit in this post gives you every input you need.

FAQ

Can I keep RDS and still migrate off Vapor?

Yes, and we recommend it. Provision your app server on AWS in the same region as your RDS instance, allow its IP in the RDS security group, and point DB_HOST at the endpoint. Latency stays in single-digit milliseconds, and you have decoupled the risky database move from the compute migration entirely.

How long does the migration take?

For a typical app: an afternoon for the audit, a day to provision and configure the new stack, and a one-to-two week parallel window before you decommission Vapor. The active cutover itself (queue switch plus DNS) is an evening. The parallel window is not wasted time; it is your rollback insurance.

Will I lose queued jobs during the cutover?

Not if you drain rather than switch. New servers dispatch to the new queue connection while Vapor's workers keep consuming SQS until it is empty, including delayed jobs. Both worker fleets run simultaneously during the window. The only way to lose jobs is to turn off SQS consumption before the backlog and delay horizon are clear, so don't.

What about Octane? We used it on Vapor for performance.

Octane runs at least as well on a server, arguably better, because workers persist indefinitely instead of living inside Lambda's lifecycle. Deploynix supports Octane with FrankenPHP, Swoole, or RoadRunner running as a daemon under Supervisor. Plenty of teams migrate to plain PHP-FPM first and adopt Octane later once they have baseline numbers to compare.

Is this a full "leave AWS" move?

No, and framing it that way leads to bad decisions. Only about 5% of organizations plan full repatriation (Advanced Hosting); the sensible pattern is workload by workload. In this migration, S3 stays, RDS can stay, and only the compute layer (the part with the worst steady-load economics) moves to servers.

Where to Go From Here

Vapor earned its place in the Laravel ecosystem, and if your traffic is genuinely spiky or your ops appetite is genuinely zero, staying is defensible. But if your dashboard shows the same steady curve every week, you are renting elasticity you do not use, and the exit is more mechanical than it looks: map the concepts, audit the vapor.yml, drain the queues, flip DNS, keep the old stack warm for a week.

The single next step: run the audit. Pull your vapor.yml and your last three months of AWS invoices, fill in the cost table above with your own numbers, and see where you land. If the gap looks like ours, provision a test server on Deploynix, deploy a staging copy of your app, and put real traffic through it before you commit to anything. The numbers will tell you whether this migration is worth your weekend. In our experience, for steady-traffic Laravel apps, they almost always do.