DEV Community: Deploynix

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.

ARM vs. x86 Servers for Laravel: Should You Switch in 2026?

Deploynix — Sun, 23 Aug 2026 11:18:03 +0000

Here is a number that should get your attention: at Hetzner, a 4 vCPU / 8 GB ARM server (the CAX31, running Ampere Altra cores) launched at €11.99 per month, while the equivalent x86 CPX31 (4 vCPU AMD EPYC, 8 GB) sat at €16.49 (Better Stack). Same vCPU count, same RAM, roughly 27% cheaper. Hetzner announced price rises effective April 2026 that moved those figures to €15.99 and €21.49 respectively, and the gap barely budged. At the time of writing, choosing ARM still saves you about €5.50 per month per server, or around 26%.

That discount is not a promotion or a loss leader. It reflects a real difference in how much these chips cost to buy and power. And it raises an obvious question for anyone running Laravel in production: is there a catch, or are we all overpaying for x86 out of habit?

The honest answer is that it depends on the shape of your traffic, and most articles on this topic skip that part. ARM cores are typically 15 to 20% slower per single thread, which matters for PHP because each request runs on exactly one thread. But your server does not handle one request. It handles dozens of concurrent requests across a fleet of PHP-FPM workers, and that is a parallel workload where ARM's core count economics shine.

We've provisioned both architectures for Laravel apps enough times to have opinions grounded in production behavior rather than synthetic benchmarks alone. This post walks through the price math, the performance trade-off that actually matters for PHP, the state of arm64 compatibility in 2026, and a migration path that will not take your app down.

Why Did ARM Servers Suddenly Get Cheap?

ARM chips have dominated phones for two decades because they deliver more compute per watt. Servers were a different story for years: the software ecosystem assumed x86, and nobody wanted to be the first to port everything. Two things broke that logjam.

First, AWS built Graviton. Amazon started shipping its own ARM server chips in 2018 and priced Graviton instances aggressively below their x86 equivalents. That forced the entire ecosystem, from Linux distributions to Docker to database vendors, to treat arm64 as a first-class target. When the largest cloud provider on earth bets on an architecture, package maintainers follow.

Second, Ampere started selling ARM server chips to everyone else. The Ampere Altra, the chip inside Hetzner's CAX line, packs up to 80 cores on a single socket with predictable per-core performance and dramatically lower power draw than comparable x86 parts. For a hosting company, electricity and cooling are among the biggest line items in the datacenter budget. A chip that does comparable work on fewer watts translates directly into lower prices for you.

There's a third, quieter factor: your laptop probably already runs ARM. Every Apple Silicon MacBook since 2020 is an arm64 machine. Millions of developers have spent five years unknowingly stress-testing the arm64 ecosystem in local development, filing issues against every Docker image and PECL extension that did not build. The ecosystem hardened because of it. We'll come back to why that helps you in the compatibility section.

What Does the Price Gap Actually Look Like?

Let's put the Hetzner numbers side by side, since Hetzner is where the ARM value proposition is most visible in Europe. Both servers below offer 4 vCPUs and 8 GB of RAM. The only meaningful spec difference is the silicon.

CAX31 (ARM)

CPX31 (x86)

ARM Savings

CPU

4 vCPU Ampere Altra

4 vCPU AMD EPYC

RAM

8 GB

Price before April 2026

€11.99/mo

€16.49/mo

€4.50/mo (~27%)

Price from April 2026

€15.99/mo

€21.49/mo

€5.50/mo (~26%)

Prices are at the time of writing and sourced from Better Stack's Hetzner Cloud review, which also covers the April 2026 adjustment. Even after the increase, the relative discount held steady at roughly a quarter off.

One server saving €5.50 a month is coffee money. But cost optimization compounds. If you run a web tier of three servers plus two queue workers, that is €27.50 a month, or €330 a year, for hardware that (as we'll see) may actually process more total requests for your workload. Scale that to an agency managing twenty client servers and the architecture choice starts paying a salary's worth of hosting bills over a few years.

The catch, and there is one, is that a cheaper server is only cheaper if it does the same job. Better Stack's analysis puts ARM instances at roughly 20 to 40% better price-performance for compatible parallel workloads, but around 15 to 20% lower single-thread scores (Better Stack). Both halves of that sentence matter for Laravel, so let's unpack them.

We've written before about why Hetzner in general is our value pick for European Laravel hosting in our Hetzner deep dive. The ARM line extends that logic one step further.

What Actually Matters for Laravel Performance?

Here is the mental model that cuts through the benchmark noise: a PHP request is single-threaded, but a PHP server is parallel.

When a request hits your Laravel app, nginx hands it to one PHP-FPM worker process. That worker executes your entire request on a single core: routing, middleware, Eloquent queries, view rendering, JSON serialization. PHP does not spread one request across multiple cores. So the latency of any individual request is bounded by single-thread performance, which is exactly where x86 keeps its edge.

But your server is not running one worker. A well-tuned 8 GB server typically runs 20 to 40 PHP-FPM workers side by side, each handling its own request on whatever core is free. Throughput, meaning how many requests per second the whole box can sustain, is a parallel problem. That is the game ARM was built to win. If you haven't tuned your worker pool, our guide to PHP-FPM worker and memory tuning is the place to start, because an untuned pool will mask any hardware difference entirely.

Where x86 Wins: Latency per Request

Strengths: Higher single-thread performance, typically 15 to 20% by synthetic measures and 20 to 30% in real PHP workloads (bitdoze benchmark). Every individual request completes faster, all else equal. Decades of compiler and library optimization targeting the architecture. Zero compatibility questions, ever.

Best for: Apps where the user experience hinges on a handful of heavy synchronous endpoints. Think report generation in the request cycle, complex Eloquent aggregations on the dashboard, or an API where a partner's SLA measures p95 latency in milliseconds. Also spiky, low-concurrency traffic: if you rarely have more than a few requests in flight, you cannot exploit parallelism, so per-core speed is all that counts.

Considerations: You pay roughly 26% more at Hetzner for the privilege, at the time of writing. If your slow endpoints are slow because of database queries or missing cache, and in our experience they usually are, a faster CPU buys you very little. Profile before you pay for silicon.

Where ARM Wins: Throughput per Euro

Strengths: Better Stack pegs ARM at 20 to 40% better price-performance for parallel workloads (Better Stack). Steady concurrent traffic across many FPM workers is the textbook parallel workload. Lower power draw means providers can keep prices low sustainably rather than as a teaser. Queue workers, schedulers, and Horizon fleets are throughput machines with no human waiting on any single job, which makes them close to a perfect fit.

Best for: Steady multi-user traffic where dozens of requests overlap. Queue-heavy applications processing thousands of jobs per hour. Worker fleets, cron-heavy apps, webhook receivers, and background processing tiers where total jobs per hour matters and per-job latency does not. Budget-sensitive projects where 26% off the hosting bill funds something else.

Considerations: Each individual request runs somewhat slower. On a typical Laravel page that spends most of its wall time waiting on MySQL and Valkey rather than burning CPU, the difference is often single-digit milliseconds and invisible. On a genuinely CPU-bound endpoint, it is measurable. You also take on a small compatibility checklist, covered below.

The genuinely balanced take: neither architecture "wins Laravel." ARM wins Laravel throughput per euro; x86 wins Laravel latency per request. Which one you should optimize for is a question about your users, not your stack.

Is ARM Compatibility Still a Problem in 2026?

For the standard Laravel stack, no. This was a real concern in 2021. It is mostly a solved problem now.

Everything a typical production Laravel server runs has mature arm64 builds: nginx, PHP (every supported version), MySQL, MariaDB, PostgreSQL, Valkey, Redis, Supervisor, certbot, Node.js for asset builds, and Composer, which is architecture-agnostic PHP anyway. Ubuntu publishes arm64 images with identical package coverage for everything above. The popular ondrej PPA, the de facto standard source for PHP on Ubuntu, ships arm64 packages, so PHP installation is literally the same commands:

sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt install -y php8.4-fpm php8.4-cli php8.4-mysql \
  php8.4-redis php8.4-mbstring php8.4-xml php8.4-curl \
  php8.4-zip php8.4-intl php8.4-gd php8.4-bcmath

Not one flag changes between architectures. Your composer install, your .env, your nginx vhost, and your Supervisor configs are all byte-identical. If you can tell which architecture you are on from inside a Laravel codebase, something unusual is going on.

When you do want to check, two commands answer the question:

uname -m                    # aarch64 on ARM, x86_64 on Intel/AMD
dpkg --print-architecture   # arm64 or amd64 (Debian/Ubuntu)

What to Actually Check Before Switching

The remaining rough edges in 2026 cluster in three places, and you can audit all of them in an afternoon.

Closed-source binaries. Anything you download as a precompiled blob rather than install from a package manager deserves a look. Monitoring agents from smaller vendors, license-key-protected PHP tools, proprietary CLI utilities. Most major vendors ship arm64 builds now, but "most" is not "all." Check what you have:

file /usr/local/bin/your-vendor-tool
# ELF 64-bit LSB executable, x86-64 ...  -> won't run on ARM
# ELF 64-bit LSB executable, ARM aarch64 -> you're fine

PECL extensions that compile from source. Common extensions like redis, imagick, xdebug, and swoole build cleanly on arm64. Obscure or unmaintained PECL packages occasionally have hand-written x86 assembly or outdated build scripts. If your php -m output contains anything exotic, test-compile it on a throwaway ARM instance before committing.

Docker images without arm64 manifests. If part of your stack runs in containers, verify each image publishes an arm64 variant:

docker manifest inspect ghcr.io/vendor/some-image:latest \
  | grep -B1 -A1 '"architecture"'

Official images for PHP, nginx, MySQL, PostgreSQL, and Valkey are all multi-arch. The gaps show up in small vendor images and internal tooling built by a CI runner that only knows amd64.

Here's the twist we hinted at earlier: if your team develops on Apple Silicon Macs, you have been running your stack on ARM for years already. Every M-series MacBook running your app in Docker or Herd is an arm64 environment. The classic "works on my machine" architecture mismatch has quietly inverted. Deploying to an ARM server means production finally matches the laptops, and any arm64-incompatible dependency would have bitten your developers long before it bit production. The short version: M-series adoption did more for arm64 server viability than any vendor announcement.

How Honest Are the Benchmarks?

Benchmark methodology is where ARM-versus-x86 articles quietly mislead people, so let's be explicit about what different tests actually measure.

Synthetic benchmarks like Geekbench multi-core flatter ARM. They saturate every core with math-heavy work, which is the exact scenario Ampere designed for. Real PHP applications spend most of their time in memory access, I/O waits, and branchy interpreted code, not vectorized math loops.

Real-application benchmarks tell a more modest story. The bitdoze ARM vs x86 VPS benchmark, which tested WordPress-style PHP workloads on comparable instances, found x86 ahead by roughly 7 to 10% in raw throughput and 20 to 30% in single-thread performance. WordPress is a reasonable stand-in for PHP frameworks generally: interpreted PHP, MySQL queries, template rendering. Note what happened there: x86 won raw throughput too, just narrowly.

So why do we still say ARM wins throughput? Because the benchmark compares performance at equal specs, not at equal cost. If x86 delivers 7 to 10% more requests per second but costs 26% more, ARM delivers meaningfully more requests per euro. That is the number your hosting bill cares about. Better Stack's 20 to 40% price-performance advantage figure (Better Stack) is exactly this arithmetic applied across their test suite.

The other honesty check: benchmark your app, not someone else's. A Livewire dashboard, a JSON API, and a queue fleet have wildly different CPU profiles. Our methodology from load testing Laravel on a $5 server applies unchanged here: same codebase, same seed data, wrk or k6 against realistic endpoints, and watch p95 rather than averages. Run it against one ARM and one x86 instance for an hour each. The two servers together cost less than a pizza, and you will have real numbers instead of ours or anyone else's.

Which Workloads Fit ARM, and Which Don't?

Here is the decision table we walk through when someone asks us whether to provision CAX or CPX. It compresses everything above into workload shapes.

Workload

Better Fit

Why

Steady web traffic, many concurrent users

ARM

Parallel across FPM workers; per-request latency delta is invisible behind I/O waits

Queue workers / Horizon fleets

ARM

Pure throughput, nobody waits on an individual job; best price per job processed

Scheduled jobs, webhook receivers, cron-heavy apps

ARM

Background throughput, latency irrelevant

Staging, preview, and QA environments

ARM

Cost matters, performance barely does; also validates arm64 before production

Dedicated database server

Either

Databases are memory- and disk-bound first; buy RAM and fast storage, not architecture

Latency-critical API with strict p95 SLA

x86

Single-thread speed directly shortens every request

Spiky, low-concurrency traffic

x86

Few overlapping requests means no parallelism to exploit; per-core speed is everything

Heavy synchronous CPU work (PDF generation, image processing in-request)

x86

CPU-bound single requests feel the 20-30% single-thread gap directly

Anything depending on x86-only closed-source binaries

x86

Compatibility is binary; no discount fixes a tool that won't run

Two patterns fall out of that table. First, the further a workload sits from a waiting human, the better ARM fits. Second, mixed fleets are legitimate: plenty of teams run ARM queue and web tiers behind an x86 box that handles the one CPU-heavy synchronous service. Nothing forces a single architecture across your infrastructure, and if you're still choosing where that infrastructure lives, our cloud provider guide for Laravel developers maps which providers offer ARM at all.

Running ARM Servers on Deploynix

Since we get asked: yes, Deploynix provisions Hetzner's ARM CAX instances the same way it provisions any other server. You pick a CAX plan during server creation instead of a CX or CPX plan, and that is the entire difference in the workflow.

Under the hood, the provisioning stack detects the architecture and installs the identical stack from arm64 package sources: nginx, PHP-FPM (any supported version, or several side by side), MySQL, MariaDB or PostgreSQL, Valkey, and Supervisor. Firewall rules, deploy keys, SSL, zero-downtime deployment structure, all identical. Your deploy script does not know or care that it is running on Ampere cores. The same applies across providers: Hetzner, DigitalOcean, Vultr, Linode, AWS, and custom servers all land on the same stack layout, so an ARM box slots into an existing fleet without special handling.

The genuinely useful part for this article's question is monitoring. Deploynix tracks CPU, memory, and load metrics per server, which means you can run the before-and-after comparison with real data: note your x86 server's CPU utilization and load average under normal traffic, stand up the ARM twin, shift traffic, and compare the same charts a week later. In our experience that graph settles the ARM debate faster than any benchmark blog post, ours included.

How Do You Migrate a Laravel App from x86 to ARM?

You don't. You migrate to a new server that happens to be ARM. This distinction matters: there is no in-place architecture switch. Every binary on the machine is compiled for one instruction set, so the move is a reprovision, and that is actually good news, because reprovisioning is a well-understood, low-risk operation with a built-in rollback.

The shape is classic blue/green at the server level:

1. Provision the ARM server alongside the old one. New CAX instance, same region, same stack configuration. Your existing x86 server keeps serving traffic untouched.

2. Deploy the same release. Same repository, same branch, same .env values pointed at the same database (or a replica if you are moving the database too). Run composer install and your asset build on the new box; both are architecture-transparent.

3. Test against the server's IP directly. Hit the ARM server with your smoke tests and a short load test before any real user does. Edit your local /etc/hosts to point your domain at the new IP for full end-to-end checks. This is where any exotic PECL extension or x86-only binary would surface, safely, with zero user impact.

4. Cut over gradually or atomically. The simple path is a DNS cutover: drop your TTL to 60 seconds a day in advance, then repoint the A record. The cautious path is a load balancer in front of both servers, shifting traffic in stages: 10%, then 50%, then 100%, while you watch error rates and p95 latency. Deploynix's load balancer server type exists for exactly this kind of gradual shift, and it turns an architecture migration into a routing decision you can reverse in seconds.

5. Keep the x86 server warm for a week. It costs a few euros and it is the cheapest insurance you will ever buy. If anything subtle appears, cut DNS back. After a clean week, destroy it and pocket the ongoing savings.

Queue workers are even easier because they need no cutover at all. Point ARM workers at the same Redis or database queue, let both architectures consume jobs side by side, then retire the x86 workers. The queue does not care what processed the job. If you run Horizon, drain the old supervisor gracefully with horizon:terminate and let the ARM fleet absorb the backlog.

Total effort for a typical single-app setup: an afternoon of work spread across a week of caution. Compare that with the effort you'd spend shaving 26% off your hosting bill any other way.

When Should You Not Bother?

Cost optimization has a floor, and honesty demands we mark it.

Skip the switch if your total hosting spend is one small server. Saving €5.50 a month, at the time of writing, does not justify even an afternoon of migration work unless you are doing it for the learning. At that scale your bigger cost question is whether a VPS is right at all, which we tackled in the real cost math of Laravel Cloud's $5 plan vs a $5 VPS.

Skip it if you depend on an x86-only binary you cannot replace. A monitoring agent, a licensed PDF engine, a vendor CLI. One hard incompatibility outweighs any discount, and emulation layers like qemu on a production server are a support ticket generator, not a solution.

Skip it if your p95 latency is already tight against an SLA and your endpoints are CPU-bound. A 20 to 30% single-thread deficit (bitdoze) lands directly on exactly those requests. Buy the faster core; it is the correct tool.

And skip it, for now, if your provider's ARM availability is thin in your region. Hetzner's CAX line is not available in every location, and a cheaper server in the wrong region can cost you more in latency than it saves in euros. Check availability before you plan anything.

Everyone else, which in our experience is the majority of Laravel apps (steady traffic, I/O-bound endpoints, queue-heavy backends), is leaving 26% on the table out of inertia.

FAQ

Does Laravel officially support ARM servers?

Laravel doesn't target an architecture at all; it targets PHP. PHP has shipped first-class arm64 builds for years, and every part of the standard stack (nginx, MySQL/PostgreSQL, Valkey, Supervisor) has mature arm64 packages. If PHP runs, Laravel runs. There is no ARM-specific configuration anywhere in a Laravel codebase.

Will my Composer dependencies work on ARM?

Almost certainly. Composer packages are PHP source code, which is architecture-independent. The only risk lives in compiled PHP extensions (PECL) and any vendored native binaries. Check php -m for exotic extensions and file any bundled binaries. Mainstream extensions like redis, imagick, gd, and intl all build cleanly on arm64 in 2026.

Is ARM actually faster than x86 for Laravel?

Per request, no: x86 completes a single request roughly 20 to 30% faster in real PHP benchmarks (bitdoze). Per euro, yes: at Hetzner's roughly 26% lower ARM pricing at the time of writing, ARM delivers more total throughput for the same spend on concurrent traffic and queue work (Better Stack). Pick the metric that matches your bottleneck.

Can I mix ARM and x86 servers in one setup?

Yes, and it is often the best answer. Architectures share nothing at the HTTP or queue layer, so an ARM queue fleet can consume the same Redis queue as an x86 web tier, and a load balancer can split traffic across both. Many teams run ARM for throughput tiers and keep one x86 box for a CPU-bound service.

How risky is the migration?

Low, if you treat it as a blue/green server swap rather than an upgrade. You provision the ARM server alongside the old one, deploy the same release, test against the IP, shift traffic gradually, and keep the old server for a week as rollback. At no point is your app running on only an untested box.

The Verdict

ARM in 2026 is not a gamble; it is a pricing decision with a known trade-off. You accept 15 to 30% slower single-thread execution in exchange for roughly 26% lower cost at the time of writing, and because PHP-FPM's concurrency model spreads real traffic across many parallel workers, most Laravel workloads convert that trade into more throughput per euro, not less. The exceptions are real (latency-critical endpoints, CPU-bound synchronous work, x86-only binaries) but they are exceptions, and they are identifiable in an afternoon of auditing.

Your next step is cheap and concrete: provision one ARM instance, deploy your actual application to it, and load test it against your current server for a week. A CAX31 costs €15.99 a month at the time of writing, so the experiment costs a few euros and answers the question with your data instead of ours. Once it is up, wire it into your stack the standard way with our production-ready Laravel stack guide and let the monitoring graphs make the call.

Migrating From Heroku to Deploynix: A Cost and Control Upgrade for Laravel

Deploynix — Fri, 21 Aug 2026 11:13:03 +0000

There's a specific moment when a Heroku invoice stops making sense. For most teams it isn't the first month, or even the first year. It's the month you scale a dyno to handle real traffic, add a worker for your queue, bump Postgres off the hobby tier, and realize you're paying north of $100 every month for compute that a single mid-range VPS would handle without breaking a sweat. You stare at the line items, do the mental math, and the number just doesn't add up anymore.

We've heard this story from Laravel developers repeatedly over the past two years, and the data backs it up. In a Barclays CIO survey, 83% of enterprises said they plan to repatriate at least some workloads from public cloud back to infrastructure they control (Northflank, 2024). Organizations that make the move strategically report infrastructure savings of 30-60% (MassiveGRID, 2026). The pendulum that swung hard toward "never touch a server" is swinging back toward "own your stack, but automate the painful parts."

To be clear: Heroku earned its reputation. git push heroku main was a genuine revolution in 2010, and the developer experience is still excellent in 2026. The problem was never the product. The problem is the price you pay for that experience once your app is no longer a side project, and the ceiling you hit when you need control Heroku doesn't offer.

This guide is the complete migration path for a production Laravel application: why teams leave, how every Heroku concept maps to a VPS, a pre-migration audit checklist, a step-by-step runbook with real commands, a worked cost comparison, and an honest accounting of what you take on when you leave a fully managed platform.

Key Takeaways- A typical production Heroku stack (web dyno, worker dyno, Postgres, Redis) runs about $115/month; a comparable VPS costs $12-24/month. - 83% of enterprises plan to repatriate cloud workloads (Northflank, 2024). - Heroku uses PostgreSQL, and Deploynix supports PostgreSQL natively, so no database engine switch is required. - A parallel-running window plus a low-TTL DNS cutover makes the migration effectively zero-downtime.

Why Are Teams Leaving Heroku in 2026?

Cost at scale is the headline reason, and it's substantial. Strategic cloud repatriation delivers 30-60% infrastructure savings on average (MassiveGRID, 2026), and Heroku migrations often land at the top of that range because dyno pricing carries the platform's largest margins. But cost is only the most visible of four recurring complaints.

The Cost Curve Bends the Wrong Way

Heroku's pricing is friendly at the bottom and punishing at the top. At the time of writing, a Basic dyno runs about $7/month, a Standard-1X about $25/month, and Performance dynos start at $250/month and climb from there. Managed Postgres and the Key-Value Store (Redis-compatible) are priced separately, each with their own tier ladder.

The trouble is that these tiers don't scale with hardware prices. VPS compute has gotten dramatically cheaper per gigabyte of RAM over the past decade. Heroku's dyno pricing hasn't followed. A Standard-1X dyno gives you 512MB of RAM for $25/month. A $9/month VPS from Hetzner gives you 4GB. That's roughly a 20x difference in price per gigabyte, and it compounds across every dyno and addon you run.

Dyno Constraints

Dynos restart daily, whether you want them to or not. The ephemeral filesystem means anything written to disk vanishes on restart, which forces you onto S3 for every uploaded file even when local storage would be fine. Memory limits are hard walls: exceed 512MB on a Standard-1X and you get R14 errors and degraded performance until you pay for the next tier. None of these constraints exist on a server you control.

Addon Sprawl

Every capability is a separate line item. Postgres is an addon. Redis is an addon. Log retention beyond 1,500 lines is an addon. Scheduled jobs, monitoring, error tracking: addons. Each one is individually reasonable and collectively expensive. Teams routinely discover their addon spend exceeds their dyno spend, and that a lot of it duplicates things Laravel and a VPS give you for free.

EU Data Residency

Heroku's Common Runtime offers US and EU regions, but fine-grained control over where your data physically lives requires Private Spaces, which start at enterprise-level pricing. For teams with GDPR obligations or customers who ask pointed questions about data location, "our database is on a Hetzner server in Falkenstein, Germany" is a much easier answer than a diagram of Heroku's addon infrastructure. This is a pattern we cover across the whole PaaS category in why Laravel developers are leaving generic PaaS platforms, and it applies to Heroku more than most.

How Do Heroku Concepts Map to a VPS?

Every Heroku primitive has a direct equivalent on a Deploynix-managed server, which is what makes this migration mechanical rather than architectural. Nothing in your Laravel codebase needs to change. The table below is the mental model for the entire migration; the rest of this guide is just executing it row by row.

Heroku concept

Deploynix / VPS equivalent

Dyno

Server + site (Nginx + PHP-FPM)

Procfile entries (web:, worker:)

Supervisor-managed daemons and queue workers, configured in the UI

Config vars

.env file, edited through the dashboard

Release phase (release: php artisan migrate)

Deploy hooks that run during each deployment

Heroku Postgres addon

Self-hosted PostgreSQL on your server

Heroku Key-Value Store (Redis)

Valkey (Redis-compatible), installed by default

Heroku Scheduler addon

Laravel scheduler via cron (schedule:run every minute)

heroku ps / dyno metrics

Server monitoring with CPU, RAM, and disk alerts

heroku releases:rollback

One-click instant rollback to a previous release

Automatic SSL

Free Let's Encrypt SSL, auto-renewed

Two rows deserve emphasis. First, the database: Heroku standardized on PostgreSQL, and Deploynix provisions PostgreSQL alongside MySQL and MariaDB, so there's no forced engine migration. Your pg_dump restores directly. Second, the release phase: Heroku's release: command maps one-to-one onto deploy hooks, so your migration-on-deploy workflow survives intact.

Heroku vs. Deploynix: An Honest Comparison

Before the runbook, a fair assessment of both platforms. We build Deploynix, so discount our bias accordingly, but we've tried to be straight about where Heroku genuinely wins.

Heroku

Strengths: The best-polished PaaS developer experience in the industry, fifteen years of refinement, and truly zero server operations. You never think about the OS, patching, or capacity in units smaller than a dyno. The addon marketplace makes bolting on a service a one-line command. The buildpack system means deployment "just works" for almost any stack with no configuration at all.

Best for: Prototypes, internal tools, and early-stage products where engineering time is worth far more than infrastructure spend. Teams with zero appetite for operations, even automated operations. Apps whose traffic genuinely justifies elastic dyno scaling on unpredictable schedules.

Considerations: The cost curve steepens sharply with scale, and you pay the managed-platform premium on every component: compute, database, cache, logging, scheduling. The 512MB memory ceiling on Standard-1X dynos is tight for a modern Laravel app with Octane or heavy queue jobs. The ephemeral filesystem forces architectural decisions on you. Fine-grained data residency requires Private Spaces pricing.

Deploynix

Strengths: You run on servers you own, at VPS prices, with the operational work automated. Provisioning on DigitalOcean, Vultr, Linode, Hetzner, AWS, or any custom VPS takes minutes. Zero-downtime deploys, instant rollback, deploy hooks, queue workers and daemons via Supervisor, the Laravel scheduler, free SSL, monitoring with alerts, and automated database backups to S3-compatible storage are all built in. Security hardening is applied by default at provision time.

Best for: Production Laravel applications with steady traffic, teams that want a 60-90% infrastructure cost reduction without giving up push-to-deploy workflows, and anyone who needs to choose exactly where their data lives.

Considerations: A VPS is your responsibility in ways a dyno is not. Deploynix automates OS hardening, unattended security upgrades, backups, and monitoring, but you are still the one choosing when to scale the server, and vertical scaling means a resize rather than a slider. If your traffic is genuinely spiky by 10x on unpredictable schedules, elastic dyno scaling still has a real argument. We compare that trade-off across providers in our guide on migrating Laravel from Railway, Render, or Fly.io to a VPS.

The Pre-Migration Audit: What to Inventory Before You Move

A clean migration starts with a complete inventory, and in our experience the audit takes under an hour for a typical app. Teams that skip it are the ones that discover a forgotten Heroku Scheduler job or an addon-injected config var two days after cutover. Work through these four checks before you provision anything.

1. Buildpacks and Procfile

List what Heroku is actually running for you:

heroku buildpacks -a your-app
cat Procfile

A typical Laravel app shows the PHP buildpack (often with Node.js for asset builds) and a Procfile like this:

web: heroku-php-nginx -C nginx.conf public/
worker: php artisan queue:work redis --tries=3 --timeout=90
release: php artisan migrate --force

Each line becomes a row in your migration plan: web: becomes the Nginx site Deploynix configures automatically, worker: becomes a queue worker defined in the UI, and release: becomes a deploy hook. If you have custom buildpacks (wkhtmltopdf, ImageMagick, custom PHP extensions), note them; on a VPS these are one-time apt installs rather than buildpack gymnastics.

2. Addon Inventory

heroku addons -a your-app

For each addon, decide: self-host it, replace it, or keep it as an external SaaS. Postgres and the Key-Value Store move onto your server. Logging addons are replaced by real log files on disk plus Laravel's own channels. Scheduler is replaced by cron. Error trackers like Sentry or Bugsnag are ordinary SaaS products that work identically from a VPS; keep them and just carry the DSN over.

3. Export Your Config Vars

heroku config -a your-app --shell > heroku-config.env

This produces KEY=value lines ready to merge into your new .env. Watch for two gotchas. First, addon-injected vars like DATABASE_URL and REDIS_URL will change; don't copy them blindly. Second, Heroku's PHP buildpack reads DATABASE_URL as a single URL, while a conventional Laravel .env splits it into DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, and DB_PASSWORD. Translate accordingly, or keep using DATABASE_URL since Laravel supports it natively.

4. The Database Decision (Spoiler: There Isn't One)

Heroku means PostgreSQL. Some VPS panels are MySQL-only, which turns a hosting migration into a database engine migration, an order of magnitude more risk. Deploynix provisions PostgreSQL as a first-class option alongside MySQL and MariaDB, so you keep your engine, your extensions, and your query behavior. The only decision left is which Postgres major version to install; match your Heroku version, which you can check with heroku pg:info -a your-app.

The Migration Runbook, Step by Step

The full migration takes an afternoon of focused work plus a parallel-running window, and no step involves downtime until the final DNS cutover. We'll assume a standard Laravel app with Postgres, Redis-backed queues, and scheduled jobs. Here's the sequence we run ourselves.

Step 1: Provision the Server

In Deploynix, connect your cloud provider (DigitalOcean, Vultr, Linode, Hetzner, AWS) or add a custom VPS by IP, then provision. For the worked example later in this post, a 2 vCPU / 4GB server is comfortable. Choose PostgreSQL as the database engine during provisioning; Valkey is installed for cache and queues. Provisioning applies security hardening automatically: firewall rules, SSH lockdown, fail2ban, and unattended security upgrades.

Step 2: Move the Database

Capture a fresh backup on Heroku, download it, and restore it to the new server:

heroku pg:backups:capture -a your-app
heroku pg:backups:download -a your-app

This gives you latest.dump in Postgres custom format. Restore it:

pg_restore --verbose --clean --no-acl --no-owner \
  -h your-server-ip -U deploy -d your_app_db latest.dump

The --no-acl --no-owner flags matter: Heroku's dump references Heroku-internal roles that don't exist on your server, and these flags strip them. For a database of a few gigabytes this completes in minutes. This first restore is a rehearsal; you'll do it once more, fresh, right before cutover.

Step 3: Create the Site and Connect GitHub

Add a site on the server, point it at your GitHub repository (GitLab and Bitbucket work the same way), and enable auto-deploy on push to your production branch. Set your environment variables from the audited heroku-config.env, with the database and Redis vars updated:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=your_app_db
DB_USERNAME=deploy
DB_PASSWORD=generated-at-provision

REDIS_CLIENT=phpredis
REDIS_HOST=127.0.0.1

QUEUE_CONNECTION=redis
CACHE_STORE=redis
SESSION_DRIVER=redis

Then recreate your release phase as deploy hooks, which run on every deployment:

php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache

Deploys are zero-downtime: each push builds a new release directory and switches a symlink only when everything succeeds, so a failed build never takes the site down. Trigger a first deploy and confirm the app boots against the restored database.

Step 4: Queue Workers and the Scheduler

Recreate each worker: Procfile line as a queue worker in the Deploynix UI, which writes and manages the Supervisor configuration for you:

Command: queue:work
Connection: redis
Tries: 3
Timeout: 90
Processes: 2

Supervisor restarts workers if they crash and Deploynix restarts them gracefully on each deploy, replacing the dyno restart behavior you relied on. For Heroku Scheduler jobs, the fix is nicer than what you had: Heroku Scheduler's 10-minute minimum granularity goes away. Enable the Laravel scheduler and every schedule() definition in your app runs on its native cadence via a single cron entry:

* * * * * php /home/deploy/your-app/current/artisan schedule:run >> /dev/null 2>&1

If any Scheduler jobs lived only in the Heroku dashboard rather than in code, move them into routes/console.php now. Your scheduling belongs in version control anyway.

Step 5: The Parallel-Running Window

Don't cut over the day you finish setup. Run both environments in parallel for three to seven days. Point a test subdomain at the new server, enable the free SSL certificate, and exercise the app: logins, uploads, queue jobs, scheduled tasks, webhooks. Watch the built-in monitoring for memory and CPU headroom. Keep deploying to both targets during this window so the codebases never diverge.

One rule during parallel running: the Heroku database remains the source of truth. The new server's database is a stale copy used for verification only. Any writes made during testing on the new stack are throwaway.

Step 6: DNS Cutover With a Low TTL

At least 24 hours before cutover, drop your DNS TTL to 300 seconds so the switch propagates in minutes rather than hours. At cutover time:

heroku maintenance:on -a your-app

heroku pg:backups:capture -a your-app
heroku pg:backups:download -a your-app
pg_restore --verbose --clean --no-acl --no-owner \
  -h your-server-ip -U deploy -d your_app_db latest.dump

Then flip your DNS A record to the new server, confirm SSL issues for the apex domain, and verify propagation:

dig +short yourapp.com

Total write-downtime is the maintenance window: the duration of one final dump and restore, typically 5-15 minutes for a moderately sized database. Read-only traffic could even be served throughout if you skip maintenance mode and accept a small window of writes to reconcile.

The Rollback Plan

Keep the Heroku app scaled up but idle for two weeks. If anything goes seriously wrong, rollback is the cutover in reverse: dump the new database, restore to Heroku, turn maintenance off, flip DNS back. Because your TTL is still 300 seconds, the world follows within minutes. Only after two quiet weeks do you run the satisfying final commands:

heroku ps:scale web=0 worker=0 -a your-app
heroku addons:destroy heroku-postgresql -a your-app --confirm your-app

What Does the Move Actually Save? A Worked Example

For a typical production Laravel app, the same workload that costs about $115/month on Heroku runs on a $12-24/month VPS, a saving of 79-90% on infrastructure. That's consistent with the 30-60% average that repatriating organizations report (MassiveGRID, 2026); Heroku migrations land above the average because every component carries the managed premium. Here are the numbers, using Heroku's pricing at the time of writing:

Component

Heroku

VPS (Deploynix-managed)

Web serving

Standard-1X dyno, 512MB RAM: $25/mo

Included on server

Queue worker

Standard-1X worker dyno: $25/mo

Supervisor worker, included

PostgreSQL

Standard-0 addon: ~$50/mo

Self-hosted, included

Redis / cache

Key-Value Store Premium-0: ~$15/mo

Valkey, included

Scheduled jobs

Scheduler addon: free, 10-min granularity

Cron, per-minute, included

SSL

Included

Included (Let's Encrypt)

Total compute

~$115/mo

$12-24/mo (e.g. Hetzner 4GB ~$12, DigitalOcean 4GB ~$24)

And the hardware comparison is lopsided in the VPS's favor. That $115 Heroku stack gives your app two 512MB containers and a shared database plan. The $12 Hetzner server gives you 4GB of RAM and 2 dedicated-share vCPUs for the app, database, and cache combined, with room to spare. Most apps migrate onto a smaller server than they expect.

Two honest caveats. Add your Deploynix subscription to the right-hand column; even so, the total stays a fraction of the Heroku bill, and the platform fee is flat rather than scaling per-dyno. And if your app needs Performance dynos ($250+ each at the time of writing), your savings are far larger than this example, which is exactly the dynamic we walk through in cloud repatriation for Laravel: from AWS to a $10 VPS. For the small end of the spectrum, the real cost math on a $5 VPS breaks down the same comparison at hobby scale.

What Do You Take On When You Leave Heroku?

Leaving a fully managed platform means accepting responsibility for three things Heroku handled invisibly, and the honest answer is that automation covers most, not all, of them. Here's the real operational delta, item by item, and how much of it is mitigated.

OS Updates and Security

On Heroku, the stack image is patched for you. On a VPS, the OS is yours. Deploynix narrows this gap substantially: provisioning applies hardening by default (firewall, SSH configuration, fail2ban) and enables unattended security upgrades, so CVE patches land without your involvement. What remains yours is the occasional major distribution upgrade every couple of years. That's a real task, but it's a scheduled afternoon, not a lurking daily burden.

Backups

Heroku Postgres continuous protection was genuinely good, and this is the responsibility to take most seriously. The mitigation: automated database backups to any S3-compatible storage (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces) on a schedule you define, with retention policies. Configure this on day one, before cutover, and restore-test it once. We wrote a full setup guide in automated database backups: set it, forget it, sleep well. Off-server backups cost a dollar or two per month; skipping them is the one genuinely reckless way to run this stack.

Monitoring

heroku ps and the metrics dashboard are replaced by built-in server monitoring: CPU, memory, and disk tracking with configurable alerts, plus visibility into your Supervisor-managed workers. You'll actually gain observability here, because you can see the whole machine rather than a per-dyno abstraction, and read full logs on disk instead of Heroku's 1,500-line router buffer. Pair it with the external error tracker you already carried over, and your coverage exceeds what you had.

Frequently Asked Questions

Do I have to switch from PostgreSQL to MySQL?

No. This is the question we hear most from Heroku teams, and the answer is a flat no. Deploynix provisions PostgreSQL as a first-class engine alongside MySQL and MariaDB. Your pg_dump restores directly with pg_restore, your migrations are untouched, and any Postgres-specific features you use (JSONB queries, full-text search) keep working.

How much downtime should I expect?

The write-downtime equals your final dump-and-restore window, typically 5-15 minutes for databases up to a few gigabytes, and the rest of the migration happens while Heroku serves production normally. With a 300-second DNS TTL set in advance, traffic follows the cutover within minutes. Larger databases can shrink the window further with logical replication, but most apps don't need it.

What happens to my Heroku Scheduler jobs?

They move to the Laravel scheduler, and they get better. Heroku Scheduler's minimum granularity is 10 minutes and its jobs live outside version control. On your server, a single cron entry runs schedule:run every minute, so every frequency Laravel supports works natively and your schedule definitions live in routes/console.php where they belong.

Can I still roll back a bad deploy like `heroku releases:rollback`?

Yes, and it's faster. Every zero-downtime deploy keeps previous releases on disk, and rollback is a one-click symlink switch back to the prior release, taking effect in seconds. Failed builds never go live in the first place, because the symlink only moves after a successful build.

Is this migration harder than moving from Forge?

Slightly, because you're changing hosting models rather than just panels, but the Laravel-side work is nearly identical. If you've read our Forge migration guide, the site, worker, and scheduler steps will look familiar; the Heroku-specific additions are the Procfile translation and the Postgres dump-and-restore, both covered above.

The Next Step

Heroku was the right choice when your priority was shipping fast with zero operations, and there's no shame in having paid the premium while it bought you focus. But when the invoice crosses the line from convenience fee to burden, the math is hard to argue with: the same Laravel workload, on hardware four times larger, for 79-90% less, with PostgreSQL intact and your deploy workflow preserved.

The whole migration is an afternoon of setup plus a week of parallel running, and nothing is irreversible until you scale the dynos to zero. The single next step: provision a server with Deploynix on the provider of your choice, restore last night's pg_dump to it, and point a test subdomain at the result. Once you've watched your app run for a week on a $12 server, the invoice decision makes itself.

Passkey Authentication in Laravel 13: Setup, HTTPS Requirements, and a Sane Rollout Plan

Deploynix — Wed, 19 Aug 2026 11:13:05 +0000

Right now, somewhere, a botnet is replaying leaked email and password pairs against a Laravel login form. Not because anyone targeted that app specifically, but because credential stuffing is cheap, automated, and it works. Verizon's Data Breach Investigations Report has said the same thing for years: stolen credentials remain one of the most common ways attackers get in, showing up in roughly a third of breaches (Verizon DBIR). Your users reuse passwords. Some of those passwords are already in a dump somewhere. That's the baseline reality every login form inherits.

Rate limiting helps. TOTP helps more. But both are mitigations layered on top of the same structural flaw: a shared secret that your server stores, your user remembers, and any phishing page can ask for. Passkeys remove the shared secret entirely, which is why they're the first authentication upgrade in a long time that changes the math instead of just raising the cost.

Laravel 13, released March 17, 2026, ships first-party passkey authentication support, so the integration excuse is gone (Laravel News, PHP Everyday). What's left is the operational half: relying party ID decisions you can't undo, the HTTPS requirement that follows you into staging, testing without a fingerprint reader on your CI runner, and an account recovery story that's honestly harder than the code. We run Laravel infrastructure for a living, so this post covers both halves. The code first, then the parts that actually determine whether your rollout goes well.

Why Are Passkeys Worth Adopting Now?

Passkeys are phishing-resistant, immune to credential stuffing, and now supported natively in Laravel 13. The FIDO Alliance reported that over 15 billion online accounts could use passkeys by 2025 (FIDO Alliance), and every major platform ships an authenticator. The ecosystem argument that justified waiting no longer holds.

The security properties come from the architecture, not from policy. A passkey is a public-private key pair. Your server stores only the public key. The private key never leaves the user's authenticator, whether that's Face ID on an iPhone, Windows Hello on a laptop, or a hardware key like a YubiKey. When your database gets dumped, the attacker gets a pile of public keys that are useless for logging in anywhere, including your own app.

Phishing resistance is the part that surprises people. A passkey is cryptographically bound to the domain it was registered on. If a user lands on deplyonix-login.example instead of your real domain, their browser simply won't offer the passkey. There's no "user was tired and typed their password into the wrong site" failure mode, because there's nothing to type. This isn't vendor marketing; it's how the W3C WebAuthn specification defines credential scoping (W3C WebAuthn Level 2).

And credential stuffing? There's nothing to stuff. No secret exists in more than one place, so a breach at some unrelated site can't be replayed against yours. For anyone who has watched fail2ban logs scroll past at 3 a.m., that alone justifies the project.

The remaining question was always developer effort. Before Laravel 13, you were wiring up a third-party WebAuthn package, hand-rolling the ceremony endpoints, and hoping you got attestation validation right. Now the framework handles the ceremonies, and if you're planning the framework upgrade anyway, our guide to upgrading to Laravel 13 in production with zero downtime covers that path. In our experience the upgrade and the passkey rollout are best treated as two separate deploys, for reasons we'll get to in the rollout section.

How Does WebAuthn Actually Work?

Strip away the acronyms and WebAuthn is a challenge-response protocol built on public-key cryptography, standardized by the W3C (W3C WebAuthn Level 2). The server issues a random challenge. The authenticator signs it with a private key it never reveals. The server verifies the signature with the public key it stored at registration. That's the whole trick. Everything else is packaging.

Two ceremonies matter: registration (creating a credential) and authentication (using it).

The Registration Ceremony

When a user adds a passkey, your server generates a challenge plus some metadata: your app's name, the relying party ID (more on that shortly), and the user's identifier. The browser hands this to the platform authenticator, which asks the user to confirm with a biometric or PIN. The authenticator then mints a brand-new key pair scoped to your domain, signs the challenge, and returns the public key and a credential ID. Your server verifies the response and stores both.

One detail worth internalizing: a new key pair is created per site, per user. There's no master key that opens everything. The passkey for your app is mathematically unrelated to the passkey for the user's bank.

The Authentication Ceremony

Login runs the same dance in reverse. The server sends a fresh challenge. The browser finds credentials matching your relying party ID, the user confirms with Face ID, Windows Hello, or a hardware key tap, and the authenticator signs the challenge with the stored private key. Your server looks up the public key by credential ID, verifies the signature, checks the challenge matches the one it issued, and logs the user in.

Because the challenge is random and single-use, replay attacks fail. Because the signature is bound to the origin, phishing pages fail. Because verification uses only a public key, database leaks fail. It's a short list of failure modes, and that's the point.

Where Do Synced Passkeys Fit In?

Platform passkeys sync through the vendor's credential manager: iCloud Keychain on Apple devices, Google Password Manager on Android and Chrome. That's how a passkey created on a phone works on the same user's laptop. Syncing is what made passkeys consumer-viable, and it's also the piece that makes some security teams pause, because the platform account becomes part of your trust chain. We'll come back to that trade-off honestly in the considerations section.

Passwords vs TOTP vs Passkeys: How Do They Compare?

No comparison table settles an architecture decision by itself, but this one clarifies what each factor actually defends against.

Property

Passwords

TOTP (authenticator apps)

Passkeys

Secret stored on server

Yes (hashed)

Yes (shared seed)

No (public key only)

Phishing resistant

No (codes can be relayed in real time)

Yes (bound to domain)

Credential stuffing resistant

Partially (second factor required)

Yes (nothing to stuff)

Works offline on user side

Yes

Medium (typing, resets)

High (open app, copy code)

Low (one biometric prompt)

Recovery difficulty

Low (email reset)

Medium (backup codes)

High (needs deliberate design)

Server-side breach impact

High if hashes crack

High (seeds are symmetric)

Minimal

Passwords

Strengths: Universal. Every user, browser, device, and support workflow understands them. Recovery via email reset is a solved problem, and no platform dependency exists.

Best for: The fallback layer during a passkey transition, and users on locked-down or shared devices where authenticators aren't available.

Considerations: Reuse and phishing are unfixable at the protocol level. Everything you bolt on (complexity rules, breach-list checks, rate limiting) is compensation for the core design.

TOTP

Strengths: Big security lift over passwords alone, well understood, works without connectivity, cheap to implement.

Best for: A second factor where passkeys aren't viable yet, and compliance regimes that explicitly name OTP.

Considerations: The seed is a shared secret sitting in your database, and modern phishing kits proxy TOTP codes in real time. Adversary-in-the-middle toolkits treat TOTP as a speed bump, not a wall.

Passkeys

Strengths: Phishing-resistant by construction, immune to stuffing and database-dump replay, and genuinely faster to use than a password plus a code.

Best for: Primary authentication for consumer and SaaS apps on a stable production domain, and any team tired of password-reset support tickets.

Considerations: Recovery must be designed, not assumed. The relying party ID welds credentials to your domain. Enterprise users on managed devices may not be able to enroll at all.

How Do You Set Up Passkeys in Laravel 13?

The walkthrough below assumes Laravel 13 on PHP 8.5, which is the stack Deploynix provisions by default on Ubuntu 24.04. The first-party support gives you the ceremony plumbing; you own the routes, the UI, and the policy decisions.

Configuration

The relying party settings live in config. Set them deliberately, because the id value is the one you can't casually change later:

// config/passkeys.php

return [
    'relying_party' => [
        // Must be your production registrable domain, or a suffix of it.
        'id' => env('PASSKEYS_RP_ID', parse_url(config('app.url'), PHP_URL_HOST)),
        'name' => config('app.name'),
    ],

    // How long the browser waits for the user to complete the ceremony.
    'timeout' => 60_000,

    // Require user verification (biometric or PIN), not just presence.
    'user_verification' => 'required',
];

Keep PASSKEYS_RP_ID in your environment configuration per environment, so staging registers credentials against the staging domain and production against the real one. Never read env() outside config files; use config('passkeys.relying_party.id') everywhere else.

Storing Credentials

A user has many passkeys, and you want them to. One per device family is the healthy pattern:

// database/migrations/2026_08_02_000000_create_passkeys_table.php

public function up(): void
{
    Schema::create('passkeys', function (Blueprint $table) {
        $table->id();
        $table->foreignId('user_id')->constrained()->cascadeOnDelete();
        $table->string('name'); // "MacBook Touch ID", "YubiKey 5C"
        $table->string('credential_id')->unique();
        $table->text('public_key');
        $table->unsignedBigInteger('sign_count')->default(0);
        $table->json('transports')->nullable();
        $table->timestamp('last_used_at')->nullable();
        $table->timestamps();
    });
}

The model is deliberately boring:

// app/Models/Passkey.php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Passkey extends Model
{
    use HasFactory;

    protected $fillable = [
        'name', 'credential_id', 'public_key', 'sign_count', 'transports',
    ];

    protected function casts(): array
    {
        return [
            'transports' => 'array',
            'last_used_at' => 'datetime',
        ];
    }

    public function user(): BelongsTo
    {
        return $this->belongsTo(User::class);
    }
}

The Registration Endpoints

Registration is a two-step round trip: fetch options, then verify the browser's response.

// app/Http/Controllers/PasskeyController.php

namespace App\Http\Controllers;

use App\Http\Requests\StorePasskeyRequest;
use App\Models\Passkey;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Passkeys;

class PasskeyController extends Controller
{
    public function registrationOptions(Request $request): JsonResponse
    {
        $options = Passkeys::registrationOptions($request->user());

        $request->session()->put('passkey_registration_challenge', $options->challenge());

        return response()->json($options);
    }

    public function store(StorePasskeyRequest $request): JsonResponse
    {
        $verified = Passkeys::verifyRegistration(
            user: $request->user(),
            credential: $request->validated('credential'),
            challenge: $request->session()->pull('passkey_registration_challenge'),
        );

        $request->user()->passkeys()->create([
            'name' => $request->validated('name'),
            'credential_id' => $verified->credentialId(),
            'public_key' => $verified->publicKey(),
            'transports' => $verified->transports(),
        ]);

        return response()->json(['registered' => true]);
    }
}

On the front end, the browser API does the heavy lifting:

// resources/js/passkeys.js

async function registerPasskey(name) {
    const options = await fetch('/passkeys/register/options', {
        method: 'POST',
        headers: { 'X-CSRF-TOKEN': csrfToken() },
    }).then((r) => r.json());

    const credential = await navigator.credentials.create({
        publicKey: parseCreationOptions(options),
    });

    await fetch('/passkeys/register', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'X-CSRF-TOKEN': csrfToken(),
        },
        body: JSON.stringify({ name, credential: serialize(credential) }),
    });
}

The Authentication Endpoints

public function authenticationOptions(Request $request): JsonResponse
{
    $options = Passkeys::authenticationOptions();

    $request->session()->put('passkey_auth_challenge', $options->challenge());

    return response()->json($options);
}

public function authenticate(Request $request): JsonResponse
{
    $passkey = Passkeys::verifyAuthentication(
        credential: $request->input('credential'),
        challenge: $request->session()->pull('passkey_auth_challenge'),
    );

    $passkey->forceFill(['last_used_at' => now()])->save();

    auth()->login($passkey->user, remember: true);

    $request->session()->regenerate();

    return response()->json(['authenticated' => true]);
}

One front-end detail worth shipping on day one: conditional UI. Adding autocomplete="username webauthn" to your email input lets the browser surface saved passkeys in the same autofill dropdown users already trust. Adoption rates are meaningfully better when the passkey appears where the password used to, instead of behind a separate button nobody clicks.

Device Management UI

Every passkey deployment needs a management screen, and it's where product decisions hide. Ours went through three revisions. The essentials:

List each passkey with its user-chosen name, creation date, and last_used_at. Users forget which device is which; the timestamp is what makes deletion feel safe.
Allow renaming. "iCloud Keychain" means nothing to someone with three Apple devices.
Guard deletion. If a user has gone passwordless, refuse to delete their final passkey until another one exists or a password is set. This one check prevents a whole category of lockout tickets.
Require a fresh authentication (password confirm or recent passkey assertion) before adding or removing credentials. Session hijacking shouldn't be enough to plant an attacker's passkey.

Why Is the Relying Party ID a One-Way Door?

The relying party ID is the domain your credentials are welded to, and it's the single most consequential configuration value in this entire feature. Every passkey your users register is scoped to it, permanently. Get it wrong and there is no migration script, because the private keys live on devices you don't control.

The scoping rules come straight from the spec (W3C WebAuthn Level 2). The RP ID must be the origin's registrable domain or a suffix of it. In practice:

RP ID example.com works for example.com, app.example.com, and staging.example.com.
RP ID app.example.com works only on app.example.com. Credentials registered there are invisible to example.com and to any sibling subdomain.
RP ID example.com will never work from example.net, no matter what you do.

Our advice: set the RP ID to your apex domain unless you have a concrete reason not to, such as genuinely independent products on separate subdomains. The apex gives you room to move the app between subdomains later without stranding credentials.

The scenario that actually burns people is the rebrand. If you launch passkeys on oldname.com and later move to newname.com, every passkey dies at the moment of cutover. Not "needs re-sync". Dead. Your migration plan becomes "keep the old domain serving auth indefinitely" or "force every user through re-enrollment", and both are miserable. If a domain change is even a remote possibility, delay the passkey launch until the domain is settled.

There's a quieter version of the same trap that we see on our own platform. Deploynix gives every new site a vanity subdomain (yourapp.deploynix.cloud) so you can deploy before DNS is sorted. That's great for smoke-testing, but if you enable passkey registration while users are hitting the vanity domain and then move to your real custom domain, those credentials are scoped to deploynix.cloud infrastructure and won't follow you. Treat the vanity domain as pre-production for anything WebAuthn-related, and only open passkey enrollment once traffic is on the final domain.

One more nuance: your staging environment on staging.example.com with RP ID example.com will happily accept production passkeys, because the RP ID matches. If you want staging credentials isolated (you usually do), set staging's RP ID to the full staging hostname in that environment's config.

Why Do You Need Real HTTPS Everywhere, Including Staging?

WebAuthn only exists in secure contexts. Browsers do not expose navigator.credentials over plain HTTP; the API is simply absent, per the spec's secure-context requirement (W3C WebAuthn Level 2). The single exception is localhost, which browsers treat as secure for development. There is no flag, header, or workaround for a real hostname served over HTTP.

This has a consequence teams keep rediscovering the hard way: you cannot credibly test passkeys on an HTTP staging server. Self-signed certificates are nearly as bad. Some browsers refuse WebAuthn entirely behind certificate warnings, others behave inconsistently, and either way your QA pass is exercising code paths your users will never hit. If staging doesn't have a real certificate on a real domain, your passkey testing is fiction.

So the infrastructure prerequisite list is short but strict: valid TLS on production, valid TLS on staging, and valid TLS on any preview environment where someone might click "Add a passkey". If your certificate story is shaky anywhere in that chain, fix it before writing a line of ceremony code. Our production security checklist puts HTTPS at the top for exactly this class of reason: modern browser APIs increasingly refuse to function without it.

How This Works on Deploynix

We built our SSL handling around the assumption that every environment deserves a real certificate, and passkeys are the feature that turns that from nice-to-have into hard requirement.

Every site you add gets a free Let's Encrypt certificate provisioned and auto-renewed, staging subdomains included. Because staging runs on a real subdomain with a real cert, the WebAuthn ceremonies behave exactly as they will in production, including the RP ID scoping behavior described above. Wildcard certificates cover multi-subdomain setups, and the details (issuance, renewal, wildcard DNS validation) are in our complete guide to SSL certificates on Deploynix.

Preview environments matter more than you'd expect here. Auth changes are exactly the kind of PR you want reviewed on a live URL rather than in screenshots, and because preview environments for pull requests come up with valid HTTPS, a reviewer can register a real passkey against the preview build from their own laptop before the merge.

Two more pieces of the platform earn their keep during a rollout. Zero-downtime deploys with one-click rollback mean an auth regression is a rollback away instead of an incident, which lowers the stakes of shipping the enrollment prompts iteratively. And server monitoring with alerts gives you a place to watch error rates on the ceremony endpoints as each rollout phase widens. None of this is passkey-specific machinery; it's the same baseline we'd recommend for any change to your login path, alongside the hardening in securing your Laravel deployment.

How Do You Test WebAuthn Without a Fingerprint Reader?

You don't need a drawer of YubiKeys or a CI runner with Face ID. Browsers ship virtual authenticators precisely for this.

For manual testing, Chrome DevTools has a WebAuthn panel (More tools, then WebAuthn) where you can add a virtual authenticator, choose its transport and whether it supports resident keys and user verification, then run your registration and login flows against it. Registered credentials appear in the panel, which makes it easy to verify what your server actually stored.

For automated coverage, Playwright can drive the same machinery over the Chrome DevTools Protocol:

// tests/e2e/passkey-login.spec.js

const client = await page.context().newCDPSession(page);
await client.send('WebAuthn.enable');

const { authenticatorId } = await client.send('WebAuthn.addVirtualAuthenticator', {
    options: {
        protocol: 'ctap2',
        transport: 'internal',
        hasResidentKey: true,
        hasUserVerification: true,
        isUserVerified: true,
    },
});

With that in place, navigator.credentials.create() and .get() resolve automatically in the test run, no human finger required. We run a small suite like this against preview environments before auth-related merges.

On the PHP side, keep your Pest feature tests focused on what the server owns: challenge issuance and expiry, session challenge consumption (a challenge must not verify twice), the deletion guard on a user's last credential, and the re-authentication requirement on the management endpoints. Use model factories for Passkey records and treat the cryptographic verification itself as a boundary you exercise through the browser-level tests. Trying to hand-forge attestation objects in PHPUnit is effort better spent elsewhere.

One habit worth adopting: test at least once on a real device per platform family before each rollout phase. Virtual authenticators validate your protocol flow, but they won't catch a confusing iCloud Keychain prompt or a Windows Hello dialog that appears behind the browser window. The last-mile UX lives outside your code.

What Does a Sane Rollout Plan Look Like?

The technology is the easy half. The rollout is where passkey projects succeed or quietly stall. The plan that has worked, for us and for most teams we've talked to, is three phases with explicit gates between them. The unifying rule: passwords remain a working fallback until the data says otherwise, and "day one" is never the day you remove them.

Phase 1: Opt-In for People Who Ask

Ship passkey registration in account settings behind a feature flag, announce it in a changelog, and say nothing else. Your early adopters (the users who already use password managers and hardware keys) will find it, exercise your edge cases, and file better bug reports than QA ever will.

What to watch during this phase: ceremony completion rate (started registrations vs. stored credentials), errors by browser and platform, and whether anyone hits the last-credential deletion guard. A completion rate below roughly 90 percent usually means a UX problem, not a protocol one; hunt for it before widening the audience.

Phase 2: Prompt After Successful Login

Once the flow is boring, start prompting: immediately after a successful password login, offer "Add a passkey to skip your password next time". This moment converts far better than a settings page ever will, because the user has just experienced the friction you're removing and has already proven their identity, so enrollment is safe.

Cap the prompt. Ask at most once every few weeks per user, and honor a "don't ask again" choice permanently. An authentication feature that nags becomes an authentication feature users resent.

Expect the support load to shift rather than spike. Password-reset tickets start declining; in their place come "what is a passkey" questions and a steady trickle of "it's asking for my fingerprint and I don't want that" concerns. Write the help-center article before Phase 2, not after. Two paragraphs explaining that the biometric never leaves the device prevents most of these tickets.

Phase 3: Default for New Signups

When your existing-user metrics are healthy, make passkey creation the default path on registration, with password creation demoted to a secondary link. New users have no habit to unlearn, so this is where adoption compounds.

Even here, keep the password path alive. Locked-down corporate devices, shared machines, and unsupported browsers all still exist. The end state for most apps isn't "no passwords"; it's "passwords are the rarely used fallback, monitored accordingly". Going fully passwordless is a Phase 4 that most teams, honestly, never need to reach, and it should wait until password logins are a rounding error in your metrics.

Throughout all three phases, watch your login funnel the way you'd watch a checkout funnel: passkey login success rate, fallback-to-password rate, and time-to-authenticate. A rising fallback rate on one platform is your early warning that an OS update changed a prompt somewhere.

How Should You Handle Account Recovery?

Here's the uncomfortable truth: account recovery is the actual hard problem, and passkeys make it harder before they make it easier. With passwords, "I forgot" resolves through an email reset. With a lost device holding an unsynced passkey, there's nothing to reset. The private key is gone.

Synced passkeys soften this considerably. A user whose iPhone falls in a lake restores iCloud Keychain on the replacement phone and their passkeys come back. But hardware keys don't sync, some users disable sync, and platform account recovery becomes your problem by proxy. Design for the worst case:

Encourage a second passkey at enrollment. After a user registers their first credential, prompt for one more on a different device. Two independent authenticators eliminate most lockout scenarios outright.
Issue recovery codes, exactly as you would for TOTP. One-time-use, hashed at rest, shown once. Boring and proven.
Decide what email reset means now. If password reset via email still exists, your account security equals your users' mailbox security, same as before passkeys. That's an acceptable, honest trade-off during transition; just make the decision explicitly rather than by default, and rate-limit and alert on the reset path.
Write the support playbook before launch. When someone fails all automated recovery, what does your team verify before restoring access? Recovery-by-support-ticket is the channel attackers target once the front door hardens; social engineering against help desks is a well-worn playbook. Define the identity checks, log every manual recovery, and review them.

Whatever you choose, the recovery path is now your weakest link, because attackers route around strength. It deserves the same review rigor as the login path itself, and it belongs on the agenda the next time you run a step-by-step security audit of your server and application.

What Are the Honest Downsides?

We're bullish on passkeys, but a few realities deserve plain statement before you commit a quarter to this.

Enterprise-managed devices are the biggest friction. Plenty of corporate laptops run with platform authenticators restricted, browser sync disabled by policy, or hardware keys mandated and everything else blocked. If you sell B2B, assume a meaningful slice of your users cannot enroll a synced passkey, and keep password-plus-TOTP as a fully supported path for them indefinitely. Ask your largest customers' IT teams before Phase 3, not after.

Cross-device sync is a trust trade-off, not a free lunch. A synced passkey is as secure as the Apple or Google account it syncs through. For most consumers that account is far better protected than their password habits, so it's a clear net win. But some security teams reasonably dislike delegating part of the trust chain to a platform vendor, and for high-security contexts, device-bound credentials on hardware keys remain the stricter answer. Know which posture your product needs.

There's also the long tail: shared family tablets, kiosk machines, users on old browsers, and people who are simply uncomfortable with a fingerprint prompt regardless of where the biometric is processed. In 2026 browser support is excellent, but "excellent" isn't "universal", and your login form has to serve everyone. That's the real reason every rollout phase above keeps a fallback: not caution for its own sake, but because the edge cases are people.

None of these are reasons to skip passkeys. They're reasons the rollout is phased, the password path survives, and the metrics get watched.

FAQ

Do passkeys replace two-factor authentication?

Functionally, a passkey with user verification is already two factors in one gesture: possession of the device plus the biometric or PIN that opens it. Most teams treat passkey login as satisfying their MFA requirement. If a compliance framework you're subject to names OTP specifically, check with your auditor before dropping TOTP.

What happens when a user loses their phone?

If the passkey was synced through iCloud Keychain or Google Password Manager, it restores with the platform account on the new device. If it was device-bound, that credential is gone, which is why you should encourage a second passkey at enrollment and issue recovery codes. Recovery design, not the protocol, determines how painful this day is.

Can I test passkeys in local development without HTTPS?

Yes, on localhost only, which browsers treat as a secure context. Any other hostname, including .test domains and LAN IPs, requires valid HTTPS or the WebAuthn API won't exist on the page. For staging and preview environments, use real certificates on real domains.

Will passkeys registered on staging work in production?

Only if the relying party IDs align, and usually you don't want them to. Set staging's RP ID to the full staging hostname so its credentials stay isolated, and set production's RP ID to your apex domain. And remember the reverse trap: if production's RP ID is the apex, production passkeys will work on staging subdomains too.

Should we remove passwords once passkey adoption is high?

Not on any schedule you set in advance. Let the metrics decide: when password logins are a fraction of a percent and your recovery flow has survived real-world contact, going passwordless becomes a small step instead of a leap. Most apps run hybrid indefinitely, and that's a fine end state.

Where to Start This Week

Passkeys are the rare security upgrade that improves the user experience while removing an entire attack class. The Laravel 13 support takes care of the cryptography; your job is the operational judgment around it. Pick your relying party ID like it's permanent, because it is. Give staging a real certificate so your testing means something. Roll out in phases with passwords intact. And spend your design effort on recovery, because that's where the hard failures live.

The concrete next step: get a staging environment on a real subdomain with valid HTTPS, wire up the registration ceremony behind a feature flag, and run the flow end to end with a Chrome virtual authenticator and then with your own thumb. Once that loop feels boring, you're ready for Phase 1. On Deploynix, the staging cert is already handled the moment you add the site, so the infrastructure part of that list takes about as long as reading this sentence.

Laravel 13 Native Attributes: Slimmer Models and a Cleaner Codebase

Deploynix — Mon, 17 Aug 2026 11:04:11 +0000

Open the biggest model in your app right now. Ours was Server.php, and before we refactored it this spring, the first 60 lines were pure configuration: a $table override from an old naming decision, a 14-entry $fillable array, $hidden for two token columns, a casts() method with nine entries, and a $touches array nobody had questioned since 2024. Sixty lines before the first line of actual behavior. Every Laravel developer has a model like this, and most of us stopped seeing the clutter years ago.

Laravel 13, released on March 17, 2026, finally gives that clutter a proper home. The framework now supports native PHP attributes in more than 15 locations, replacing property declarations like $table, $hidden, and $fillable on models and extending the same treatment to event listeners, notifications, mailables, and broadcast events (Laravel News, 2026). Crucially, the release ships with no app-code breaking changes: your property-based models keep working exactly as before (KrishaWeb, 2026).

We've now migrated most of the Deploynix codebase to the attribute style, and we deploy Laravel apps for a living, so we've also watched dozens of customer apps make the same transition. This post covers what attributes actually are, why the old property-based configuration aged badly, a full tour of the new surface with before/after code, and a migration plan that won't wreck your sprint. If you're still planning the version jump itself, start with our guide to upgrading to Laravel 13 in production with zero downtime.

Key Takeaways- Laravel 13 (March 17, 2026) adds native PHP attributes to 15+ framework locations, with PHP 8.3 as the minimum version (Laravel News, 2026) - Property-based config still works; there are no app-code breaking changes - Attributes are reflection-read and cached, so runtime cost is effectively zero - Migrate incrementally, one namespace at a time, with tests and small deploys

What Are PHP Attributes, and Why Did Laravel Adopt Them Now?

PHP attributes are structured metadata you attach to classes, methods, and properties, introduced in PHP 8.0 back in 2020. The engine parses them at compile time and exposes them through reflection. Laravel 13 leans on them across 15+ framework locations, a move made practical by the framework's new PHP 8.3 minimum requirement (PHP Everyday, 2026).

If you've written a #[Test] annotation in PHPUnit or a #[Route] in Symfony, you already know the shape. An attribute is a small, dedicated class. When you write #[Table('legacy_servers')] above a model, you're instantiating real, typed, autoloadable code that your IDE can resolve, your static analyzer can inspect, and the framework can read through reflection.

That last part matters more than it sounds. Laravel has always been a convention-driven framework, and conventions used to live in loosely typed protected properties and magic strings. Attributes let the same conventions live in declared, discoverable classes instead. Nothing about Eloquent's behavior changed in Laravel 13. What changed is where the configuration lives and how much of it your tooling can actually see.

Laravel didn't invent this pattern overnight, either. The framework had been testing the water for two major versions: #[ObservedBy] and #[ScopedBy] on models, attribute-based route model binding tweaks, and container contextual attributes all landed earlier. Laravel 13 is the point where the pattern went from a garnish to the recommended default. And with PHP 8.5 now stable, the language side of this story is thoroughly settled.

Why Did Property-Based Configuration Age So Badly?

The short answer: property config scattered one model's identity across five untyped declarations, and tooling could never fully understand any of them. Laravel 13's attribute push exists precisely because the framework team saw the same friction at scale across 15+ configuration points (Laravel News, 2026). Three specific problems kept biting us.

First, magic strings everywhere. protected $table = 'legacy_servers' is a string the framework interprets at runtime. So is every entry in $fillable, $hidden, $appends, and casts(). Rename a column, and your IDE's refactoring tools skip every one of those strings. We once shipped a bug where a renamed ip_address column stayed in $fillable as the old name for three weeks. Nothing errored. Mass assignment just silently dropped the field.

Second, IDE blindness. A protected array property has no schema. Your editor can't tell you that 'datetime' is a valid cast and 'date_time' isn't, because both are just strings in an array. Attribute classes have constructors with typed parameters, so autocomplete, go-to-definition, and inline docs all work the way they do for normal code.

Third, scattered conventions. In a ten-person team, one developer alphabetizes $fillable, another groups it by feature, a third switched that model to $guarded = [] in 2023, and a fourth added a casts() method below 200 lines of scopes. None of these choices is wrong. Collectively, they mean no two models read the same way. Attributes don't magically enforce consistency, but they give configuration one canonical position, at the top of the class, in a syntax that linters can actually check.

Was the old style unworkable? No. Plenty of successful apps will keep it for years. But if you've ever scrolled past 60 lines of arrays to find a relationship method, you know the ergonomic ceiling.

A Tour of the Laravel 13 Attribute Surface

The rest of this section walks through the four areas where attributes change day-to-day code the most: models, event listeners, notifications and mailables, and broadcast events. All of the "before" examples remain fully valid in Laravel 13, since the release intentionally avoided app-code breaking changes (KrishaWeb, 2026).

Models: Table, Fillable, Hidden, and Casts

Here's a trimmed version of our real Deployment model, before and after. First, the Laravel 12 style:

class Deployment extends Model
{
    use HasFactory;

    protected $table = 'site_deployments';

    protected $fillable = [
        'site_id',
        'server_id',
        'commit_sha',
        'branch',
        'status',
        'triggered_by',
    ];

    protected $hidden = [
        'deploy_token',
    ];

    protected function casts(): array
    {
        return [
            'status' => DeploymentStatus::class,
            'is_rollback' => 'boolean',
            'finished_at' => 'datetime',
        ];
    }
}

And the Laravel 13 attribute equivalent:

use Illuminate\Database\Eloquent\Attributes\Casts;
use Illuminate\Database\Eloquent\Attributes\Fillable;
use Illuminate\Database\Eloquent\Attributes\Hidden;
use Illuminate\Database\Eloquent\Attributes\Table;

#[Table('site_deployments')]
#[Fillable(['site_id', 'server_id', 'commit_sha', 'branch', 'status', 'triggered_by'])]
#[Hidden(['deploy_token'])]
#[Casts(['status' => DeploymentStatus::class, 'is_rollback' => 'boolean', 'finished_at' => 'datetime'])]
class Deployment extends Model
{
    use HasFactory;
}

The class body now contains only behavior: relationships, scopes, business methods. Configuration sits above the class name where you read it once and move on. Here's how the common model properties map:

Laravel 12 property

Laravel 13 attribute

Notes

protected $table

#[Table('...')]

Class-level, single value

protected $fillable

#[Fillable([...])]

Same array semantics

protected $guarded

#[Guarded([...])]

Mutually exclusive with Fillable, as before

protected $hidden

#[Hidden([...])]

Serialization only, unchanged behavior

casts() method

#[Casts([...])]

Complex closures stay in the method

protected $touches

#[Touches([...])]

Same relation-name strings

protected $with

#[With([...])]

Eager-load defaults

One honest caveat: casts that need runtime logic, like a cast that varies by tenant, still belong in the casts() method. Attributes are static metadata. In our experience that covers maybe 5 percent of casts, and mixing the two on one model works fine.

Event Listeners: Retiring the EventServiceProvider Wiring

Event discovery has been drifting away from manual registration since Laravel 11, the same release cycle that started deprecating app/Http/Kernel.php, which Laravel 13 has now removed entirely (PHP Everyday, 2026). Attributes finish the job for listeners. Before, the mapping lived in a provider, far from the listener itself:

class EventServiceProvider extends ServiceProvider
{
    protected $listen = [
        DeploymentFinished::class => [
            NotifyTeamOfDeployment::class,
            RecordDeploymentMetrics::class,
        ],
    ];
}

In Laravel 13, the listener declares its own subscription, including queue configuration:

use Illuminate\Events\Attributes\ListensTo;
use Illuminate\Queue\Attributes\OnQueue;

#[ListensTo(DeploymentFinished::class)]
#[OnQueue('notifications')]
class NotifyTeamOfDeployment implements ShouldQueue
{
    public function handle(DeploymentFinished $event): void
    {
        // ...
    }
}

This is the change we'd rank highest for maintainability. When wiring lived in the provider, deleting a listener class without cleaning the provider produced a runtime error in production, not a static one. With the attribute, the listener is self-describing: open the file, and you know what it listens to and which queue it runs on. Nothing to keep in sync.

Notifications and Mailables

Notifications got the same treatment for channel routing. The old via() method returning an array of strings is exactly the kind of stringly-typed convention attributes were built to replace:

// Before: Laravel 12
class DeploymentFailedNotification extends Notification implements ShouldQueue
{
    public function via(object $notifiable): array
    {
        return ['mail', 'slack', 'database'];
    }
}

// After: Laravel 13
#[Channels(['mail', 'slack', 'database'])]
class DeploymentFailedNotification extends Notification implements ShouldQueue
{
    // via() no longer needed for static channel lists
}

Dynamic routing, where channels depend on the notifiable's preferences, keeps the via() method. The attribute covers the static case, which for most apps is the overwhelming majority. Mailables similarly move envelope metadata like subject lines and reply-to addresses into #[Envelope] attribute parameters, leaving the class body to focus on content building. If your app leans hard on notifications, this refactor pairs well with the queue and worker tuning items in our list of 20 quick performance wins for production Laravel apps.

Broadcast Events

Broadcast events previously mixed metadata into methods: broadcastOn(), broadcastAs(), and a class body that was mostly ceremony. Laravel 13 lets simple cases collapse:

// Before: Laravel 12
class ServerMetricsUpdated implements ShouldBroadcastNow
{
    public function broadcastOn(): array
    {
        return [new PrivateChannel('servers.'.$this->server->id)];
    }

    public function broadcastAs(): string
    {
        return 'metrics.updated';
    }
}

// After: Laravel 13
#[BroadcastOn('private:servers.{server}')]
#[BroadcastAs('metrics.updated')]
class ServerMetricsUpdated implements ShouldBroadcastNow
{
    public function __construct(public Server $server) {}
}

The channel template syntax resolves {server} against the event's public properties. For our Reverb-powered dashboards, this cut most broadcast event classes roughly in half. Events with genuinely dynamic channel logic keep their methods, same story as casts and notification channels.

Should You Go Attribute-First, Stay Property-Based, or Run Mixed?

Yes, mixed is fine, and it's how nearly everyone will actually live for the next year or two. Laravel 13 guarantees both styles work side by side with no breaking changes, and even a single class can combine an attribute for $table with a casts() method (KrishaWeb, 2026). Still, it helps to pick a direction deliberately.

Attribute-First

Strengths: Configuration is typed, discoverable, and consistently positioned. IDE autocomplete and go-to-definition work on config. Listener wiring is self-documenting. New classes are visibly slimmer, often by 30 to 60 lines on large models.

Best for: Actively developed apps already on Laravel 13, teams that generate new models and listeners weekly, codebases with heavy static analysis investment (PHPStan or Psalm in CI).

Considerations: Requires PHP 8.3 or newer, and every developer needs a short adjustment period. Dynamic config still needs methods, so you'll never be 100 percent attributes. Older tutorials and Stack Overflow answers will show the property style for years.

Property-Based (Status Quo)

Strengths: Zero migration effort. Every Laravel developer on Earth reads it fluently. Fifteen years of documentation, packages, and examples assume it. Fully supported in Laravel 13 with no deprecation warnings.

Best for: Small stable apps in maintenance mode, teams mid-upgrade with bigger problems to solve first, packages that must support Laravel 12, which remains an actively supported release.

Considerations: You keep every ergonomic problem described above: magic strings, IDE blindness, scattered conventions. New hires arriving from attribute-first codebases will find it dated. The framework's documentation now leads with attributes, so the property style slowly becomes the "legacy" path in docs and examples.

Mixed, With a Convention

Strengths: Lets you migrate incrementally with no big-bang risk. New code gets the modern style immediately, and old code migrates when touched.

Best for: Most real production teams, honestly. Anyone with more than 50 models.

Considerations: Without a written convention it decays into inconsistency, the exact disease you're treating. Write the rule down: for us it's "new classes use attributes; any model you materially edit gets converted in the same PR; no drive-by conversions in unrelated PRs." That last clause keeps diffs reviewable.

Rector deserves a mention here. The Rector Laravel rule set gained attribute-migration rules shortly after release, and they handle the mechanical 90 percent: $table, $fillable, $hidden, static casts, and listener wiring. We ran it namespace by namespace rather than repo-wide, reviewed each diff by hand, and caught two models where $guarded and $fillable had somehow coexisted for years. The tool converts syntax; it can't convert judgment, so treat its output as a draft.

What About Static Analysis and IDE Support?

This is where attributes quietly pay for the whole migration. Because an attribute is a real class with a real constructor, #[Casts(['status' => DeploymentStatus::class])] gives your tooling a ::class constant it can verify, rename, and track for usages. The string 'status' is still a string, but PHPStan's Laravel extension can now cross-check attribute arrays against your migrations and model doc-blocks far more reliably than it ever could with protected properties inherited through Eloquent's magic.

Concretely, here's what improved for us after converting: renaming a cast enum class updates the attribute automatically via IDE refactoring. Find-usages on an event class now surfaces every #[ListensTo] declaration, which made an event-flow audit take an afternoon instead of a week. And PHPStan flags a typo'd cast type at level 6, where before it sailed through at max level because arrays of strings carry no schema.

PhpStorm's 2026.1 release and the Laravel Idea plugin both shipped completion and inspections for the new attributes within weeks of the March release. If your team's editor situation is more varied, the fallback story is still fine, since attributes are plain PHP syntax that highlights correctly everywhere. The one rough edge we hit: some older code-generation tools still scaffold property-style models, so check your stubs. php artisan stub:publish and a ten-minute edit brings your make:model output into the attribute era.

Do Attributes Cost Anything at Runtime?

No, and this deserves a direct answer because "reflection" makes performance-minded engineers flinch. Laravel reads attribute metadata through reflection once, then caches the result in the same metadata caches that already store property-based configuration. The framework team confirmed there's no measurable runtime difference between the two styles (Laravel News, 2026).

We verified this ourselves anyway, because trust is good and benchmarks are better. On our own API, p50 response times before and after converting roughly 80 models were identical within noise, under half a millisecond of variance across a week of production traffic on both sides of the deploy. With opcache and Laravel's bootstrap caching in play, attribute reflection happens at cache-build time, not per request.

There's one operational implication worth knowing: because attribute metadata participates in framework caching, your deploy pipeline should run the standard cache rebuild steps, php artisan optimize or the equivalent, on every release. If your pipeline dates from a couple of major versions ago, our rundown of Laravel 12's deployment changes covers the cache and Kernel-removal groundwork that Laravel 13 builds on, since app/Http/Kernel.php had been deprecated since Laravel 11 and is now gone entirely (PHP Everyday, 2026).

When Is the Refactor Not Worth It?

Skip it when the codebase is small, stable, and rarely touched. A 15-model internal tool that gets two commits a quarter gains nothing from a mechanical rewrite, and every line you change is a line you can break. Laravel 13 supports the property style indefinitely with no deprecation timeline announced, so "never" is a legitimate migration date (KrishaWeb, 2026).

We'd also hold off in three other situations. If you're mid-upgrade and not yet stable on Laravel 13, finish the upgrade first; mixing a version jump with a style migration doubles your rollback ambiguity when something breaks. If your test coverage on models and listeners is thin, write the tests first, because a mechanical refactor without a safety net is just risk with extra steps. And if you maintain a package supporting both Laravel 12 and 13, stay property-based until you drop 12, which is still a supported release and will be for a while.

Ask one question: will a human edit this code in the next year? If yes, the refactor buys you compounding readability every time someone opens the file. If no, leave it alone. Refactoring is an investment, and investments need a return window. The broader trend data in our state of Laravel deployment in 2026 report suggests most actively developed apps hit that bar easily, while a long tail of maintenance-mode apps never will, and that's fine.

A Pragmatic Migration Plan for a Production Codebase

Here's the plan we used on our own app and now recommend to customers. Total elapsed time for us: about three weeks of background work, never blocking feature development, across roughly 80 models, 60 listeners, and 40 notifications.

Phase

Scope

Safety net

Deploy size

One low-risk model namespace (e.g. App\Models\Billing)

Existing feature tests + serialization snapshot tests

Single small deploy

Remaining model namespaces, one per PR

Rector draft, hand review, full suite per PR

One namespace per deploy

Listeners + EventServiceProvider teardown

Event fake assertions on every event/listener pair

Two deploys

Notifications, mailables, broadcast events

Notification fakes + a staging click-through

Two or three deploys

Stub updates + written convention in CONTRIBUTING

CI lint rule rejecting new property-style config

One deploy

Three principles make this boring, in the good sense. First, one namespace at a time. A repo-wide PR touching 200 files is unreviewable, and unreviewable PRs are where mechanical refactors go wrong. A 12-file PR gets real review in ten minutes.

Second, tests are the contract. Before converting a model, we made sure something asserted its mass-assignment behavior and its serialized shape, because $fillable and $hidden mistakes are silent by design. A cheap trick: a snapshot test that serializes one factory instance of every model and diffs the keys. It caught our only real conversion bug, a Hidden attribute that listed api_token while the property had said api_token_hash.

Third, deploy in small batches, quickly. Don't let five converted namespaces pile up unreleased. Each phase should reach production within a day of merging, so if anything slips through, the suspect list is one small diff, not three weeks of them. This is standard advice for any refactor, but doubly so for one that changes how configuration is read rather than what it says.

Shipping the Refactor on Deploynix

We ran this exact migration on Deploynix itself, using Deploynix, so here's the concrete workflow rather than the theory. Nothing below is specific to attributes; it's how we ship any large mechanical refactor where the blast radius is "every model in the app."

Each phase branch went through our staging-to-production pipeline. A push to the branch triggered a staging deploy via the GitHub integration, and staging ran the same PHP version as production, pinned per site, which mattered during the window when production was on PHP 8.3 and we were validating 8.5. On staging we ran the full Pest suite plus the serialization snapshot check against a production-shaped database, then let the branch soak for a few hours while monitoring watched error rates and queue depth.

Production deploys used the standard release model: each deploy builds into a fresh release directory, runs composer install, php artisan optimize, and migrations, and then goes live through an atomic symlink switch. Zero downtime, and critically for a refactor like this, the previous release stays on disk untouched. When our Phase 3 deploy surfaced a listener that Rector had converted but whose queue name attribute pointed at a queue Horizon wasn't consuming, we rolled back with one click, the symlink flipped to the prior release, and total customer-facing weirdness lasted under a minute. We fixed the queue name, redeployed, done. That failure would have been a tense evening with a rsync-based deploy; with releases and instant rollback it was a Slack message. The mechanics are the same ones we describe in how to roll back a failed deployment in 30 seconds.

The lesson we'd generalize: large mechanical refactors are only as scary as your rollback story. If reverting is instant and boring, you can ship a 12-file conversion PR every afternoon without ceremony, and the whole migration becomes background noise. If reverting is a 40-minute manual procedure, you'll batch changes into big risky releases, which is exactly backwards. Get the deployment mechanics right first, whatever platform or scripts you use, and the refactor itself becomes the easy part.

FAQ

Do I have to migrate to attributes when upgrading to Laravel 13?

No. Laravel 13 ships with no app-code breaking changes, and property-based configuration like $fillable and $table continues to work with no deprecation warnings (Laravel News, 2026). The upgrade and the refactor are separate projects. Do the upgrade first, stabilize, then migrate styles at your own pace.

Can attributes and properties coexist in the same model?

Yes, and mixing is officially supported. A model can use #[Table] and #[Fillable] while keeping a casts() method for dynamic casts (KrishaWeb, 2026). If both styles define the same setting, the attribute wins, but we'd treat that situation as a bug and let a lint rule catch it.

What's the minimum PHP version for Laravel 13's attributes?

Laravel 13 requires PHP 8.3 or newer (PHP Everyday, 2026). The attribute syntax itself dates back to PHP 8.0, so the constraint is the framework's floor, not the language feature. With PHP 8.5 now stable, we'd provision new servers on 8.4 or 8.5 and pin per site.

Do attributes slow down requests since they use reflection?

No. Attribute metadata is read via reflection once and cached alongside Laravel's existing bootstrap and metadata caches, so per-request cost is effectively zero (Laravel News, 2026). Our own production benchmarks showed no measurable p50 difference across 80 converted models. Just keep php artisan optimize in your deploy pipeline.

Can Rector automate the conversion?

Mostly. Rector's Laravel rule set converts the mechanical cases: $table, $fillable, $hidden, static casts, and listener registrations. Treat its output as a draft, review every diff, and leave dynamic configuration, like tenant-dependent casts or preference-based notification channels, in methods where it belongs. Run it per namespace, not repo-wide.

Where to Go From Here

Attributes won't change what your app does. They change how quickly the next engineer understands it, and over a codebase's lifetime that's the cost that dominates. Laravel 13 made the modern style available everywhere without forcing anyone's hand, which is exactly the right way to evolve a 15-year-old framework. Our advice: don't schedule a heroic rewrite. Pick one quiet model namespace this sprint, convert it behind your test suite, ship it in a small deploy, and let the pattern spread PR by PR from there.

If you want the fuller operational picture first, from server provisioning through release strategy, our definitive guide to Laravel deployment in 2026 covers the pipeline foundations that make refactors like this one routine instead of risky. Start there, then go slim down that 60-line model header. It's been waiting long enough.

Laravel 13 Native Attributes: Slimmer Models and a Cleaner Codebase

Deploynix — Wed, 12 Aug 2026 08:03:09 +0000

Key Takeaways- Laravel 13 (March 17, 2026) adds native PHP attributes to 15+ framework locations, with PHP 8.3 as the minimum version (Laravel News, 2026) - Property-based config still works; there are no app-code breaking changes - Attributes are reflection-read and cached, so runtime cost is effectively zero - Migrate incrementally, one namespace at a time, with tests and small deploys

What Are PHP Attributes, and Why Did Laravel Adopt Them Now?

Why Did Property-Based Configuration Age So Badly?

Was the old style unworkable? No. Plenty of successful apps will keep it for years. But if you've ever scrolled past 60 lines of arrays to find a relationship method, you know the ergonomic ceiling.

A Tour of the Laravel 13 Attribute Surface

Models: Table, Fillable, Hidden, and Casts

Here's a trimmed version of our real Deployment model, before and after. First, the Laravel 12 style:

class Deployment extends Model
{
    use HasFactory;

    protected $table = 'site_deployments';

    protected $fillable = [
        'site_id',
        'server_id',
        'commit_sha',
        'branch',
        'status',
        'triggered_by',
    ];

    protected $hidden = [
        'deploy_token',
    ];

    protected function casts(): array
    {
        return [
            'status' => DeploymentStatus::class,
            'is_rollback' => 'boolean',
            'finished_at' => 'datetime',
        ];
    }
}

And the Laravel 13 attribute equivalent:

use Illuminate\Database\Eloquent\Attributes\Casts;
use Illuminate\Database\Eloquent\Attributes\Fillable;
use Illuminate\Database\Eloquent\Attributes\Hidden;
use Illuminate\Database\Eloquent\Attributes\Table;

#[Table('site_deployments')]
#[Fillable(['site_id', 'server_id', 'commit_sha', 'branch', 'status', 'triggered_by'])]
#[Hidden(['deploy_token'])]
#[Casts(['status' => DeploymentStatus::class, 'is_rollback' => 'boolean', 'finished_at' => 'datetime'])]
class Deployment extends Model
{
    use HasFactory;
}

Laravel 12 property

Laravel 13 attribute

Notes

protected $table

#[Table('...')]

Class-level, single value

protected $fillable

#[Fillable([...])]

Same array semantics

protected $guarded

#[Guarded([...])]

Mutually exclusive with Fillable, as before

protected $hidden

#[Hidden([...])]

Serialization only, unchanged behavior

casts() method

#[Casts([...])]

Complex closures stay in the method

protected $touches

#[Touches([...])]

Same relation-name strings

protected $with

#[With([...])]

Eager-load defaults

Event Listeners: Retiring the EventServiceProvider Wiring

class EventServiceProvider extends ServiceProvider
{
    protected $listen = [
        DeploymentFinished::class => [
            NotifyTeamOfDeployment::class,
            RecordDeploymentMetrics::class,
        ],
    ];
}

In Laravel 13, the listener declares its own subscription, including queue configuration:

use Illuminate\Events\Attributes\ListensTo;
use Illuminate\Queue\Attributes\OnQueue;

#[ListensTo(DeploymentFinished::class)]
#[OnQueue('notifications')]
class NotifyTeamOfDeployment implements ShouldQueue
{
    public function handle(DeploymentFinished $event): void
    {
        // ...
    }
}

Notifications and Mailables

Notifications got the same treatment for channel routing. The old via() method returning an array of strings is exactly the kind of stringly-typed convention attributes were built to replace:

// Before: Laravel 12
class DeploymentFailedNotification extends Notification implements ShouldQueue
{
    public function via(object $notifiable): array
    {
        return ['mail', 'slack', 'database'];
    }
}

// After: Laravel 13
#[Channels(['mail', 'slack', 'database'])]
class DeploymentFailedNotification extends Notification implements ShouldQueue
{
    // via() no longer needed for static channel lists
}

Broadcast Events

Broadcast events previously mixed metadata into methods: broadcastOn(), broadcastAs(), and a class body that was mostly ceremony. Laravel 13 lets simple cases collapse:

// Before: Laravel 12
class ServerMetricsUpdated implements ShouldBroadcastNow
{
    public function broadcastOn(): array
    {
        return [new PrivateChannel('servers.'.$this->server->id)];
    }

    public function broadcastAs(): string
    {
        return 'metrics.updated';
    }
}

// After: Laravel 13
#[BroadcastOn('private:servers.{server}')]
#[BroadcastAs('metrics.updated')]
class ServerMetricsUpdated implements ShouldBroadcastNow
{
    public function __construct(public Server $server) {}
}

Should You Go Attribute-First, Stay Property-Based, or Run Mixed?

Attribute-First

Best for: Actively developed apps already on Laravel 13, teams that generate new models and listeners weekly, codebases with heavy static analysis investment (PHPStan or Psalm in CI).

Property-Based (Status Quo)

Best for: Small stable apps in maintenance mode, teams mid-upgrade with bigger problems to solve first, packages that must support Laravel 12, which remains an actively supported release.

Mixed, With a Convention

Strengths: Lets you migrate incrementally with no big-bang risk. New code gets the modern style immediately, and old code migrates when touched.

Best for: Most real production teams, honestly. Anyone with more than 50 models.

What About Static Analysis and IDE Support?

Do Attributes Cost Anything at Runtime?

When Is the Refactor Not Worth It?

A Pragmatic Migration Plan for a Production Codebase

Phase

Scope

Safety net

Deploy size

One low-risk model namespace (e.g. App\Models\Billing)

Existing feature tests + serialization snapshot tests

Single small deploy

Remaining model namespaces, one per PR

Rector draft, hand review, full suite per PR

One namespace per deploy

Listeners + EventServiceProvider teardown

Event fake assertions on every event/listener pair

Two deploys

Notifications, mailables, broadcast events

Notification fakes + a staging click-through

Two or three deploys

Stub updates + written convention in CONTRIBUTING

CI lint rule rejecting new property-style config

One deploy

Shipping the Refactor on Deploynix

FAQ

Do I have to migrate to attributes when upgrading to Laravel 13?

Can attributes and properties coexist in the same model?

What's the minimum PHP version for Laravel 13's attributes?

Do attributes slow down requests since they use reflection?

Can Rector automate the conversion?

Where to Go From Here

PHP 8.5 in Production: The Pipe Operator, and Upgrading PHP-FPM Without Downtime

Deploynix — Sun, 09 Aug 2026 15:12:18 +0000

PHP 8.5 was released in November 2025 with the pipe operator, backtraces on fatal errors, closures in constant expressions, and the long-overdue array_first() and array_last() functions (Phoronix). Nine months later, in August 2026, the ecosystem has mostly caught up. Laravel, Symfony, and WordPress all run on it, and the major extension maintainers have shipped compatible builds (adoption guide).

So the question for most teams is no longer "does it work?" It's two more practical questions. First: which 8.5 features actually earn their place in a Laravel codebase, and which are syntax novelty? Second: how do you move a production PHP-FPM fleet from 8.4 to 8.5 without dropping a single request, and with a rollback you can execute in under a minute if something breaks?

We've upgraded a lot of servers through PHP version transitions, and we've watched the same mistakes repeat: in-place upgrades that remove the old runtime, extension mismatches discovered at 2 a.m., and queue workers silently running a different PHP version than the web tier. This post covers both halves: an honest review of what's useful in 8.5 for Laravel developers, and the exact Ubuntu 24.04 playbook for a side-by-side upgrade with instant rollback.

If you followed our PHP 8.4 upgrade guide last year, the mechanics here will feel familiar. The features, though, are a bigger deal this time.

Key Takeaways- PHP 8.5 (released November 2025) ships the pipe operator, fatal error backtraces, array_first()/array_last(), and constant expression improvements (Phoronix) - Fatal error backtraces alone justify the upgrade for production debugging - Adopt the pipe operator in greenfield code with an agreed style; hold off in legacy codebases - Upgrade side-by-side: install 8.5 next to 8.4, cut over per site at the nginx level, keep 8.4 for instant rollback

What Did PHP 8.5 Actually Ship?

PHP 8.5 landed on November 20, 2025 with five headline items: the pipe operator (|>), backtraces on fatal errors, closures and first-class callables in constant expressions, casts in constant expressions, and array_first()/array_last() (Phoronix). That's a heavier feature list than 8.4's, which leaned on property hooks and asymmetric visibility.

Here's the short version of what matters for a Laravel application, before we go deeper on each:

Feature

What it does

Production impact

Pipe operator `\

`

Passes the left expression as the first argument to the right callable (Zend)

Readability for transform chains; zero runtime cost vs nested calls

Fatal error backtraces

Fatal errors (OOM, timeouts) now include a stack trace

Big. Turns "which request died?" into "which line died?"

array_first() / array_last()

First/last value without touching the internal pointer

Removes a class of reset()/end() footguns

Closures in constant expressions

Static closures and first-class callables in defaults, constants, attributes

Cleaner attribute-driven validation and config

Casts in constant expressions

(int), (string) etc. allowed in const definitions

Minor, but removes awkward workarounds

Notice what's not on the list: there's no single "your app gets 20% faster" feature this cycle. The 8.5 release is about ergonomics and observability, not raw throughput. If you're chasing performance, your time is still better spent on OPcache configuration than on any syntax in this release.

One version-support fact to anchor the rest of this post: as of August 2026, PHP 8.5 is the current stable release, 8.4 is the previous release, and Laravel 13 (current since March 2026) requires PHP 8.3 as its minimum. So every supported Laravel version runs happily on 8.5. There's no framework reason to wait.

How Does the Pipe Operator Work in Real Laravel Code?

The pipe operator takes the expression on its left and passes it as the first argument to the callable on its right (Zend). Each stage must be a callable that accepts one argument, which is why you'll usually see first-class callable syntax (trim(...)) or short closures in a chain (php[architect]). That's the entire semantic. No magic, no autoloading tricks, no runtime dispatch overhead beyond a normal function call.

Collection-style transforms without Collection overhead

Laravel developers already think in pipelines. We reach for collect() or Str::of() even for three-step string transforms, because chained methods read better than nested calls. The pipe operator gives you that reading order on plain values, without allocating a Collection or Stringable object per step:

use Illuminate\Support\Str;

$slug = $request->input('title', '')
    |> trim(...)
    |> Str::squish(...)
    |> Str::slug(...);

Compare the pre-8.5 equivalents. Nested calls read inside-out: Str::slug(Str::squish(trim($title))). The fluent version, Str::of($title)->squish()->slug()->value(), reads fine but allocates intermediate objects. In a hot path that runs thousands of times per request, say normalizing rows in an import, the pipe version has the readability of the fluent API with the cost profile of the nested one.

Is that overhead ever your actual bottleneck? Honestly, almost never. Choose pipes for readability first and treat the allocation savings as a bonus.

Normalizing request data

The other place pipes shine is input normalization, where each step is a small, testable transform:

$phone = $request->input('phone', '')
    |> trim(...)
    |> (static fn (string $v): string => preg_replace('/[^0-9+]/', '', $v))
    |> (static fn (string $v): string => str_starts_with($v, '00')
        ? '+' . substr($v, 2)
        : $v);

Each stage does one thing, in reading order. When a bug report says "phone numbers starting with 00 aren't converting", you know exactly which line to look at. With a single dense preg_replace plus ternary soup, you don't.

Where pipes get ugly

The pipe operator only passes one argument, always in the first position. The moment a function wants your value in the second position, explode() is the classic offender, you're wrapping it in a closure anyway. Chains that are 80% closure wrappers read worse than the code they replaced. Multi-argument stages, conditional branches mid-chain, and anything with side effects belong in a named method, not a pipe. Our rule of thumb: if more than one stage in the chain needs a closure with a body longer than one expression, refactor to a method instead.

Are array_first() and array_last() Worth Caring About?

Yes, more than they look. PHP 8.5 added array_first() and array_last() as part of the same release (Phoronix), and they replace two of the oldest footguns in the language: reset() and end().

The problem with the old functions is that they take their argument by reference and mutate the array's internal pointer. That has two consequences you've probably hit. You can't call them on a function return value without a "notice: only variables should be passed by reference", so you create a throwaway variable. And they return false for an empty array, which is indistinguishable from a stored false.

// Before: temp variable, pointer mutation, false-vs-empty ambiguity
$errors = $validator->errors()->all();
$firstError = reset($errors);

// PHP 8.5: direct, no mutation, null on empty
$firstError = array_first($validator->errors()->all());

array_first() returns the first value or null if the array is empty, and it never touches the internal pointer. In Laravel code you already have Arr::first(), so the practical win is smaller than in framework-free code. But native functions work in constant expressions, in packages that avoid the framework, and without the helper's closure-support overhead. It's also one less place where new team members ask "wait, why is there a reset() here?"

Small feature, real quality-of-life gain. Nobody upgrades for this, but everybody uses it within a week.

How Do Fatal Error Backtraces Change Production Debugging?

This is the sleeper feature of the release, and in our experience it's the strongest single argument for upgrading production servers. PHP 8.5 adds backtraces to fatal errors (Phoronix), controlled by the new fatal_error_backtraces ini setting, which is enabled by default.

Before 8.5, the two most common production killers, memory exhaustion and max execution timeouts, died with a single line:

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted
(tried to allocate 262144 bytes) in
/var/www/app/vendor/laravel/framework/src/Illuminate/Support/Collection.php on line 138

That tells you a Collection method allocated the final straw. It tells you nothing about which controller, job, or command built the collection that ate 512 MB. Teams have historically debugged these by binary-searching log timestamps against access logs. On 8.5, the same failure logs a full stack trace:

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted ...
Stack trace:
#0 /var/www/app/app/Services/ReportBuilder.php(88): Illuminate\Support\Collection->map()
#1 /var/www/app/app/Jobs/GenerateMonthlyReport.php(41): App\Services\ReportBuilder->build()
#2 ...

Now you know it's the monthly report job, and you know it's the map() call on line 88 hydrating too many models at once. What used to be an afternoon of archaeology is now a two-minute read of the FPM error log. Since these traces land in php8.5-fpm's error log, this pairs naturally with log-based alerting: if your monitoring tails FPM logs, your alerts just got dramatically more actionable.

One caveat worth knowing: building a backtrace during memory exhaustion requires a small reserved buffer, and in pathological OOM cases the trace can be truncated. A truncated trace still beats no trace.

What Changed in Constant Expressions?

PHP 8.5 allows closures and first-class callables in constant expressions, and it allows casts there too (Phoronix). "Constant expressions" means the places PHP evaluates at compile time: class constants, default parameter values, property defaults, and attribute arguments.

The practical wins are in defaults and attributes. Before 8.5, a parameter couldn't default to a closure, so you wrote nullable-plus-fallback boilerplate:

// Before 8.5
public function sanitize(string $value, ?Closure $cleaner = null): string
{
    $cleaner ??= static fn (string $v): string => trim($v);

    return $cleaner($value);
}

// PHP 8.5
public function sanitize(
    string $value,
    Closure $cleaner = static fn (string $v): string => trim($v),
): string {
    return $cleaner($value);
}

Attributes gain the most. Validation and mapping attributes can now carry behavior instead of just configuration strings:

final class WebhookPayload
{
    #[EnsureThat(static fn (mixed $v): bool => is_string($v) && $v !== '')]
    public string $signature;
}

Only static closures are allowed (no $this capture, no use imports), which is the right constraint: compile-time values shouldn't depend on runtime state. Casts in constant expressions are a smaller courtesy, so public const int TIMEOUT_MS = (int) 2.5e3; now just works instead of forcing you to precompute the literal.

Will you use this daily? Probably not. Package authors will, though, and you'll feel it in cleaner APIs from the validation and serialization libraries you depend on.

Should You Adopt PHP 8.5 in 2026?

For the runtime itself: yes. Laravel, Symfony, and WordPress are all compatible, and by mid-2026 the ecosystem has had three release cycles to shake out extension issues (adoption guide). The fatal error backtraces and the security-support clock both push in the same direction. Running the current stable release means five more years before your next forced migration.

The syntax is a separate decision, and this is where we'd urge some restraint. The adoption guidance that's emerged in 2026 matches our experience: the pipe operator is worth adopting in greenfield projects where the team agrees on a style up front, and worth holding off on in legacy codebases where reviewers don't read it fluently yet (adoption guide). A codebase where 5% of transforms use pipes and 95% use fluent chains isn't more modern, it's just less consistent. Style consistency beats syntax novelty every time someone new reads your code.

Strengths: Fatal error backtraces improve production debugging immediately with zero code changes. The pipe operator and array_first() remove real friction. Full framework compatibility means no blocker for Laravel 13 apps, and upgrading now resets your security-support window.

Best for: Teams already on PHP 8.4 with a green test suite, greenfield projects that can set pipe-operator conventions from day one, and anyone planning a Laravel 13 upgrade who'd rather do one runtime migration than two.

Considerations: Legacy codebases gain little from new syntax until the whole team reads it fluently. Niche PECL extensions may still lag (more on that below). And if you're on PHP 8.2 or earlier, jumping two-plus versions at once multiplies deprecation risk; step through 8.4 first.

If the runtime answer is yes, the remaining question is purely operational. So let's do the upgrade properly.

The Zero-Downtime PHP-FPM Upgrade Playbook (Ubuntu 24.04)

The entire playbook rests on one architectural decision: install PHP 8.5 alongside 8.4, never on top of it. Ubuntu's ondrej/php PPA packages every PHP version with its own binaries, config tree, FPM service, and socket, specifically so multiple versions coexist. Your cutover then becomes a one-line nginx change, and your rollback is the same line reversed.

Why not upgrade in place? Let's compare honestly.

In-place upgrade

Side-by-side install

Downtime

Seconds to minutes while FPM swaps

Zero (graceful nginx reload)

Rollback

Reinstall 8.4, restore configs

Revert one nginx line, reload

Disk/memory cost

None

~150 MB disk, one mostly idle FPM master

Per-site cutover

No, all sites move at once

Yes, migrate one site at a time

Strengths: In-place is simpler and leaves nothing to clean up. Side-by-side gives zero downtime, per-site granularity, and a sub-minute rollback.

Best for: In-place suits throwaway or single-tenant staging boxes. Side-by-side is the right call for any production server, and it's non-negotiable for servers hosting multiple sites.

Considerations: Side-by-side means two config trees to keep in sync until you retire 8.4, and it's easy to forget that cron jobs and workers use the CLI binary, which cuts over separately from the web tier.

Side-by-side wins for production. Here's the sequence.

Step 1: Install 8.5 next to 8.4

On Ubuntu 24.04 with the ondrej/php PPA (add it first if this server doesn't have it):

sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt install -y php8.5-fpm php8.5-{mysql,redis,mbstring,xml,curl,zip,gd,intl,bcmath}
sudo systemctl enable --now php8.5-fpm

You now have two FPM masters running: php8.4-fpm listening on /run/php/php8.4-fpm.sock and php8.5-fpm on /run/php/php8.5-fpm.sock. Each has its own pool config under /etc/php/8.5/fpm/pool.d/. Copy over any pool tuning you've done for 8.4, pm.max_children, pm.max_requests, memory limits, because the 8.5 packages ship stock defaults. If you haven't tuned pools before, our PHP-FPM tuning guide for Laravel covers the sizing math.

An idle FPM master costs a few megabytes of memory. Running both for weeks is fine.

Step 2: Audit extension parity

The single most common upgrade failure isn't a language change, it's a missing extension. The 8.4 install accumulated extensions over years; the fresh 8.5 install has only what you just listed. Diff them:


bash
diff

Building an MCP Server in Laravel: Let AI Agents Talk to Your App Safely

Deploynix — Sun, 09 Aug 2026 15:06:55 +0000

Picture a support engineer pasting a customer email into Claude and asking, "Why did this customer's last deployment fail?" Six months ago, the answer involved tab-switching between an admin panel, a log viewer, and a database client. Now the agent calls a tool named list-recent-deployments, reads the failed step's output through a second tool, and drafts a reply with the actual error attached. Nobody exported a CSV. Nobody ran a raw SQL query against production. The agent talked to the Laravel app directly, through a narrow, authenticated, audited interface that we designed for it.

That interface is an MCP server. The Model Context Protocol was introduced by Anthropic as an open standard in November 2024, and the interoperability story is the whole point: any MCP-compatible client, whether Claude, Cursor, or GitHub Copilot, can connect to any MCP server (Laravel MCP docs, Laravel's MCP guide). Laravel shipped first-party support through the official laravel/mcp package (Packagist), so you define tools the same way you define controllers, jobs, and policies: as small classes with validation and authorization built in.

Here's the tension, though. An MCP server is an API that a probabilistic system calls on behalf of a human. Agents in 2026 aren't autocomplete anymore; they run for minutes or hours and get delegated whole tasks (The New Stack). An agent with a badly scoped tool will eventually do something you didn't intend, not out of malice, but out of statistics. So this guide treats security as the backbone, not an afterthought. We'll build a working MCP server on Laravel 13 and PHP 8.5, then spend most of our time on the parts that keep it from becoming your most dangerous endpoint.

Key Takeaways - laravel/mcp is the official first-party package; tools are classes with schemas, validation, and authorization (Packagist). - Any MCP client (Claude, Cursor, Copilot) can connect to any MCP server, per the open standard Anthropic released in November 2024. - Treat agents as untrusted callers: Sanctum auth, per-tool policies, rate limits, audit logs, and confirmation gates for anything destructive.

Why Would You Let AI Agents Talk to Your Laravel App at All?

The honest answer: because your team is already using agents, and the alternative is worse. When an agent can't reach your app through a sanctioned interface, people improvise. They paste production data into chat windows. They hand agents database credentials "just for this one query." They screenshot admin panels. An MCP server replaces that improvisation with an interface you control, validate, and log.

We see three use cases that justify the effort, and we've built for all three internally.

Support tooling is the easiest win. A support agent (human or AI) needs read access to a customer's recent activity: orders, deployments, invoices, error events. These are read-only queries with obvious tenant boundaries. An MCP tool that accepts a customer ID, checks authorization, and returns a structured summary saves hours per week and leaks nothing beyond what the caller was already allowed to see.

Internal ops is the second tier. Think "requeue this failed job," "resend this webhook," or "toggle this feature flag for one team." These are write operations, but they're small, reversible, and already exposed in your admin panel. Wrapping them in MCP tools means an on-call engineer can ask an agent to triage an incident at 2 a.m. instead of clicking through five screens half-asleep. In our experience, the audit trail actually improves here, because every tool call is logged with arguments, while admin-panel clicks often aren't.

Customer-facing agent features are the third tier and the highest stakes. If your product exposes an MCP server to customers, their agents can integrate your product into their workflows without you building a bespoke plugin for every client. This is where MCP's client-agnostic design pays off: you build one server, and Claude, Cursor, and Copilot users all get the integration for free. It's also where every security control in this article stops being optional.

What about the counterargument, that a REST API already covers this? [UNIQUE INSIGHT] A REST API is documentation-shaped: a human reads the docs, writes glue code, handles pagination, and ships an integration. An MCP server is decision-shaped: it hands the client a menu of typed, described actions that a model can choose between mid-conversation, with no glue code in between. You'll likely want both, and they'll share the same policies underneath. The difference is who the consumer is and how much ceremony sits between intent and execution.

What Are MCP Tools, Resources, and Prompts?

MCP defines three primitives a server can expose, and picking the right one for each capability matters more than it first appears. Getting this wrong usually means shipping a tool that should have been a resource, which inflates your writable surface for no benefit.

Primitive

Direction

What it's for

Laravel analogy

Tool

Agent calls it with arguments

Actions and parameterized queries: "create X," "list Y for Z"

A controller action with a Form Request

Resource

Agent reads it

Reference material: docs, config, schema descriptions, reports

A read-only route serving a document

Prompt

Agent requests a template

Reusable, server-authored instructions for common workflows

A Blade template for model instructions

Tools are the workhorses. Each tool has a name, a natural-language description, and a typed argument schema. The description is not decoration: it's how the model decides when to call the tool, so write it like you'd write for a sharp junior engineer who skims. Vague descriptions produce misfired calls.

Resources are content the agent can pull into context: your API changelog, a runbook, a schema reference. If a capability takes no arguments and changes nothing, make it a resource, not a tool. Fewer tools means fewer wrong choices for the model and a smaller surface for you to authorize.

Prompts are server-provided templates. If every "triage an incident" conversation should start with the same instructions and the same data-gathering sequence, ship that as a prompt so users don't reinvent it badly. We've found that prompts are the most underused primitive; teams put workflow instructions in a wiki that agents never read, when the server itself could serve them.

One design rule we'd push hard: model your tools around intents, not tables. resend-failed-webhook is a good tool. update-webhook-row is a bad one, because it forces the model to understand your schema and gives it write access far beyond the intent. Narrow tools are easier to authorize, easier to describe, and much harder to misuse.

How Do You Build One with laravel/mcp?

The official package makes this feel like normal Laravel work, which is exactly what you want. Install it and publish the routes file:

composer require laravel/mcp
php artisan vendor:publish --tag=ai-routes

That gives you routes/ai.php, a dedicated routes file for MCP servers, deliberately separate from web.php and api.php. Then generate a server and a first tool:

php artisan make:mcp-server OpsServer
php artisan make:mcp-tool ListRecentDeployments

Defining the server

A server class declares its identity, its instructions to connecting clients, and its capabilities. Instructions matter: they're the system-level guidance every client receives, so use them to state what the server is for and what it will refuse to do.

php

Laravel Reverb's New Database Driver: Real-Time WebSockets Without Redis

Deploynix — Mon, 03 Aug 2026 07:38:01 +0000

Until this year, every Laravel team that wanted to scale Reverb past a single process ended up having the same conversation. Someone would say "we just need a second Reverb worker," and someone else would answer "then we need Redis." Not because the app used Redis for anything else, but because Reverb's scaling mode only spoke Redis pub/sub. For a lot of small and mid-sized apps, that meant installing, securing, and monitoring an entire extra service to pass a few hundred messages per minute between two PHP processes.

Laravel 13, released on March 17, 2026, quietly removed that requirement. The release added a database driver to Reverb's scaling layer, so real-time features can now run across multiple processes without a Redis dependency, which meaningfully simplifies infrastructure for smaller deployments (Laravel News, PHP Everyday). Your MySQL or PostgreSQL server, the one you already back up and monitor, becomes the message bus.

That raises a genuinely interesting question: when should you use it? The database driver isn't a free lunch, and Redis (or Valkey) still wins in specific scenarios. We run a lot of Reverb in production for our own platform and for customers, and in this post we'll walk through how Reverb scaling actually works, what the new driver changes, an honest decision framework for choosing between the three options, and the full production setup either way. If you're newer to this topic, our WebSockets primer for Laravel developers covers the fundamentals before you get into scaling questions.

How Reverb Scaling Works Under the Hood

To understand why the database driver matters, you need to understand what problem the scaling layer solves in the first place. Reverb is a long-running PHP process built on an event loop. When a browser opens a WebSocket connection, that connection lives inside one specific Reverb process. The process holds it in memory, tracks its channel subscriptions, and answers its ping frames.

When your Laravel app broadcasts an event, say OrderShipped, it doesn't talk to the browser directly. It sends an HTTP request to Reverb's Pusher-compatible API, and Reverb then pushes the payload down every open connection subscribed to that channel. With a single Reverb process, this is beautifully simple. One process knows about every connection, so every subscriber gets the message. No coordination required, no backplane, no extra config.

The moment you run two Reverb processes, that guarantee breaks. Picture process A on port 8080 and process B on port 8081, with Nginx load balancing between them. Alice's browser connects to process A. Bob's browser connects to process B. Your app broadcasts OrderShipped, and the HTTP request happens to land on process A. Alice gets the event instantly. Bob gets nothing, because process B never heard about it. His connection is sitting in a different process's memory, invisible to A.

This is the fan-out problem, and it's why Reverb has a scaling mode at all. When you set REVERB_SCALING_ENABLED=true, each Reverb process stops assuming it knows about every subscriber. Instead, every broadcast is also published to a shared backplane, and every process subscribes to that backplane. Process A receives the event, delivers it to its local connections, and publishes it to the bus. Process B picks it up from the bus and delivers it to Bob. Same story across multiple servers: the backplane is what lets a Reverb process on server one reach a browser connected to server two.

Historically, that backplane had exactly one implementation: Redis pub/sub. It's an excellent fit technically, since Redis pushes messages to subscribers with sub-millisecond latency and handles enormous throughput. But it made Redis a hard dependency the moment you needed more than one process. Even a modest two-process setup for redundancy dragged a new service into your stack. That's the assumption Laravel 13 finally relaxed.

What Does the Laravel 13 Database Driver Actually Change?

The change itself is easy to describe: Reverb's scaling layer is now driver-based, and database joins redis as a first-party option (Laravel News). Instead of publishing inter-process messages through Redis pub/sub, each Reverb process writes broadcast payloads to a table in your existing database and polls that table on a short interval for messages published by its siblings. Each process keeps a cursor of the last message it applied, delivers new rows to its local connections, and old rows get pruned automatically so the table stays small.

Mechanically it resembles how Laravel's database queue driver relates to the Redis queue driver. Same contract, different transport, different performance envelope. The write path adds one insert per broadcast, and the read path adds a cheap indexed query per polling tick per process. For an app broadcasting dozens or even hundreds of events per minute, that load is a rounding error on any reasonably sized MySQL or PostgreSQL instance.

What you gain is operational subtraction. One less service to install and patch. One less port to firewall. One less thing to monitor at 3 a.m., and one less line item on your smallest client's VPS. Your database is already backed up, already monitored, and already part of your mental model. The PHP Everyday upgrade guide calls this out specifically as a simplification aimed at smaller deployments that want multi-process Reverb without growing their stack (PHP Everyday).

What you trade away is push semantics. Redis pub/sub delivers messages to subscribers the instant they're published. A polling driver, by definition, delivers them on the next tick. In practice the interval is a fraction of a second, so a chat message crossing processes arrives tens of milliseconds later than it would over Redis. Users won't notice on a notification bell or a dashboard widget. A multiplayer cursor overlay is a different story, and we'll get to that in the decision framework.

One thing that doesn't change at all: your application code. Broadcasting events, channel authorization, Echo on the frontend, presence channels, whispers, all of it is identical. The scaling driver is invisible above the transport layer. If you're planning the jump to Laravel 13 to get this feature, our guide to upgrading to Laravel 13 in production with zero downtime walks through the full process.

Which Scaling Backplane Should You Choose?

Here's the framework we use when customers ask. It comes down to three honest options, and the right answer depends on your connection count, your latency sensitivity, and how much infrastructure you want to own.

Option 1: A Single Reverb Process, No Backplane at All

This option gets skipped in most scaling discussions, which is a shame, because it's the correct choice for the majority of Laravel apps. A single Reverb process on a modern VPS comfortably handles thousands of concurrent connections. If your app serves a few hundred simultaneous users, one process has enormous headroom, and with no second process there's no fan-out problem to solve. Leave REVERB_SCALING_ENABLED unset and move on.

Strengths: Zero coordination overhead, zero extra latency, zero additional services. The simplest possible thing that works, and simple things fail less.

Best for: Apps with up to a few thousand concurrent connections, internal tools, dashboards, SaaS products in their first years, and anyone who hasn't yet measured a reason to scale.

Considerations: One process is one failure domain. If it crashes, everyone disconnects until Supervisor restarts it (Echo reconnects automatically, more on that below). You're also capped by a single CPU core for WebSocket work, so this stops being viable at genuinely large connection counts.

Option 2: The Database Driver

This is the new middle path. You run two or more Reverb processes, on one server or several, and coordinate them through the database you already operate. It's the option Laravel 13 built for teams that outgrew a single process but never wanted the Redis conversation.

Strengths: Horizontal scaling and process redundancy with no new services. Uses infrastructure you already back up, secure, and monitor. Trivial to set up: enable scaling, set the driver, run the migration.

Best for: Moderate scale, roughly the range where you want two to a handful of Reverb processes for redundancy or multi-server topologies, with broadcast volumes in the hundreds of messages per minute. Also ideal for agencies running many small client apps where every extra service multiplies across the fleet.

Considerations: Cross-process delivery latency is bounded by the polling interval, so it's tens of milliseconds slower than pub/sub. Every broadcast adds database writes, and every process adds polling reads, so very high message volumes will make your database work for a living. High-frequency events like live cursors or typing indicators across processes will feel the lag.

Option 3: Redis or Valkey Pub/Sub

The original backplane, and still the performance king. Messages move between processes with sub-millisecond latency, and a modest Redis or Valkey instance shrugs off tens of thousands of messages per second.

Strengths: Lowest possible cross-process latency, effectively unlimited fan-out throughput for anything a Laravel app will realistically produce, and battle-tested behavior at scale.

Best for: High fan-out workloads: busy chat products, live auctions, collaborative editing, real-time games, anything broadcasting high-frequency events to large audiences across multiple servers. Also the natural pick if Redis or Valkey is already in your stack for cache and queues, since the marginal cost is zero.

Considerations: It's another service with its own memory limits, persistence settings, and security posture. If it's only there for Reverb, you've added operational surface for one feature. On licensing and compatibility, Valkey is a drop-in replacement and our default recommendation; we compared the two in Valkey vs Redis for Laravel caching and queues.

The Three Options Side by Side

Single process

Database driver

Redis / Valkey

Extra services required

None

None (reuses your DB)

Redis or Valkey instance

Cross-process delivery latency

Not applicable

Polling interval (tens of ms)

Sub-millisecond push

Fan-out ceiling

One process's capacity

Moderate message volume

Very high

Horizontal scaling

Yes

Process redundancy

Yes

Operational overhead

Lowest

Low

Moderate

Best fit

Most apps, honestly

Moderate scale, simple ops

High-frequency, high fan-out

A reasonable growth path: start with a single process, move to the database driver when you need redundancy or a second server, and reach for Valkey only when message frequency or audience size demands it. Each step is a config change, not a rewrite.

The Full Production Setup

Whichever backplane you pick, the surrounding production setup is identical, and this is where most real-world Reverb problems actually live. We've debugged more broken WebSocket deployments caused by Nginx timeouts and file descriptor limits than by anything in Reverb itself. Here's the complete checklist we apply, assuming Ubuntu 24.04, PHP 8.5, and Nginx, the same baseline as our production-ready Laravel stack guide.

Environment Configuration

Your .env defines the Reverb app credentials, the local bind address, and the public hostname the browser connects to. For a database-driver setup:

BROADCAST_CONNECTION=reverb

REVERB_APP_ID=482913
REVERB_APP_KEY=your-app-key
REVERB_APP_SECRET=your-app-secret

REVERB_HOST=ws.example.com
REVERB_PORT=443
REVERB_SCHEME=https

REVERB_SERVER_HOST=127.0.0.1
REVERB_SERVER_PORT=8080

REVERB_SCALING_ENABLED=true
REVERB_SCALING_DRIVER=database

For Redis or Valkey, swap the last two lines:

REVERB_SCALING_ENABLED=true
REVERB_SCALING_DRIVER=redis
REDIS_HOST=10.0.0.4
REDIS_PORT=6379

Two details trip people up here. First, REVERB_HOST and REVERB_PORT are what the browser sees (your public TLS endpoint on 443), while REVERB_SERVER_HOST and REVERB_SERVER_PORT are where the Reverb process binds locally. Reverb itself should listen on 127.0.0.1 and let Nginx terminate TLS in front of it. Second, when using the database driver, run your migrations after upgrading; the scaling table ships with the framework's Reverb migrations, and forgetting it produces confusing "works locally, silent in staging" behavior.

Supervisor: Keeping the Process Alive

Reverb is a long-running process, and long-running processes need a supervisor. Here's the stanza we generate for a two-process setup:

[program:reverb]
command=php /home/deploynix/example.com/current/artisan reverb:start --host=127.0.0.1 --port=80%(process_num)02d --no-interaction
process_name=%(program_name)s_%(process_num)02d
numprocs=2
autostart=true
autorestart=true
user=deploynix
stopasgroup=true
killasgroup=true
stopwaitsecs=15
stdout_logfile=/home/deploynix/.logs/reverb.log
redirect_stderr=true

The stopasgroup=true and killasgroup=true lines matter more than they look. Without them, Supervisor signals only the parent process on restart, and any children keep running as orphans holding the port. That's the classic "address already in use" loop after a deploy. With numprocs=2, Supervisor runs reverb_00 on port 8000 and reverb_01 on port 8001, and Nginx can balance across both. If you're running a single process, drop numprocs and hardcode the port.

Nginx: TLS Termination and the WebSocket Upgrade Block

WebSocket connections start life as an HTTP request with an Upgrade header, and Nginx will not forward that handshake unless you tell it to. This config handles TLS, the upgrade, and load balancing across two local Reverb processes:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream reverb {
    server 127.0.0.1:8000;
    server 127.0.0.1:8001;
}

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

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

    location / {
        proxy_pass http://reverb;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $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 300s;
        proxy_send_timeout 300s;
    }
}

Three lines do the WebSocket-specific work. proxy_http_version 1.1 is required because the upgrade mechanism doesn't exist in HTTP/1.0, which is Nginx's default for upstream connections. The Upgrade and Connection headers are hop-by-hop, so Nginx strips them unless you explicitly re-add them. The map block is a small refinement worth keeping: it sends Connection: upgrade for WebSocket handshakes but Connection: close for plain HTTP requests to the same endpoint, which keeps Reverb's Pusher-protocol HTTP API working through the same server block.

The proxy_read_timeout Gotcha

This one deserves its own section because it produces the most confusing symptom in WebSocket operations: connections that work perfectly, then die after exactly sixty seconds of quiet. Nginx's proxy_read_timeout defaults to 60 seconds, and it measures the time between successive reads from the upstream. A WebSocket that hasn't sent anything for a minute looks, to Nginx, like a dead upstream, and Nginx closes it.

Reverb's protocol-level ping frames usually keep traffic flowing inside that window, so many teams never hit this. But "usually" isn't a plan. A paused laptop, a delayed ping, or a saturated event loop is enough to cross the threshold, and then your users see mysterious reconnect churn that never reproduces in testing. Set proxy_read_timeout (and proxy_send_timeout) well above the ping interval; we use 300 seconds as a sane default. The client reconnects gracefully either way, but there's no reason to burn reconnects on a timeout you control.

File Descriptor Limits

Every WebSocket connection is an open file descriptor, and Linux defaults assume you won't need many. A stock Ubuntu 24.04 process gets a soft limit of 1,024 descriptors, which means your "handles thousands of connections" Reverb process actually caps out around a thousand, then starts refusing connections with EMFILE errors.

Raise the limit in three places so it survives every path a process can start from. In /etc/security/limits.conf:

deploynix soft nofile 65535
deploynix hard nofile 65535

In the Supervisor main config, since Supervisor sets its own limit and children inherit it:

[supervisord]
minfds=65535

And check the kernel ceiling with sysctl fs.file-max, though on modern systems it's rarely the constraint. Remember Nginx holds a descriptor per proxied connection too, so bump worker_rlimit_nofile and worker_connections in nginx.conf to match. We covered the full Reverb hardening pass, including these limits, in our earlier deep-dive on running Reverb in production.

How Do You Monitor Reverb in Production?

The first number to watch is concurrent connections, because it's the number that predicts every other problem: file descriptor exhaustion, memory pressure, and the moment you need a second process. Laravel Pulse ships first-party Reverb cards that chart connection counts and message throughput per process, and for most teams that's the right starting point. It answers "how close are we to needing option two or three" with an actual graph instead of a guess.

When you want ground truth from the server itself, the kernel already knows. Count established connections on Reverb's port:

ss -tn state established '( sport = :8000 )' | wc -l

Or count the process's open descriptors directly, which catches the EMFILE cliff before you fall off it:

ls /proc/$(pgrep -f reverb:start | head -1)/fd | wc -l

Alert on trends, not absolutes. A connection count that doubles week over week is your early warning to plan the backplane move while it's still a calm config change. If you're on the database driver, add two database-side checks: the size of the scaling table (pruning should keep it small, so sustained growth means something's wrong) and write latency on the broadcast path. If broadcasts start queueing behind slow inserts, your message volume has outgrown polling, and that's your signal that the Valkey conversation has finally earned its place on the agenda.

Also watch memory per process. Reverb's event loop holds per-connection state, so memory grows roughly linearly with connections. A process that grows without connection growth is leaking, and autorestart=true in Supervisor is your safety net, not your fix.

What Happens During Deploys and Restarts?

Here's the part that surprises teams coming from stateless HTTP: a WebSocket server can't do a truly zero-downtime handoff of its connections. Each connection lives in a specific process's memory, and when that process exits, the connection goes with it. A deploy that restarts Reverb disconnects every client, full stop. The good news is that the ecosystem is built around this reality, and handled properly, users never notice.

After a deploy, signal the running servers with:

php artisan reverb:restart

This publishes a restart instruction over your scaling backplane (the database or Redis, whichever you've configured), and each Reverb process finishes its in-flight work, closes its connections cleanly, and exits. Supervisor sees the exit and immediately starts fresh processes running your new code. The stopwaitsecs=15 in the stanza above gives the graceful path room to complete before Supervisor escalates to SIGKILL.

On the client side, Echo's underlying Pusher protocol client treats disconnection as normal weather. It reconnects automatically with exponential backoff, re-subscribes to every channel, re-authorizes private and presence channels, and rejoins presence member lists. The typical gap is one to a few seconds. Your job is to make that gap harmless: don't treat the WebSocket as a source of truth. Fetch current state on page load and on reconnect, and use broadcasts as invalidation hints rather than the only copy of the data. Events broadcast during the gap are not replayed, so any UI that must not miss updates should re-sync when Echo fires its reconnected state change.

One more note for multi-process setups: reverb:restart is another reason the backplane matters. With scaling enabled, one command gracefully cycles every process on every server. Without it, you're restarting processes one by one and hoping you didn't miss any.

Reverb on Deploynix: The Redis Question Is Already Answered

We'll be direct about where our platform fits, because this post exists partly due to how often the "do I need Redis for Reverb?" question lands in our support inbox. On Deploynix, an app server ships with Valkey installed and configured out of the box, alongside Nginx, PHP-FPM, MySQL, and Supervisor. So the decision framework above gets simpler in practice: the Redis-class backplane is already there, already secured, already maintained. Whether you point Reverb's scaling driver at your database or at the local Valkey instance is purely a latency-versus-load decision, not an infrastructure project. That's true on every provider we support: DigitalOcean, Vultr, Linode, Hetzner, AWS, or any custom VPS.

Running the process itself is a daemons job. In the server's Daemons UI, add php artisan reverb:start --host=127.0.0.1 --port=8080 with your app's directory, set the process count, and pick the stop signal. Under the hood we write a Supervisor program with the same stopasgroup and killasgroup safety rails shown earlier, and the daemon survives reboots and crashes without you touching a config file over SSH. Free SSL via certbot covers the ws. subdomain, and server monitoring with alerts gives you the early warning on connection and memory trends we described above.

When you do outgrow a single box, the pieces are already shaped for it. A dedicated cache server type runs Valkey with TLS enabled for exactly this backplane role, and the load balancer server type forwards WebSocket upgrade headers correctly out of the box, so multi-server Reverb doesn't require hand-editing proxy configs. If you're deciding how to split things up, our breakdown of seven server types and when to use each maps these roles onto real application shapes.

FAQ

Does the database scaling driver work with MySQL, PostgreSQL, and SQLite?

It targets your default database connection, so MySQL and PostgreSQL are both fully supported in production. SQLite technically works and is handy for local multi-process testing, but its single-writer model makes it a poor backplane under real broadcast volume. Use whatever production database you already run; that's the entire point of the driver.

Do I still need Redis or Valkey for queues and cache if Reverb uses the database driver?

No, the choices are independent. Reverb's scaling driver, your queue driver, and your cache driver are three separate settings. Plenty of Laravel 13 apps now run entirely Redis-free: database queues, database cache, and database-backed Reverb scaling. That said, if Valkey is already in your stack for queues, pointing Reverb at it costs nothing.

How many concurrent connections can one Reverb process handle?

There's no fixed number, since payload size and message frequency matter as much as connection count. As a rough planning figure, a single process on a 2 vCPU server with proper file descriptor limits comfortably holds thousands of mostly-idle connections. Measure with Pulse under your real traffic before assuming you need a backplane at all.

Will switching scaling drivers require any frontend changes?

None. Echo, channel authorization, presence channels, and your broadcast events are all unchanged, because the scaling driver operates below the Pusher protocol layer. Moving from single-process to database to Valkey is an .env change plus a process restart. Clients disconnect briefly during the restart and Echo reconnects and re-subscribes automatically.

What happens to messages broadcast while a client is reconnecting?

They're gone, on every driver. Reverb delivers to currently connected clients and doesn't replay missed events. Design for it: fetch authoritative state on load and on Echo's reconnect event, and treat broadcasts as prompts to update, not as the system of record. This matters most during deploys, when every client reconnects at once.

Where to Go Next

The database driver doesn't make Redis obsolete; it makes Redis optional, which is a more useful kind of progress. Single process for most apps, database driver when you need redundancy without new services, Valkey when fan-out and latency genuinely demand it. Each step up is a config change you can make the week you need it, not an architecture decision you have to get right on day one.

If you want to put this into practice, the concrete next step is a staging run: provision an app server, add reverb:start as a daemon, flip REVERB_SCALING_DRIVER=database with two processes, and watch the connection graphs while you send real traffic through it. An afternoon of that will tell you more about your app's real-time profile than any decision table, ours included.

Laravel 13's First-Party JSON:API Support: Standards-Compliant APIs Without Packages

Deploynix — Sun, 02 Aug 2026 21:56:36 +0000

Every Laravel team that has shipped a standards-compliant API knows the tax: a third-party package like laravel-json-api/laravel, its config files, a custom schema directory, and hundreds of lines of glue code holding the response format together. Laravel 13 moves that entire layer into the framework, behind resource classes that look almost exactly like the Eloquent API Resources every Laravel developer already knows. For teams running those packages today, the migration is mostly deletion — though as with any format swap consumed by mobile clients, you'll want contract tests proving the output matches before anything ships.

That's the practical story behind one of Laravel 13's headline features. The release, which shipped on March 17, 2026, requires PHP 8.3 or higher and introduces no breaking changes to application code (Laravel News). Tucked in alongside the usual quality-of-life improvements is first-party JSON:API support: new resource classes that handle response serialization, relationship inclusion, sparse fieldsets, links, and compliant response headers automatically (PHP Everyday). Before this, standards-compliant APIs in Laravel meant third-party packages or a lot of hand-rolled convention documents that every new hire had to absorb.

One caveat before the code: the samples below reflect the API surface as described in release coverage and our early usage. Exact class and method names can shift between minor releases, so treat them as the shape of the feature and confirm against the official docs for your installed version.

We provision and deploy a lot of Laravel APIs at Deploynix, so we've spent real time with the new JSON:API layer since the release. This post covers what the specification buys you, how the new resource classes compare to classic Eloquent API Resources, how to handle includes and sparse fieldsets without wrecking your query count, and what changes at the server level when you take a compliant API to production.

Why Does JSON:API Compliance Matter for a Laravel API?

JSON:API is a specification for building HTTP APIs in JSON, maintained at jsonapi.org. It defines the shape of every response your API returns: how resources are structured, how relationships are expressed, how errors are formatted, how clients request related data, and how pagination links are exposed. In other words, it answers all the questions your team currently answers in a Notion doc titled "API Conventions" that nobody has updated since 2024.

That sounds bureaucratic until you've maintained an API consumed by more than one client. Every unspecified decision becomes a negotiation. Should errors be {"error": "..."} or {"errors": [...]}? Are timestamps ISO 8601 or Unix epochs? Does the mobile team get a slimmed-down payload, or do they download the full resource and throw most of it away over a cellular connection? Multiply those debates across five endpoints and three client teams and you've burned a sprint on formatting.

Compliance pays off in three concrete ways. First, client tooling: because the document structure is standardized, generic JSON:API client libraries exist for TypeScript, Swift, Kotlin, and most other client-side ecosystems, so frontend teams deserialize your responses without writing bespoke mapping code. Second, standardized errors: the spec's errors array with status, title, detail, and source.pointer members means validation failures render identically everywhere, and client error handling gets written once. Third, sparse fieldsets: clients ask for exactly the attributes they need, which trims payloads meaningfully for list endpoints on mobile networks.

What a compliant response actually looks like

Here's a minimal JSON:API document for a single article with its author included:

{
  "data": {
    "type": "articles",
    "id": "42",
    "attributes": {
      "title": "Zero-downtime deploys, explained",
      "published_at": "2026-07-14T09:30:00+00:00"
    },
    "relationships": {
      "author": {
        "data": { "type": "users", "id": "7" }
      }
    },
    "links": {
      "self": "https://api.example.com/v1/articles/42"
    }
  },
  "included": [
    {
      "type": "users",
      "id": "7",
      "attributes": { "name": "Rana Farouk" }
    }
  ]
}

Every resource carries a type and a string id. Relationships are expressed as linkage objects rather than nested blobs, and related resources travel in a top-level included array so each one appears exactly once, no matter how many resources reference it. Responses are served with the application/vnd.api+json media type. None of this is hard to produce by hand. It's just tedious, and tedious formats drift. A framework-level implementation is what keeps them from drifting.

What Ships in Laravel 13 for JSON:API?

Laravel 13's contribution is a set of resource classes that sit next to the classic JsonResource family. Extend the JSON:API base class instead of the classic one and the framework takes over the spec's mechanical obligations: it wraps your data in the correct document structure, resolves include query parameters into the included array, applies fields[type] sparse fieldsets, generates self and pagination links, and sets the application/vnd.api+json content type on the way out (PHP Everyday).

Because Laravel 13 has no application-code breaking changes (Laravel News), your existing classic resources keep working untouched. The JSON:API classes are additive. That matters for adoption: you can upgrade the framework first, then move endpoints to the new resources one route group at a time. If you haven't done the framework upgrade yet, we walked through the mechanics in upgrading to Laravel 13 in production with zero downtime, and the short version is that this is the calmest major upgrade since Laravel 10.

The new resource classes at a glance

A JSON:API resource looks like a classic resource that's been split into intent-revealing methods. Instead of one toArray() returning everything, you declare attributes, relationships, and links separately, and the framework assembles the document:

php