DEV Community: Deploynix

Laravel 13 Native Attributes: Slimmer Models and a Cleaner Codebase

Deploynix — Wed, 12 Aug 2026 08:03:09 +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.

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

You Don't Need Kubernetes for Your Laravel App

Deploynix — Thu, 16 Jul 2026 08:17:32 +0000

In January 2026, another "we moved off Kubernetes" post hit the front page of Hacker News. The details were familiar: a team of eight engineers spending roughly 60 hours per week maintaining their Kubernetes setup before finally replacing it with Docker Compose on plain servers. Sixty hours. That's one and a half full-time engineers doing nothing but keeping the orchestrator happy, for a product that could run on three machines.

The comments followed the usual script. Half the thread said "you were doing it wrong." The other half said "we did the same thing and got our weekends back." Both halves are right, and that's the interesting part.

This post makes a specific claim: if you're running a Laravel application, you almost certainly don't need Kubernetes, and the reasons are stronger for Laravel than for most stacks. I'll be fair about what Kubernetes actually solves, honest about what it costs, and specific about the boring architecture that covers 95% of Laravel apps in production. And I'll tell you when you genuinely do need k8s, because some readers do.

The pattern keeps repeating

The "we left Kubernetes" essay is a genre now, and it sits inside a bigger trend. A Barclays CIO survey found that 86% of CIOs plan to move some workloads back from the public cloud, and we've unpacked the whole repatriation trend separately.

Repatriation and de-Kubernetesing aren't the same thing, but they share a root cause. Teams adopted complexity designed for a scale they never reached, paid the tax for years, and eventually did the math.

Here's what strikes me about the HN thread and every post like it: the teams involved aren't incompetent. They're usually good engineers who adopted Kubernetes for defensible reasons. Résumés, hiring pipelines, "we might need to scale," a consultant's recommendation, or a genuine belief that this is just how modern infrastructure works. The problem isn't the engineers. The problem is a mismatch between the tool and the workload.

So let's define the workload Kubernetes was built for, and then look honestly at whether your Laravel app resembles it.

What Kubernetes actually solves

It's easy to write a smug takedown of Kubernetes. It's more useful to be precise about what it's genuinely good at, because that precision is exactly what tells you whether you need it.

Bin-packing many heterogeneous services. If you run 40 different services with wildly different resource profiles, some CPU-hungry, some memory-hungry, some spiky, Kubernetes will pack them onto a fleet of nodes far more efficiently than a human assigning services to servers in a spreadsheet. At that scale, the scheduler pays for itself in hardware savings alone.

Org-scale multi-team platforms. When 15 teams each ship their own services, you need namespaces, resource quotas, RBAC, admission controllers, and a standard deploy interface so teams don't step on each other. Kubernetes is the industry's answer to "how do 200 engineers share a compute platform without a meeting for every deploy." That's a real problem, and k8s solves it well.

True elastic scaling. If your traffic genuinely swings 10x within minutes, ticketing on-sales, viral consumer apps, ad-driven spikes, then horizontal pod autoscaling plus cluster autoscaling can absorb it without a human touching anything. Provisioning a new VPS by hand doesn't compete with that.

Self-healing across nodes. A node dies at 3 a.m., and the workloads on it get rescheduled elsewhere before your monitoring even pages you. If you run enough machines that node failure is a weekly event rather than a yearly one, this matters a lot.

These are real capabilities. Kubernetes won the orchestration war because it does these four things better than anything else. Now, the uncomfortable question.

Does your Laravel app have any of these problems?

Walk through the list again with a typical Laravel application in mind.

Heterogeneous services to bin-pack? No. You have one codebase. Your "services" are the same application in different modes: PHP-FPM serving web requests, Horizon running queue workers, the scheduler firing cron entries, maybe Reverb for WebSockets. They share the same code, the same vendor directory, the same deploy artifact. There's nothing to bin-pack. A scheduler optimizing placement across a heterogeneous fleet has no work to do when the fleet is three identical app servers.

Multi-team platform needs? Almost certainly not. Most Laravel teams are 1 to 10 developers shipping one application. You don't need namespaces and RBAC to stop teams colliding when there's one team. The coordination problem Kubernetes solves at the org level simply doesn't exist for you.

Elastic 10x traffic swings? Be honest about your traffic graph. Most Laravel apps, SaaS products, internal tools, e-commerce, client platforms, have daily and weekly rhythms you can predict a month out. Your Tuesday looks like last Tuesday. When growth comes, it comes over weeks, which is plenty of time to resize a server or add one. In our experience, teams that think they need autoscaling usually need a correctly sized server and a queue.

Node failure at fleet scale? With 2 or 3 servers, hardware failure is a rare event, and a load balancer health check plus a spare app server handles it. You don't need a control plane rescheduling pods across a cluster; you need the LB to stop sending traffic to a dead box, which Nginx and every cloud load balancer has done since before Kubernetes existed.

There's a deeper point here about Laravel specifically. The framework's entire production story was designed for boring servers. PHP-FPM's process model is its own worker pool manager. Horizon supervises, balances, and auto-scales queue workers within a machine, with a dashboard, out of the box. The scheduler collapses all your cron jobs into a single crontab entry. Octane exists for when you want to squeeze more requests out of the same hardware. Laravel already ships the 20% of orchestration you actually need, at the application layer, where you can debug it with dd() instead of kubectl describe.

Kubernetes solves problems Laravel apps don't have, using abstractions Laravel already provides simpler versions of.

What Kubernetes costs you

The costs are the half of the equation that adoption decisions consistently underweight. They come in four flavors.

The stack tax

Kubernetes is never just Kubernetes. To run a production Laravel app on it you'll assemble, at minimum: Helm charts or Kustomize overlays for templating, an ingress controller, cert-manager for TLS, an image registry and build pipeline, a secrets story (sealed-secrets, external-secrets, or a vault), and an observability stack because your logs are now scattered across ephemeral pods. Each piece has versions, upgrade cycles, breaking changes, and its own GitHub issues page you'll come to know well.

Compare the artifact counts. A Laravel deploy on a plain server is an Nginx vhost, a Supervisor config, and a crontab line. The same app on Kubernetes means a deployment, service, ingress, HPA, ConfigMap, and secret manifest per component, plus the chart plumbing that templates them. Every one of those files is code you maintain and can misconfigure.

The money

Managed control planes bill you for the privilege of the abstraction, and the worker nodes still cost the same as the VPSes you'd have used anyway. Meanwhile the boring option keeps getting cheaper: a 4 GB Hetzner CPX-class server runs about €7.99/month, versus $24/month for the equivalent DigitalOcean droplet, and Hetzner egress is around €1.19/TB against $10/TB at DO and roughly $90/TB at AWS. A three-server Laravel setup can cost less per month than the observability add-ons on a typical cluster.

The hiring bar

Once Kubernetes is load-bearing, every infrastructure hire needs to know it, or you need to train them. You've raised the bar for a role that used to be "comfortable with Linux and Nginx." The HN team's 60 hours per week is the extreme case, but even a well-run small cluster quietly consumes a day or two of engineering time per week in upgrades, chart bumps, certificate mysteries, and CVE responses. That time comes directly out of product work.

The debugging tax

This one hurts the most at 2 a.m. On a plain server, a misbehaving Laravel app is a tail -f on the log, a supervisorctl status, maybe an strace if things get weird. On Kubernetes, the same investigation traverses ingress, service, endpoint, pod, container runtime, and overlay network before you reach your code. Each layer is a place the problem can hide and a place your mental model can be wrong. Abstraction layers are cheap on the whiteboard and expensive in an incident.

The boring architecture that covers 95% of Laravel apps

What does a typical Laravel app actually need? Three stages, and none of them involve YAML.

Stage 1: one good VPS

One server running Nginx, PHP-FPM, Horizon, MySQL, and Valkey. That's the whole diagram. A 4 vCPU / 8 GB machine handles more traffic than most developers expect; a well-tuned single server comfortably serves the workloads of the vast majority of production Laravel apps.

The moving parts are almost embarrassingly simple. Horizon runs under Supervisor:

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

The scheduler is one crontab line:

* * * * * cd /var/www/app/current && php artisan schedule:run >> /dev/null 2>&1

That's your orchestration layer. Supervisor restarts Horizon if it dies. Cron fires the scheduler. Nginx and PHP-FPM have been serving PHP reliably since before containers were a product category.

Stage 2: split the database

When MySQL and PHP-FPM start competing for memory, move the database to its own server and point DB_HOST at its private IP. Two servers, one firewall rule, done. This single move buys most apps years of headroom, and I've written about the decision criteria in detail in Building a Multi-Server Laravel Architecture.

Stage 3: multiple app servers behind a load balancer

When one app server isn't enough, add identical app servers behind a load balancer, keep sessions and cache in Valkey, move user uploads to S3-compatible storage, and dedicate one server to Horizon and the scheduler so jobs and cron entries run exactly once (or chain ->onOneServer() onto scheduled tasks if the scheduler runs on every box). Three to five servers on this pattern will carry you a very long way; the full progression is mapped out in Scaling Laravel from 1 to 100,000 Users.

Notice what happened: you scaled from one server to a small fleet and never once needed a control plane, a service mesh, or a Helm chart. Each stage was an afternoon of work, and every piece is debuggable with tools you already know.

Every Kubernetes selling point, translated

The strongest argument for Kubernetes is a list of features that sound essential. Here's the same list next to what the boring stack has been doing for years.

Kubernetes gives you

The boring equivalent

Notes

Rolling deployments

Atomic symlink deploys

New release built alongside the old one, symlink swap, instant rollback. See The Anatomy of a Zero-Downtime Deploy

Liveness probes + pod restarts

Supervisor/systemd autorestart + monitoring alerts

Supervisor restarts a dead Horizon in seconds; alerts tell you it happened

Secrets objects

.env outside the web root, plus Laravel's encrypted env files

Simpler threat model, and no etcd to secure

Horizontal pod autoscaling

Add a VPS behind the load balancer

Takes minutes with predictable traffic; you'll see growth coming weeks out

Service discovery + DNS

Private IPs in your .env

You have three servers. You know their addresses

Ingress + cert-manager

Nginx + Let's Encrypt

One vhost file and a certbot renewal timer

ConfigMaps

Config files, deployed with your code

They're already versioned in Git

The pattern in every row is the same: Kubernetes generalizes a problem to N services across M nodes, and pays for that generality in complexity. When N is 1 and M is 3, the specific solution wins on every axis that matters, including reliability, because there's so much less to break.

Rolling deploys deserve one more sentence, since they're the feature people cite most. The releases-plus-symlink pattern gives you zero-downtime deploys and one-command rollbacks with ln -sfn. It's not a lesser version of what Kubernetes does. For a single application, it's the same guarantee with two orders of magnitude less machinery.

When you genuinely do need Kubernetes

If everything above described your situation, you can skip this section. But some readers are shaking their heads, and some of them are right to. Kubernetes earns its keep when:

You run dozens of genuinely distinct services. Not one Laravel app in three modes, but 30+ separately deployed services in multiple languages with different resource profiles. Now bin-packing and a uniform deploy interface pay real dividends.
You have a platform engineering team. If multiple product teams ship independently and someone's full-time job is the internal platform, Kubernetes is a reasonable substrate. The 60 hours per week stops being overhead and becomes the job description.
Your traffic is truly unpredictable at 10x scale. If a tweet or a TV spot can multiply your load in minutes and you can't eat the cost of permanent over-provisioning, cluster autoscaling solves a problem the boring stack handles awkwardly.
You already have deep k8s expertise in-house. Familiarity changes the math. A team that has run clusters for years pays a fraction of the learning-curve tax, and consistency with existing infrastructure has value.

If two or more of those apply, use Kubernetes with a clear conscience. The point of this essay isn't that k8s is bad. It's that the trigger for adopting it should be one of these conditions actually existing, not the possibility that one might exist someday. You can adopt Kubernetes in the quarter you need it. Adopting it three years early means paying the tax the whole time.

The middle ground

Between raw Kubernetes and hand-managed servers there's a spectrum, and it's worth knowing where the sane points are.

Docker Compose on a VPS. This is where the HN team landed, and it's a reasonable spot: you keep containerized builds and a declarative service definition, and drop the control plane entirely. The trade-off is that you're now managing Docker networking, image builds, and volume mounts for a stack (Nginx, FPM, MySQL) that installs perfectly well as native packages. For Laravel specifically, containers solve a dependency-isolation problem that PHP mostly doesn't have.

Managed platforms. Laravel Cloud (and, historically, Vapor) moves you up an abstraction level instead of down. You trade infrastructure control for zero maintenance, at a price that scales with usage. A fair option if usage-based billing fits your revenue model and you're comfortable not owning the box.

The boring stack, automated. This is the position Deploynix occupies, so weigh my bias accordingly. The architecture in this post, provisioned Nginx and PHP-FPM, Horizon under Supervisor, atomic symlink deploys with one-click rollback, Let's Encrypt, MySQL with automated backups, and server monitoring with alerts, is exactly what Deploynix sets up on a VPS from Hetzner, DigitalOcean, Vultr, Linode, AWS, or any server you can SSH into. You get the operational conveniences people adopt Kubernetes for (repeatable provisioning, safe deploys, restarts, alerts) without the cluster underneath. Flat pricing from free to $39/month, and no control plane to babysit.

The common thread across all three: each one is somebody deciding which slice of Kubernetes's value they actually need and buying only that slice.

The bottom line

The recurring "we left Kubernetes" post isn't a fad or a skill issue. It's teams discovering, one at a time, that they adopted a tool built for Google-shaped problems to run a workload shaped nothing like Google. A team of eight spending 60 hours a week on cluster maintenance is an extreme data point, but the direction of the error is common: complexity adopted years before, or instead of, the problem it solves.

Laravel makes the decision easier than most stacks. FPM manages your web workers. Horizon manages your queue workers. The scheduler manages your cron. Symlinks give you zero-downtime deploys. The framework already contains the orchestration a single application needs, which means Kubernetes has remarkably little left to offer until you're operating at genuine multi-service, multi-team scale.

So start boring: one good VPS. Split the database when memory pressure says so. Add app servers behind a load balancer when traffic says so. Reach for Kubernetes when, and only when, you can point at one of the four conditions above and say "that's us, today." Your future self, awake at 2 a.m. reading a plain log file instead of spelunking through pod events, will thank you.

Deploying AI-Powered Laravel Apps: Queues, Streaming, Timeouts

Deploynix — Thu, 16 Jul 2026 08:11:53 +0000

Somewhere in the Laravel app you're running right now, there's a good chance an HTTP call goes out to OpenAI, Anthropic, or a local model. A chat feature, a summarizer, an agent that triages support tickets. Laravel 13 shipped in March 2026 with first-party AI primitives and the framework now literally brands itself as being for "Artisans and agents". The application layer has never been easier.

The server layer is another story. An LLM call breaks almost every assumption your default server config makes. Requests that last 30 to 120 seconds instead of 200 milliseconds. Responses that arrive token by token instead of all at once. Failures that are retry-able but cost real money every time you retry them. Nobody's hosting docs cover this, so here's the guide we wish existed: the actual server-side ops of running LLM workloads on a Laravel VPS.

Why LLM Calls Break Your Server's Defaults

Your stack was tuned for short requests. Every layer between the browser and the LLM API has a timeout or a buffer, and nearly all of them are wrong for AI workloads:

Layer

Default

Why it breaks

PHP max_execution_time

30 seconds

A 45-second completion dies mid-request

Nginx fastcgi_read_timeout

60 seconds

Nginx returns a 504 while the model is still thinking

Nginx FastCGI buffering

Streamed tokens sit in a buffer; the user sees nothing, then everything

Laravel HTTP client

30 seconds

Long completions throw ConnectionException

Queue retry_after

90 seconds

A 2-minute job gets handed to a second worker and billed twice

That last row is the expensive one, and we'll spend a whole section on it. But first, the rule that prevents most of these problems from mattering at all.

Rule #1: LLM Calls Belong in Queued Jobs

Never make an LLM call inside a web request if you can possibly avoid it. A synchronous call ties up a PHP-FPM worker for the full duration of the completion. With the default pm.max_children on a small VPS, a dozen users triggering AI features simultaneously can exhaust your entire FPM pool, and now your login page is timing out because your summarizer is slow.

Queued jobs fix the architecture. The web request dispatches a job and returns in milliseconds. A dedicated worker makes the slow call. The result comes back to the user via polling, broadcasting, or a stream (more on that below).

Here's a job skeleton with every LLM-specific concern handled:

php

Your Deploy Pipeline Is an Attack Surface

Deploynix — Thu, 16 Jul 2026 08:02:47 +0000

In May 2026, the Laravel ecosystem got its wake-up call. According to a report from The Hacker News, more than 700 versions of Laravel-Lang packages were compromised and republished carrying a credential stealer. The malicious code targeted exactly what you'd expect a professional operation to target: cloud provider keys, CI/CD tokens, and SSH keys. And it executed through the most mundane command in a PHP developer's day, a Composer install.

Laravel-Lang isn't an obscure dependency. It's the de facto standard for localized validation messages, pulled into countless Laravel projects, often as a transitive dependency nobody consciously chose. If your pipeline installed a poisoned version, the malware didn't need to break into anything. Your own build ran it, with your own credentials sitting in the environment.

This post is a hardening guide. We'll walk through what happened, why deploy pipelines are such a valuable target, and the concrete Composer, secrets, and access-control changes that shrink your exposure to the next one. Because there will be a next one.

What Actually Happened With Laravel-Lang

The chain was depressingly simple:

Someone with publish rights was the way in. The typical entry point in attacks like this is a compromised maintainer account: not the code, not Packagist itself, just one set of credentials belonging to someone who can publish.
Poisoned versions were published. Over 700 package versions across the Laravel-Lang ecosystem were republished with malicious code embedded, per The Hacker News report.
The code executed at install time. The payload ran through Composer's plugin and script auto-run behavior. No one had to call the malicious code. Installing the package was enough.
Credentials were exfiltrated. The stealer hunted for cloud keys, CI/CD tokens, and SSH keys, the exact material a build environment has to hold in order to do its job.

Notice what's missing from that chain: any vulnerability in your application. Your Laravel code could be flawless, your server patched, your firewall tight. None of it matters, because the attack came in through the front door, wearing the badge of a package you already trusted.

That's the uncomfortable lesson of supply-chain attacks. composer install is remote code execution that you invited. Usually the code it fetches is what you wanted. The entire security model rests on "usually."

Why Deploy Pipelines Are the Perfect Target

If you were writing a credential stealer, where would you want it to run? Not on a developer's laptop with a lock screen and half the secrets missing. You'd want the deploy pipeline, because the pipeline is where everything valuable converges:

Cloud provider keys. CI jobs that push to S3, invalidate CDN caches, or manage infrastructure carry API keys for AWS, DigitalOcean, Hetzner, and friends.
SSH keys. Something has to connect to your production servers. That something holds a private key, and it's usually the pipeline.
Git credentials. Deploy keys and access tokens that can read (and sometimes write) your source code.
Database credentials. Migrations run during deploys, which means the pipeline environment can reach your database with real credentials.
Third-party API keys. Stripe, Paddle, Mailgun, OpenAI. If your .env is present at build time, it's all there.

And on top of that concentration of secrets, the pipeline has one more property attackers love: it runs code automatically, on a schedule or on every push, with no human watching the output scroll by. A malicious composer install on a developer machine might get noticed. The same install in CI at 2 a.m. gets a green checkmark.

Your deploy pipeline is a machine that holds all your keys and executes third-party code without supervision. Treat it with the same suspicion you'd apply to a public-facing endpoint, because functionally, that's what it is. Packagist is the input.

Hardening Composer

This is the core of the defense. Composer has grown real security controls over the past few major versions; most projects just never turn them on.

Turn Off Script Execution Where You Can

The single highest-impact flag is --no-scripts:

composer install --no-scripts --no-interaction --prefer-dist --no-dev --optimize-autoloader

With --no-scripts, Composer skips all lifecycle scripts during the install. For a Laravel app that matters more than it sounds, because the default composer.json wires artisan into the install process:

"scripts": {
    "post-autoload-dump": [
        "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
        "@php artisan package:discover --ansi"
    ]
}

That package:discover call boots your Laravel application on the build machine, which loads and executes code from your installed packages. If a dependency is poisoned, this is one of the moments its code gets to run with your pipeline's environment in scope.

What breaks when you skip scripts: package discovery doesn't run, so Laravel's package manifest goes stale. The fix is to run the step explicitly, as a separate, deliberate command after the install and after any audit checks have passed:

composer install --no-scripts --no-dev --prefer-dist --no-interaction
composer audit --locked --no-dev
php artisan package:discover --ansi

Be honest with yourself about what this buys you. It doesn't make a malicious package safe; a poisoned service provider will still execute the moment your app boots. What it does is reorder the pipeline so that nothing from a fresh install executes before your checks have run, and it strips out the install-time execution paths that stealers rely on for the smash-and-grab. Defense in depth, not a force field.

A few packages genuinely rely on their own plugin hooks to function (patch appliers, autoload tweakers, php-http/discovery). Test your build with --no-scripts in staging first, and document any step you have to re-add manually. On Deploynix, deployment hooks give you full control of the install command, so swapping the default for the hardened sequence above is a one-line edit to your deploy script.

Allowlist Composer Plugins Explicitly

Scripts come from your root composer.json, but plugins come from your dependencies, and plugins execute during Composer's own runtime. Since Composer 2.2, plugin execution is gated behind the allow-plugins config. In interactive mode Composer prompts you; in CI, an unconfigured plugin fails the build, which is exactly the behavior you want.

Make the allowlist explicit in composer.json rather than letting prompts accumulate answers over the years:

"config": {
    "allow-plugins": {
        "pestphp/pest-plugin": true,
        "php-http/discovery": false
    },
    "sort-packages": true
}

Two rules for maintaining it:

Default to false. Only flip a plugin to true when you understand what it does and why the package can't work without it.
Review the list in every PR that touches composer.json. A new true entry in allow-plugins is someone granting install-time code execution to a third party. That deserves at least the scrutiny you'd give a new middleware.

You can also pass the --no-plugins flag in CI jobs that only need composer audit or validation, so those jobs execute no plugin code at all.

Install From the Lockfile, Never Update on a Server

Your composer.lock file is a security control, not just a convenience. It pins every package, including transitives, to an exact version with a hash. Commit it, always, even for internal projects.

Then enforce one rule everywhere outside a developer machine: CI and servers run **composer install, never composer update.** An update resolves versions at run time, which means a package poisoned five minutes ago can walk straight into production. An install from a committed lockfile can only ever give you versions that a human put into a commit, versions that existed and were reviewed at a specific point in time.

Add validation so drift fails loudly:

composer validate --strict
composer install --no-scripts --no-dev --prefer-dist --no-interaction

composer validate --strict fails the build if the lockfile is out of sync with composer.json, which catches the classic "edited composer.json on the server" mistake before it becomes a habit. --prefer-dist pulls packaged archives rather than cloning source repositories, which is faster and keeps .git metadata out of your vendor directory.

The Laravel-Lang incident is the argument for this discipline in one sentence: a project installing from a lockfile pinned before the window couldn't have pulled a poisoned version; a project running unpinned updates during it easily could.

Run composer audit in Every Pipeline

Composer ships a built-in audit command that checks your installed packages against published security advisories:

composer audit --locked --no-dev

--locked audits what's actually in your lockfile rather than what's currently installed, and --no-dev skips dev dependencies that never reach production. The command exits non-zero when it finds an advisory, so wiring it into CI is a two-line job:

security-audit:
  script:
    - composer audit --locked --no-dev

Be clear about what this catches: known compromises. During the window between a malicious publish and the advisory going out, composer audit is blind. That's not a reason to skip it. Advisories for incidents like Laravel-Lang land fast once discovered, and an audit step in the pipeline is the difference between finding out from your CI logs and finding out from your cloud provider's fraud team. Run it on every deploy and on a daily schedule against your main branch, so a quiet week doesn't mean a quiet audit.

Treat New Transitive Dependencies as Code Review

Every composer.lock diff in a pull request is a list of code you're about to execute in the most privileged environment you own. Review it like one:

Read the lock diff. A minor bump of a first-party package that drags in three brand-new transitive dependencies is worth thirty seconds of "what are these and who maintains them."
Prefer tight constraints for risky positions. Anything that runs at install time or in your build tooling deserves a pinned or narrowly-ranged constraint, not ^ across major functionality changes.
Use Dependabot or Renovate, but keep a human in the loop. Automated update PRs are great; automated merges of dependency updates are how poisoned versions ship themselves. Renovate's minimumReleaseAge setting is particularly useful here: requiring a release to be several days old before a PR is even opened means most compromised versions get caught and pulled by the ecosystem before your bot ever proposes them.

None of this is heavy process. It's five minutes per dependency PR, and it's the only point in the whole pipeline where a human actually looks at what's changing in vendor/.

Secrets Hygiene on the Server

Assume the stealer runs anyway. What does it get? That question should drive how you lay out secrets on the server, and the honest answer for most Laravel apps is "everything, because it's all in one .env file readable by the same user that runs Composer."

Practical steps, in order of impact:

Make every credential least-privilege. Your DB_USERNAME should not be root. It should be an application user with privileges on the application database and nothing else: no GRANT, no SUPER, no access to other schemas. A stolen app credential that can read one database is an incident; a stolen root credential is a company-ending event on a bad day.
Scope third-party API tokens. Most providers support restricted tokens now. A Stripe restricted key, an S3 key limited to one bucket with no s3:DeleteObject, a DigitalOcean token scoped to read-only where write isn't needed. Every scope you don't grant is blast radius you don't have.
Keep production secrets out of build environments entirely. Your CI job that runs composer install and npm run build does not need DB_PASSWORD or STRIPE_SECRET. If your pipeline copies the full .env into the build stage "because it was easier," the Laravel-Lang stealer just thanked you.
Encrypt what's at rest. Laravel's php artisan env:encrypt lets you keep an encrypted environment file in the repo and decrypt it only at release time on the target server. We covered the full setup in our guide to secrets management for Laravel, including key handling and rotation workflows.

The theme is the same everywhere: a credential stealer can only steal what's present and can only use what the credential permits. You control both.

Scoped Deploy Keys and Short-Lived Tokens

Access credentials for the pipeline itself deserve the same least-privilege treatment as application secrets.

Repo deploy keys should be read-only. A deploy key exists so a server can clone your code. It does not need push access, and on GitHub, deploy keys are read-only unless you deliberately check the write box. Leave it unchecked. A stolen read-only key leaks your source; a stolen writable key lets an attacker commit a backdoor that your own pipeline will then deploy for them.

One SSH key per server, never shared. When every server has its own keypair, revocation is surgical: one compromised box means one key removed from authorized_keys and one deploy key deleted from the repo. When five servers share a key, revoking it is a coordinated outage. Per-server keys also make your audit logs meaningful, because you can tell which machine actually connected.

Short-lived CI tokens beat long-lived personal access tokens. A PAT created in 2024 and pasted into CI secrets is a skeleton key with no expiry and, usually, the full permissions of the human who made it. Modern CI platforms can do better: GitHub Actions can authenticate to cloud providers through OIDC, minting a token that lives for the duration of one job and dies with it. A stealer that grabs a token with a fifteen-minute lifetime has a fifteen-minute problem. One that grabs your two-year-old PAT has your account.

Rotate on a schedule, not just on incidents. Quarterly rotation of deploy keys and CI tokens is cheap insurance, and more importantly, it forces you to keep the rotation procedure documented and working. The worst time to discover nobody remembers how to rotate the deploy key is during an actual incident.

Reducing the Blast Radius

Separation is the strategy that makes every other control matter more. Two environments with half your secrets each are strictly better than one environment with all of them.

Separate CI credentials from production credentials. The build stage and the release stage are different trust zones. Build needs: repo read access, package registries, maybe an artifact store. Release needs: SSH to servers, and that's about it. When those are distinct credentials in distinct jobs, a compromise during composer install gets the build zone only. This maps naturally onto atomic deployment models, where the build happens in a fresh release directory and only a symlink swap touches production; we broke down that flow in The Anatomy of a Zero-Downtime Deploy.

Think about what each environment can reach. From your CI runner, can you connect to the production database? If yes, why? Most teams' answer is "migrations," and the better pattern is running migrations from the server during release rather than from CI across the internet. Every network path you close is a path the stealer can't use either.

Watch your egress. Exfiltration needs an outbound connection. Build machines and app servers typically have completely unrestricted outbound internet, which means stolen credentials leave silently. Full egress allowlisting is real work and often impractical for a small team, but even coarse measures help: outbound firewall rules on database servers (which have no business calling the internet), and alerting on unusual outbound destinations from app servers. Server-level monitoring that shows you resource and traffic anomalies, like the monitoring built into Deploynix, won't name the attacker, but a build server suddenly talking to an unfamiliar host during install is exactly the anomaly worth a look.

Keep staging honest. Staging environments often accumulate production credentials out of convenience: the real Stripe key "to test something," the production S3 bucket "temporarily." A stealer doesn't care which environment it runs in. If staging holds production secrets, staging is production, minus the hardening.

If You Installed a Compromised Version

Advisory lands, and your lockfile shows one of the poisoned versions. Here's the run book. Work top to bottom; the order matters because you must rotate the credentials that control other credentials first, or an attacker uses the parent to reissue the child while you're busy.

1. Contain first. Pin or remove the compromised package versions, redeploy from a clean lockfile, and freeze other deploys while you work.

2. Rotate in dependency order:

Tier 1: Accounts that mint credentials
  - Cloud provider root/IAM credentials and API tokens
  - Git hosting account credentials, 2FA recovery codes
  - CI/CD platform tokens and secrets store

Tier 2: Credentials those accounts issued
  - Deploy keys (all repos)
  - Server SSH keypairs
  - CI job tokens, webhook secrets

Tier 3: Application secrets (the whole .env)
  - Database passwords
  - APP_KEY (plan for re-encryption of encrypted data)
  - Mail, payment, storage, and third-party API keys

Rotate everything the compromised environment could read, not just what you can prove was taken. Stealers don't leave receipts.

3. Audit **authorized_keys on every server.** Line by line, on each box the pipeline could reach. Any key you can't positively attribute to a person or a specific server gets removed. Check ~/.ssh for every user account, not just the deploy user.

4. Review cloud audit logs. Pull the trail for the exposure window: API calls from unfamiliar IPs, newly created IAM users or access keys, changed security groups, new instances in regions you don't use. Attackers create their own credentials fast precisely so your rotation doesn't lock them out; look for what was created, not just what was used.

5. Check the Git side. New deploy keys, new webhooks, new OAuth app grants, recent commits and tags you don't recognize, changed CI workflow files. A modified pipeline definition is persistence, and it survives credential rotation.

6. Write it down. Which versions, which environments, what was rotated, what the logs showed. If customer data was reachable, your disclosure obligations may kick in, and a timeline built the same day beats one reconstructed a month later.

The 10-Point Pipeline Hardening Checklist

Print this one, or paste it into the team wiki:

composer.lock is committed, and every non-dev environment runs composer install, never composer update.
CI installs use --no-scripts, with package:discover run explicitly after checks pass.
allow-plugins is an explicit allowlist in composer.json, defaulting to false, reviewed on every change.
composer audit --locked runs in every pipeline and daily on the main branch.
Dependency update PRs get human review of the lock diff; no auto-merge, with a minimum release age on your update bot.
Build environments hold no production secrets. No DB_PASSWORD, no payment keys, nothing production can't afford to leak.
Every credential is least-privilege: non-root DB users, scoped API tokens, restricted cloud keys.
Deploy keys are read-only and per-server SSH keys are unique, so revocation is surgical.
CI-to-cloud auth uses short-lived tokens (OIDC where available) instead of long-lived PATs.
A rotation run book exists and has been tested, covering the full tiered order above.

Ten items, none of which require new tooling or budget. Most teams can close the whole list in an afternoon plus one staging test cycle.

What to Change This Week

The Laravel-Lang attack didn't exploit Laravel, or PHP, or a CVE in anything. It exploited the ecosystem's default posture of executing whatever the registry serves, delivered through Composer's install-time auto-run per the reporting on the incident, via what is typically the entry point in attacks like this: a compromised maintainer account. That posture is yours to change, at least for your own pipeline.

You won't get to zero risk. You will, with lockfile discipline, script and plugin controls, scoped credentials, and separated environments, get to a place where a poisoned package yields an attacker a read-only deploy key and a fifteen-minute token instead of the keys to your cloud account. That's the difference between a bad afternoon and a disclosure letter.

If you're rebuilding your deploy flow anyway, our production security checklist for 2026 covers the server-side half of this picture, and Deploynix gives you the scaffolding the pipeline half sits on: customizable deployment hooks for the hardened install sequence, atomic releases with one-click rollback when you need to back out a bad dependency fast, and server monitoring that surfaces the anomalies worth investigating. The supply chain is everyone's problem now. Your pipeline doesn't have to be the easy target in it.

Cloud Repatriation for Laravel: From AWS to a $10 VPS

Deploynix — Wed, 15 Jul 2026 19:26:00 +0000

When 37signals announced they were leaving AWS back in 2023, a lot of people treated it as a stunt. DHH being DHH. Three years later, the receipts are in: roughly $2 million saved per year, on track for about $10 million over five years, and the stunt has become a trend with a name. Cloud repatriation.

This post is that trend translated for Laravel. Not the abstract "cloud vs on-prem" debate that enterprise architects have at conferences, but the specific question you're probably asking: my Laravel app runs on EC2 with RDS, ElastiCache, an ALB, and a NAT gateway, and the bill keeps creeping up. Would the same app run fine on one or two VPSes for a tenth of the cost? Usually, yes. Here's the evidence, the trade-offs, and the exact migration sequence.

Why repatriation stopped being contrarian

The numbers moved first, then the sentiment followed. A Barclays CIO survey found that 86% of CIOs plan to move at least some workloads back from public cloud, up from 43% in 2020. That's not a fringe position anymore. That's the majority.

The case studies got harder to dismiss too. 37signals is the loud one, but GEICO, an insurance company with genuinely serious infrastructure, cut per-core costs by roughly 50% by pulling workloads back in-house. When a regulated Fortune 500 insurer and a small software company reach the same conclusion from opposite ends of the market, the middle should pay attention.

The developer mood shifted alongside the finance numbers. A Hacker News thread from January 2026 titled "Kubernetes Was Overkill" hit the front page with a story that will sound familiar: a team of eight spending around 60 hours a week feeding a k8s cluster, who moved to Docker Compose on plain servers and got their week back. Laravel teams rarely run Kubernetes, but the underlying pattern is identical. Complexity you adopted for scale you don't have, billed monthly.

None of this means AWS is bad. It means AWS is priced for workloads most Laravel apps don't resemble. Let's look at where the money actually goes.

What does a Laravel app on AWS actually cost?

A "standard" AWS deployment for a production Laravel SaaS usually looks like this: one or two EC2 instances (or Fargate tasks) behind an Application Load Balancer, RDS MySQL with Multi-AZ enabled because the checkbox said "recommended," an ElastiCache Redis node for cache and queues, a NAT gateway so instances in private subnets can reach the internet, S3 for storage, and CloudWatch collecting logs.

Every one of those line items bills separately, and several bill in ways people consistently forget:

The ALB charges per hour just for existing, then again in "load balancer capacity units" based on traffic. It never sleeps, so it never stops billing.
The NAT gateway is the classic gotcha. Hourly charge plus a per-gigabyte processing charge on traffic in both directions. Your Composer installs, API calls, and S3 uploads from private subnets all flow through it, and it quietly becomes one of the larger items on small bills.
RDS Multi-AZ roughly doubles your database instance cost, because you're paying for a standby replica that does nothing except wait for a failover most teams never experience.
CloudWatch charges for log ingestion and retention. A chatty Laravel app shipping every request log to CloudWatch can generate a surprising bill for the privilege of storing logs you'll never read.
Egress deserves its own section, because it's the single most distorted price in cloud computing.

The egress tax

Data leaving AWS is billed at a rate that has no relationship to what bandwidth actually costs. Compare the overage pricing across providers, per Better Stack's DigitalOcean vs Hetzner comparison:

Provider

Egress overage per TB

Cost of 5 TB/month egress

AWS

~$90

~$450

DigitalOcean

$10

$50

Hetzner

~€1.19

~€5.95

That's not a typo. AWS charges roughly 75 times what Hetzner charges for the same gigabyte leaving the same kind of datacenter (treating euro and dollar as near parity). And both DigitalOcean and Hetzner bundle generous transfer allowances with each server before overage pricing even kicks in, so a typical Laravel SaaS on either provider pays nothing at all for egress.

If your app serves file downloads, media, exports, or a busy API, egress alone can justify the migration before you've compared a single compute price.

The compute gap

Compute pricing tells a similar story with smaller multiples. The same Better Stack comparison puts a 4 GB Hetzner cloud instance at around €7.99/month against $24/month for a 4 GB DigitalOcean droplet, and an on-demand AWS instance with comparable specs lands well above both once you add EBS storage and the surrounding services. I've broken down full stage-by-stage numbers in the real cost of running a Laravel SaaS if you want the line-item version.

The honest summary: for a modest production Laravel app, the AWS stack described above typically lands in the low-to-mid hundreds of dollars per month once egress, NAT, Multi-AZ, and CloudWatch are counted. The equivalent VPS stack lands at $20-40. Per month.

What do you actually give up by leaving AWS?

This is where repatriation posts usually get dishonest, so let's not. AWS sells real things. The question is whether your Laravel app uses them.

Managed RDS failover. This one's genuine. Multi-AZ RDS gives you automatic failover in about a minute with zero operational effort, and nothing on a $10 VPS replicates that exactly. But be honest about your current posture: a lot of teams pay the Multi-AZ premium while running a deploy process, DNS setup, or application architecture that can't survive a failover gracefully anyway. On a VPS, your equivalent is automated backups plus a tested restore procedure, which for most single-region SaaS apps means accepting that a catastrophic database server failure costs you some minutes of downtime and a restore, maybe once every few years. Many businesses will trade that for thousands of dollars a year. Some genuinely can't, and that's fine; see the "when not to repatriate" section.

IAM. Astonishingly powerful, and almost entirely unused by small teams. If your IAM setup is "one role with too many permissions that everything uses," you're not giving up much. On a VPS the equivalent surface is SSH keys, a firewall, and per-database credentials, which is a smaller and more comprehensible security model. Worth noting: the May 2026 Laravel-Lang supply-chain attack specifically targeted cloud keys and CI/CD tokens via compromised Composer packages, so a smaller credential footprint isn't just simpler, it's a smaller target.

Autoscaling. The headline cloud feature, and the least used in practice. Most Laravel SaaS traffic is boringly predictable: a daily curve, a weekly curve, growth measured in months. Autoscaling solves a problem shaped like "10x traffic in ten minutes," and if that's not your traffic shape, you're paying elastic prices for static load. On a VPS you buy headroom instead, and vertical scaling (resize, reboot, minutes of work) covers each growth step.

Compliance checkboxes. If enterprise procurement requires workloads inside AWS with specific attestations, that's a business constraint, not a technical one. No VPS math changes it.

Notice what's not on the list: deployment tooling, SSL, monitoring, queue workers, cron. None of that is an AWS feature. It's all reproducible on any server, which is exactly the layer a provisioning platform handles.

The repatriation architecture

Here's the shape that replaces the EC2 + RDS + ElastiCache + ALB stack for the overwhelming majority of Laravel apps:

Option A: one beefy VPS. Nginx, PHP-FPM, MySQL, Valkey, and Horizon on a single 8-16 GB Hetzner instance. This sounds like heresy to anyone trained on AWS reference architectures, but a single modern VPS has far more headroom than most people believe, and it removes an entire class of network latency and configuration between your app, database, and cache.

Option B: app server + database server. Same stack, split across two instances: the app server runs Nginx, PHP-FPM, Horizon, and Valkey; the database server runs MySQL alone with its own RAM budget. This buys you independent scaling, a database that survives app-server rebuilds, and cleaner resource isolation for maybe $15-25/month extra. It's my default recommendation for anything with paying customers.

Either way, this is precisely the setup Deploynix provisions: pick Hetzner (or DigitalOcean, Vultr, Linode, or bring your own box over SSH), choose the server type, and it configures Nginx, PHP-FPM, MySQL with automated backups, firewall rules, Supervisor-managed Horizon workers, cron, and Let's Encrypt SSL. The Hetzner + Deploynix combination is the specific pairing I'd reach for on cost grounds.

What about S3? Keep it, or don't. Object storage is the one AWS service where staying put is defensible: S3 itself is cheap, and Laravel's filesystem abstraction means the app doesn't care. But if your S3 egress is meaningful (users downloading files), Cloudflare R2 or Backblaze B2 speak the S3 API, so the migration is usually a new disk in config/filesystems.php, a bucket sync, and R2 in particular charges nothing for egress:

'r2' => [
    'driver' => 's3',
    'key' => env('R2_ACCESS_KEY_ID'),
    'secret' => env('R2_SECRET_ACCESS_KEY'),
    'region' => 'auto',
    'bucket' => env('R2_BUCKET'),
    'endpoint' => env('R2_ENDPOINT'),
],

The migration playbook, step by step

The whole trick to a low-stress repatriation is refusing to do a big-bang cutover. You run both stacks in parallel, prove the new one works, and move traffic last. Budget two to three weeks of calendar time, most of it waiting, not working.

Step 1: Provision the target

Spin up the VPS (or pair) and let your provisioning tool build the stack: Nginx, PHP matching your production version, MySQL, Valkey, Supervisor. On Deploynix this is the connect-provider-and-click part; either way, resist the urge to hand-configure. You want this server reproducible, because the ability to rebuild it in minutes is your replacement for a chunk of AWS's managed-ness.

Step 2: Deploy the app in parallel

Point a deployment at the new server from the same Git repository and get a full release running against a copy of production data. Port your environment config carefully; this is the step where you discover the twelve .env values that only exist in the ECS task definition. Set up zero-downtime releases with symlink swaps from day one so the new stack's deploy story is already better than the old one.

Run the boring checklist: queues process, scheduled tasks fire, mail sends, uploads land in the right bucket, Horizon dashboard loads.

Step 3: Replicate the database

For small databases, a dump-and-restore during a maintenance window is fine and you can skip the replication ceremony:

mysqldump --single-transaction --routines --triggers \
  -h your-rds-endpoint.rds.amazonaws.com -u admin -p \
  your_database | gzip > dump.sql.gz

For anything where extended downtime hurts, set the VPS MySQL up as an external replica of RDS. Extend binlog retention on RDS first so the replica can catch up after the initial import:

CALL mysql.rds_set_configuration('binlog retention hours', 168);

Then import a consistent snapshot on the VPS and start replication against the RDS endpoint. From that point the VPS database trails production by seconds, and your eventual cutover downtime shrinks to almost nothing.

Step 4: Shadow-test

Point a staging hostname at the new server and use it for real. Run your test suite against it. Have the team do their daily work through it for a few days. If you have synthetic monitoring or smoke tests, aim them here. What you're hunting for is environmental drift: a missing PHP extension, a locale difference, an outbound IP that a third-party API hasn't allowlisted. Every one of these is cheap to find now and expensive to find at 2 a.m. post-cutover.

Step 5: Drop the DNS TTL

Two days before cutover, lower the TTL on your app's DNS records to 60 seconds. This is the least glamorous and most important step in the playbook. A 24-hour TTL turns "roll back the cutover" from a one-minute action into a day of split traffic.

Step 6: Cut over

Pick a low-traffic window. One thing php artisan down does not do: it doesn't stop Horizon workers or the scheduler, which will happily keep processing jobs and writing to RDS after you promote the VPS, a recipe for split-brain writes. Stop them explicitly on the old stack first (disable Supervisor's autorestart before terminating, or just stop the program) and comment out the scheduler's cron entry there. The sequence:

# On the old stack
php artisan down --retry=60
supervisorctl stop horizon   # or disable autorestart, then: php artisan horizon:terminate
crontab -e                   # comment out the schedule:run entry

# On the VPS: confirm the replica has fully caught up before promoting
mysql -e "SHOW REPLICA STATUS\G"   # Seconds_Behind_Source must read 0

# On the VPS: stop replication, promote to primary
mysql -e "STOP REPLICA; RESET REPLICA ALL;"

# Point .env at the local database, then
php artisan config:cache
php artisan up

Flip DNS to the new server's IP. With a 60-second TTL, traffic moves over within a couple of minutes. Watch the logs, watch Horizon, watch your error tracker. Total downtime with the replication approach: under five minutes, most of it caution rather than necessity.

Step 7: Keep AWS warm, then kill it properly

Leave the old stack running but idle for two weeks. It's your rollback path, and it's also where you'll notice the stragglers: a webhook still pointed at the old ALB, a cron job that only runs monthly, an office IP allowlist. After two weeks of silence, decommission deliberately, because AWS keeps billing for things you forgot were separate: EBS volumes and snapshots, unattached Elastic IPs, the NAT gateway, the ALB itself. Terminating the EC2 instances alone does not stop the bleeding. Walk the bill line by line until it reads zero.

What if you're on Vapor?

The serverless pendulum is swinging back too, and I say that as someone who wanted it to work. Vapor's promise was Laravel without servers; the reality for many teams was cold starts, VPC-plus-NAT charges for database access, and a bill that scaled with success in unpredictable ways. I've written up the full accounting in the serverless hype vs reality for Laravel apps.

If you're on Vapor today, you have two exits. The official one is Laravel Cloud: there's a documented Vapor-to-Cloud migration path, and Cloud's June 2026 pricing update brought tiers from $5/month with scale-to-zero hibernation and spending caps. It's a genuinely reasonable landing spot if you want to stay fully managed and usage-priced.

The other exit is the one this post describes: a VPS, where the pricing model is a flat number you can recite from memory. Vapor apps migrate to servers more easily than people expect, since the codebase is still just Laravel. Queues move from SQS back to Redis with a config change, and the things Vapor abstracted (workers, cron, TLS) are exactly what server platforms automate anyway. If cost predictability was your reason for leaving, usage-priced serverless to usage-priced managed cloud is a smaller move than it looks; the VPS is the option that actually changes the model.

When you shouldn't repatriate

Repatriation is a tool, not a religion. Stay on AWS when:

Your traffic is genuinely elastic. If you routinely see 10x spikes on unpredictable schedules (ticketing, viral consumer apps, election-night dashboards), autoscaling is doing real work for you and a fixed-size VPS forces you to pay for peak capacity all month. That said, check your actual metrics before claiming this; almost everyone thinks their traffic is spikier than it is.
Compliance is welded to AWS services. If your SOC 2 scope, HIPAA BAA, or enterprise contracts name specific AWS services, migrating means re-auditing. Sometimes that's worth it. It's rarely worth it this quarter.
You're deeply coupled to AWS primitives. An app orchestrating Lambda fan-outs, Kinesis streams, and Textract jobs isn't a Laravel app on AWS, it's an AWS app with a Laravel frontend. Repatriate the parts that make sense, if any.
Nobody on the team will own servers. A managed panel removes most of the ops burden, but "most" isn't "all." Someone still needs to care when a disk-usage alert fires. If your team has zero appetite for that, at any tooling level, a fully managed platform is the honest choice.

A worked 12-month example

Take a modest SaaS: a few thousand users, one production app, a queue-heavy workload, 2 TB of monthly egress from file exports.

The AWS version of this stack (two small instances behind an ALB, Multi-AZ RDS, an ElastiCache node, a NAT gateway, CloudWatch, and that 2 TB of egress at ~$90/TB) reliably lands in the mid hundreds of dollars per month. I won't pretend to a precise total, because AWS bills never are, but the egress line alone is around $180/month and it's rarely the biggest item. Call it several thousand dollars a year, trending up.

The VPS version, priced concretely:

Item

Monthly cost

Hetzner app server, 4 vCPU / 8 GB (Nginx, FPM, Horizon, Valkey)

~€7.99-16 (source)

Hetzner database server, 8-16 GB MySQL

~€8-16 (estimate, based on Hetzner's cited 4 GB pricing)

Deploynix Starter plan

$7 flat

Egress (2 TB, within included allowance)

Backups to S3-compatible storage

pennies per month

Total

~$30-40/month

That's roughly $360-480 a year for the whole production footprint, management layer included, versus thousands on AWS for the same app serving the same users. The delta pays for a lot: a contractor security review, a year of every SaaS tool in your stack, or simply margin. And because both the servers and the Deploynix plan are flat-priced, the number in month twelve is the number in month one. No usage meter, no surprise NAT charges, no egress anxiety.

Where this leaves you

The repatriation trend isn't developers getting nostalgic for servers. It's the market repricing a decade of "nobody got fired for choosing AWS" now that 86% of CIOs have looked at the bill and companies like 37signals and GEICO have published what leaving actually saves.

For Laravel specifically, the trade is unusually favorable. The stack is simple (Nginx, PHP-FPM, MySQL, Redis-compatible cache, a queue worker), it runs beautifully on commodity VPSes, and the operational layer that used to require a sysadmin is now a $12/month platform subscription. The parallel-run playbook above takes the drama out of the move: provision, deploy, replicate, shadow-test, drop the TTL, cut over, keep AWS warm for two weeks.

If you want to test the thesis cheaply, that's what free tiers are for. Provision a Hetzner box through Deploynix's Free plan, deploy a copy of your app next to your AWS stack, and compare the two with your own traffic. The numbers in this post are persuasive. Yours will be decisive.

FrankenPHP in Production on a Plain VPS: The Real Setup

Deploynix — Wed, 15 Jul 2026 19:19:55 +0000

FrankenPHP quietly won the Laravel Octane server race. Swoole needs a compiled PHP extension that fights with your package manager. RoadRunner needs a separate binary and its own YAML config. FrankenPHP is one download, and since Octane added support for it as documented on blog.laravel.com, it's become the default answer when someone asks "which Octane server should I use?"

We covered the conceptual trade-offs in PHP-FPM vs Laravel Octane on Deploynix. This post is the follow-up: the hands-on guide to actually running FrankenPHP on a normal Ubuntu VPS. Not a container platform, not a managed runtime. A plain server you SSH into, with systemd, Nginx, and a deploy script.

We'll set it up properly, then spend serious time on the part most tutorials skip: the worker mode bugs that only show up in production, and the situations where you shouldn't use FrankenPHP at all.

What FrankenPHP Actually Is

FrankenPHP is not "another PHP server" bolted together from parts. It's a Caddy module that embeds the PHP interpreter directly into the Caddy web server, compiled into a single Go binary. Download one file and you have a web server, TLS termination, HTTP/2 and HTTP/3, and PHP itself. No PHP-FPM pool, no separate php package, no FastCGI socket between the web server and the runtime.

That single-binary design is why it beat the alternatives on developer experience. There's nothing to compile and no extension to match against your PHP version, because the PHP version ships inside the binary.

It runs in two distinct modes, and the difference matters more than anything else in this post:

Classic mode works like PHP has always worked. Each request boots your application from scratch, handles the request, and throws everything away. It's a drop-in replacement for Nginx + PHP-FPM with fewer moving parts. Same execution model, same safety guarantees.

Worker mode boots your Laravel application once, holds it in memory, and feeds it request after request. The framework bootstrap, container building, provider registration, config loading: all of it happens once per worker instead of once per request. This is the mode Octane uses, and it's where the performance wins come from. It's also where the bugs live.

One more thing you get for free: because FrankenPHP is Caddy, it can do automatic HTTPS, provisioning and renewing Let's Encrypt certificates on its own when it faces the internet directly. Whether you actually want it facing the internet directly is a real question we'll get to.

Installing FrankenPHP on Ubuntu

You have two sensible paths on a plain VPS. Pick based on how the binary will be managed: standalone, or through Octane.

Path 1: The Static Binary

For classic mode or manual setups, grab the static binary:

curl -fsSL https://frankenphp.dev/install.sh | sh
sudo mv frankenphp /usr/local/bin/
frankenphp version

That's the whole installation. One binary in /usr/local/bin, no apt repositories, no php8.4-fpm service, no extension packages. The static build bundles PHP and the common extensions Laravel needs. The rest of this guide follows the Octane path below, but the systemd and worker-mode guidance applies to both.

Path 2: Through Laravel Octane

If you're running Laravel (you probably are, if you're reading this blog), let Octane manage the binary:

composer require laravel/octane
php artisan octane:install --server=frankenphp

Octane downloads a FrankenPHP binary into your project and wires up the config. From there, starting the server locally is one command:

php artisan octane:start --server=frankenphp --host=127.0.0.1 --port=8000

We prefer the Octane path for Laravel apps for one practical reason: the binary version travels with the project, so your deploy pipeline and your production server can't drift apart. The FrankenPHP Laravel docs cover both approaches if you want the raw-Caddyfile route instead.

Run it once in the foreground, hit the port with curl, confirm you get your app back. Then never run it in the foreground again. Production processes belong to systemd.

A Production systemd Unit That Actually Works

Every FrankenPHP tutorial ends with php artisan octane:start --server=frankenphp in a terminal, which dies the moment your SSH session drops. Here's a complete unit file for a real server. Save it as /etc/systemd/system/octane.service:

[Unit]
Description=Laravel Octane (FrankenPHP)
After=network.target mysql.service redis-server.service
StartLimitIntervalSec=60
StartLimitBurst=5

[Service]
Type=simple
User=deployer
Group=deployer
WorkingDirectory=/home/deployer/myapp/current
ExecStart=/usr/bin/php artisan octane:start \
    --server=frankenphp \
    --host=127.0.0.1 \
    --port=8000 \
    --workers=4 \
    --max-requests=500
Restart=always
RestartSec=3

# Caddy (inside FrankenPHP) needs writable config/data dirs
Environment=XDG_CONFIG_HOME=/home/deployer/.config
Environment=XDG_DATA_HOME=/home/deployer/.local/share

# Resource guardrails
LimitNOFILE=65535
MemoryHigh=768M
MemoryMax=1G

[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable --now octane
sudo systemctl status octane

A few deliberate choices worth explaining:

User=deployer, not root. FrankenPHP binds to 8000 here, not 443, so it needs no privileges. If you later let it bind 443 directly, grant CAP_NET_BIND_SERVICE via AmbientCapabilities rather than running as root.
WorkingDirectory points at current. If you use atomic symlink deploys (and you should, see The Anatomy of a Zero-Downtime Deploy), the unit points at the symlink. Remember that the running workers resolved that path at boot; more on that in the deploy section.
The XDG variables are not optional. Caddy wants somewhere to write config and state. Without them, you'll chase a confusing "failed to create config directory" error on first start under systemd, because the service environment doesn't have the HOME-derived defaults your shell does.
MemoryHigh/MemoryMax are your safety net against slow leaks. MemoryHigh throttles, MemoryMax kills and, combined with Restart=always, gives you a self-healing worst case: a leaky worker set gets recycled instead of taking the whole VPS into swap.
--workers=4 is a starting point, not a recommendation. A reasonable default is one to two workers per CPU core for typical database-bound Laravel apps. Measure, then adjust.

Should Nginx Stay in Front, or Should Caddy Face the Internet?

This is the first real architecture decision, and the answer depends on what's already on the box.

Option A: FrankenPHP Behind Your Existing Nginx

If your server already runs Nginx (every Deploynix-provisioned server does, since Nginx fronts each site by default), the path of least resistance is to keep it there. Nginx keeps owning ports 80 and 443, keeps its existing Let's Encrypt certificates, and proxies to Octane on localhost:

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

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

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

    # Serve static assets directly, skip PHP entirely
    root /home/deployer/myapp/current/public;
    location ~* \.(css|js|jpg|jpeg|png|gif|svg|woff2?)$ {
        expires 30d;
        try_files $uri =404;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        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_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_buffering off;
        proxy_read_timeout 120s;
    }
}

This is the setup we run in practice. You keep everything you already trust about your Nginx config: rate limiting, static file serving, existing certificate automation, other sites on the same box. Octane becomes just another upstream. The Upgrade headers matter if you're running Reverb or any WebSocket traffic through the same host.

Option B: FrankenPHP Owns Port 443

On a fresh single-purpose VPS with nothing else running, letting FrankenPHP face the internet directly is genuinely simpler. Caddy handles certificate issuance and renewal automatically, you delete Nginx from the stack entirely, and one process serves everything.

When does each make sense?

Situation

Recommendation

Existing server with Nginx and multiple sites

Nginx in front, Octane on localhost

Deploynix or similar provisioned server

Nginx in front (it's already configured)

Fresh single-app VPS, you want minimum parts

FrankenPHP on 443 directly

You need Nginx-level rate limiting, WAF rules, or odd rewrites

Nginx in front

You want HTTP/3 without extra work

FrankenPHP directly (Caddy ships it)

The one setup to avoid: both fighting over the same ports. If Nginx holds 443 and you start FrankenPHP without telling it to use another port, it will try to bind 443, fail, and crash-loop. Explicit --host=127.0.0.1 --port=8000 in the unit file prevents that class of incident entirely.

Worker Mode Gotchas: The Section That Saves Your Weekend

Here's the mental shift. For PHP's entire history, every request started from a blank slate. Sloppy state management was invisible because the runtime threw your mess away every few hundred milliseconds. Worker mode removes the garbage truck. Your application object lives for hundreds or thousands of requests, and anything that leaks between requests is now a bug.

In our experience, these are the ones that actually bite:

Static Properties and Singletons Holding Stale State

The classic case:

class DiscountService
{
    public static ?User $currentUser = null;

    public function applyFor(User $user): void
    {
        static::$currentUser = $user;
        // ...
    }
}

Under PHP-FPM, this is merely ugly. Under worker mode, $currentUser survives the request. Request one sets it to Alice. Request two belongs to Bob, hits a code path that reads static::$currentUser, and Bob gets Alice's discount, or worse, Alice's data. This category of bug is quiet, intermittent, and horrifying, because it only reproduces under real concurrent traffic.

The same applies to container singletons that capture request state. If a service is bound with singleton() and its constructor receives the current request, the current user, or anything derived from either, that snapshot is frozen at first resolution and served to every subsequent request that worker handles. Bind request-dependent services with scoped() instead, which Octane resets between requests, or resolve the request lazily inside the method that needs it.

Before going live, audit for the usual suspects: static properties that aren't pure caches of immutable data, singletons constructed from request state, and packages that memoize per-request values in globals. Legacy packages are the biggest risk, because you didn't write the state bugs you're inheriting.

Memory That Only Grows

Even with clean request handling, long-lived PHP processes accumulate memory. Collected log context, growing arrays in third-party clients, fragmentation. Watch your Octane service for a week and you'll see resident memory climb in a slow staircase.

You have three layers of defense, and you want all three:

First, **--max-requests is the pressure valve.** The --max-requests=500 flag in our unit file tells Octane to gracefully retire each worker after 500 requests and boot a fresh one. It's the same idea as pm.max_requests in PHP-FPM: an admission that leaks happen, converted from an outage into routine hygiene. Start around 500 and lower it if memory still climbs too fast between recycles.

Second, watch the numbers. systemctl status octane shows current memory for the whole service, and journalctl -u octane shows restarts. For trends over time you want real monitoring; a leak that adds a few megabytes per hour is invisible in a status snapshot and obvious on a seven-day memory graph. This is exactly the kind of thing server-level monitoring with alerts exists for. Deploynix's built-in CPU/memory alerts will page you when the box crosses a threshold, which for a slow leak means you find out on a Tuesday afternoon instead of during Saturday's traffic spike.

Third, the systemd **MemoryMax cap** from the unit file above is the final backstop. If everything else fails, the service gets restarted rather than the server falling over.

Restart Workers on Every Deploy, No Exceptions

This is the operational rule people learn the hard way. Your workers hold the old code in memory. Deploy new code, and until the workers restart, they keep serving the previous release. With atomic symlink deploys it's stricter still: the workers resolved the old release's real path at boot, so they don't even see the symlink flip.

The fix is one line in your deploy hook:

php artisan octane:reload

This gracefully cycles the workers into the new code without dropping in-flight requests. In a Deploynix deployment hook, it slots in right after the symlink swap, alongside the queue:restart you should already be running for the same reason. If you're on Horizon, the same stale-code logic applies to queue workers, and the deploy hook handles both.

Forget this step and you get the most confusing bug class in Octane operations: "I deployed the fix but production still has the bug." You'll check the code on disk, it's correct, and you'll question your sanity for twenty minutes before remembering the workers.

What Performance Should You Actually Expect?

Time for honest framing, because this is where Octane marketing and Octane reality diverge.

What worker mode eliminates is per-request framework bootstrap: loading config, registering service providers, building the container. On a hot, simple route (an API endpoint returning a small JSON payload, a lightweight authenticated page) that bootstrap is a large fraction of total response time, and removing it is a dramatic, measurable win. This is the workload behind the impressive-looking demos, and the gain there is real. The Laravel team's own writeup is a good reference for what the FrankenPHP + Octane combination is designed to deliver.

But most production Laravel requests aren't hot, simple routes. They're three database queries, a cache read, maybe an external API call, and a Blade render. If your median request spends most of its time waiting on MySQL, removing the bootstrap shaves a modest slice off the total. Worker mode makes the PHP part of your request fast; it does nothing for the parts of your request that were already the actual bottleneck.

So the realistic picture looks like this:

Big wins: high-RPS APIs, endpoints serving mostly cached data, apps where framework boot dominates response time, servers where FPM process churn is the limiting factor.
Modest wins: typical CRUD apps that are database-bound. Latency improves, but your users may not notice.
No win at all: apps whose slow endpoints are slow because of unindexed queries or chatty external APIs. Fix those first; they're cheaper fixes than a new runtime.

We deliberately won't quote benchmark numbers here, because every "FrankenPHP is N times faster" figure was measured on someone else's app, someone else's routes, and someone else's hardware. Load test your app before and after. Our load testing walkthrough on a $5 server covers a workflow you can reuse for exactly this comparison.

When Should You Not Use FrankenPHP?

The uncomfortable truth after all of the above: PHP-FPM remains the right default for most Laravel apps. FrankenPHP worker mode is a trade: you accept a stricter programming model and a new operational surface in exchange for throughput and latency. That trade only makes sense when the throughput actually buys you something.

Skip worker mode (or defer it) when:

Your codebase assumes per-request state. If the app is older, has accumulated static properties, or leans on packages you haven't audited for long-lived processes, worker mode will surface those assumptions as intermittent production bugs. The audit is real work. Until you've done it, FPM's blank-slate model is protecting you.

You depend on legacy or unmaintained packages. You can fix your own singletons. You can't easily fix a package that stashes state in a static property four dependencies deep. If your composer.json has archaeology in it, test under sustained load, not just a smoke test.

You don't have memory monitoring. Worker mode without a memory graph is flying without instruments. If nobody on the team will notice RSS climbing over a week, the first symptom of a leak will be an OOM kill during peak traffic. Set up monitoring first, Octane second.

The site is low-traffic. A brochure site, an internal tool, an app serving a few requests per second: FPM handles this without breaking a sweat, and it's simpler in every way that matters. Adding a long-lived application server to save milliseconds nobody is waiting for is complexity with no payoff.

Your bottleneck is elsewhere. Slow queries, missing indexes, no cache layer, a fat external API in the request path. Worker mode won't rescue any of that, and it's harder to debug the real problem through a new runtime.

The right time for FrankenPHP is when you have real traffic, a codebase you trust (or have audited) to be stateless per request, monitoring already in place, and a measured bottleneck that's actually PHP execution. That describes fewer apps than the hype suggests, but for those apps it's excellent.

Troubleshooting Quick Hits

The issues you'll most likely hit in the first week, and their fixes:

Service crash-loops immediately on start. Almost always a port conflict. Nginx already holds 80/443 and FrankenPHP tried to bind them. Check with sudo ss -tlnp | grep -E ':(80|443|8000)' and make sure your --host=127.0.0.1 --port=8000 flags actually made it into the unit file. Also watch for Caddy's admin API on port 2019 colliding if you run more than one instance.

"Failed to create config directory" or permission errors under systemd. The XDG variables are missing. Add Environment=XDG_CONFIG_HOME= and Environment=XDG_DATA_HOME= lines pointing somewhere your service user can write, as in the unit above. It works from your shell and fails under systemd because your shell has $HOME conveniences the service doesn't.

Deployed code not live. Workers are serving the old release from memory. Run php artisan octane:reload and add it to your deploy hook permanently.

Reading logs. Everything the service prints goes to the journal: journalctl -u octane -f to follow live, journalctl -u octane --since "1 hour ago" when investigating an incident. Laravel's own log channel still writes wherever you configured it; check both.

Memory climbing steadily. Expected to a degree. Confirm --max-requests is set, watch whether recycling flattens the staircase, and if a single worker balloons on a specific route, that route is leaking: profile it.

Weird redirects or wrong URLs behind Nginx. You're missing X-Forwarded-Proto, so Laravel thinks it's serving HTTP. Confirm the proxy headers from the Nginx block above and that your TrustProxies middleware trusts 127.0.0.1.

Where This Leaves You

FrankenPHP earned its position as the default Octane story honestly: one binary, no extension to compile, no separate config language, and Caddy's HTTPS automation included. On a plain VPS the full production setup is a binary, a systemd unit, an Nginx proxy_pass block, and one line in your deploy hook. That's a smaller footprint than either Swoole or RoadRunner asks for.

The discipline it demands is real, though. Worker mode changes PHP's oldest contract, and the price of the speed is that your code must actually be stateless between requests, your deploys must reload workers, and someone must watch the memory graph.

If you're running on Deploynix, the surrounding pieces are already in place: Nginx fronts your site, atomic symlink deploys give octane:reload its natural home in a deployment hook, daemons keep the process supervised, and server monitoring catches the memory creep worker mode makes possible. The FrankenPHP-specific parts of this guide still apply verbatim; the platform just handles the scaffolding around them.

And if after reading the "when not to use it" section you concluded that PHP-FPM is fine for your app, that's not a consolation prize. It's the correct engineering call for most Laravel applications in 2026. Revisit the decision when your traffic, not your curiosity, asks for it.

SQLite in Production for Laravel: When One File Wins

Deploynix — Wed, 15 Jul 2026 19:14:08 +0000

SQLite has been Laravel's default database since Laravel 11 shipped in 2024. Run laravel new, hit enter through the prompts, and your app is talking to a single file on disk. No daemon, no port 3306, no credentials to rotate.

Most reactions to this fall into two camps. One camp treats SQLite as a toy you swap out before your first real user. The other treats it as a silver bullet that makes database servers obsolete. Both are wrong, and both will cost you either money or sleep.

This is the guide for the middle ground: you run Laravel on a VPS, you want fewer moving parts, and you need to know exactly what SQLite demands in production, where it breaks, and when to walk away from it. Real config blocks throughout.

Why SQLite Suddenly Got Respectable

Five years ago, suggesting SQLite for production in a Laravel forum got you laughed out of the thread. Three things changed.

Laravel made it the default. That single decision moved SQLite from "testing database" to "the thing thousands of production apps launched on." The framework followed through: the modern config/database.php exposes SQLite pragmas as first-class connection options, which is most of what production tuning requires.

Modern VPS hardware removed the old bottleneck. SQLite's classic weakness was slow disks. NVMe storage is now standard on entry-level instances. A Hetzner CPX-class box with 4 GB of RAM runs around €7.99/month, against $24/month for the equivalent DigitalOcean droplet, and either one gives you disk latency measured in microseconds. A query against a local NVMe file skips the network hop entirely. There's no connection pool, no TCP handshake, no round trip. A read is a function call into a library living in your PHP process.

Replication tooling matured. The strongest argument against SQLite was always "one file, one disk, one bad day away from losing everything." Tools like Litestream changed that math by streaming every change to S3-compatible storage continuously. We'll set that up below.

None of this makes SQLite the right answer everywhere. It makes SQLite a serious option for a specific shape of application: single server, read-heavy, modest write volume. That shape covers more Laravel apps than most people admit.

The Production Config Laravel Actually Needs

SQLite's out-of-the-box defaults are conservative to the point of being hostile for web workloads. The default journal mode locks the entire database during writes, and the default busy timeout is zero, meaning a second concurrent write throws SQLITE_BUSY: database is locked immediately instead of waiting its turn.

Laravel lets you fix all of this declaratively. Here's the connection block that should be in every production config/database.php:

'sqlite' => [
    'driver' => 'sqlite',
    'database' => env('DB_DATABASE', database_path('database.sqlite')),
    'prefix' => '',
    'foreign_key_constraints' => env('DB_FOREIGN_KEYS', true),
    'busy_timeout' => 5000,
    'journal_mode' => 'wal',
    'synchronous' => 'normal',
],

Four settings do the heavy lifting:

journal_mode => 'wal': switches to Write-Ahead Logging. This is the single most important line. Without it, every write blocks every read. More on what WAL actually changes in the next section.
busy_timeout => 5000: when a connection hits a lock, it retries for up to 5 seconds before giving up instead of failing instantly. This turns "random 500 errors under load" into "a write occasionally waits a few extra milliseconds." It's the difference between SQLite feeling flaky and feeling boring.
synchronous => 'normal': the default FULL setting forces an fsync on every transaction. NORMAL in WAL mode syncs at checkpoint boundaries instead. In our experience this is the right trade: the database can't corrupt on power loss, though the last few transactions before a hard crash may be lost. If you're running a payments ledger, keep FULL. For everything else, NORMAL is noticeably faster.
foreign_key_constraints => true: SQLite ships with foreign key enforcement off for backwards-compatibility reasons that date to 2009. Turn it on. You want the database rejecting orphaned rows, not your application code hoping to catch them.

One warning that saves people real pain: WAL mode requires a local filesystem. It relies on shared memory between processes, and it does not work correctly on NFS or other network filesystems. If your database file lives on network-attached storage, you've quietly reintroduced the network hop you were trying to eliminate, plus a corruption risk. Local disk only.

What Does WAL Mode Actually Change?

In the default rollback-journal mode, a write transaction takes an exclusive lock on the whole database. Readers wait for writers. Writers wait for readers. On a web server handling concurrent requests, that's a queue of PHP-FPM workers stacking up behind a single UPDATE.

WAL inverts the model. Writes get appended to a separate -wal file, and readers keep reading a consistent snapshot of the main file. The practical result:

Readers never block writers, and writers never block readers. Your traffic can keep serving pages while a write is in flight.
There is still exactly one writer at a time. This is the constraint that never goes away. Two simultaneous writes serialize; the second one waits (which is why busy_timeout matters).

For a typical Laravel app, where the overwhelming majority of queries are reads, this constraint is far less scary than it sounds. A blog, a documentation site, a dashboard, a booking tool with a few hundred writes a minute: none of these come close to saturating a single writer on NVMe.

Where write contention actually bites

The apps that hurt on SQLite aren't the ones with lots of users. They're the ones where the framework itself hammers the database with writes. And here's the trap: recent Laravel defaults put the queue, the cache, and sessions in the database. On MySQL that's a reasonable default. On SQLite it means every queued job, every cache write, and every session touch competes for the same single-writer lock as your actual business data.

The fix is to give the chatty infrastructure workloads to Redis or Valkey, which is a one-line install on most VPS setups, and reserve SQLite for the data you actually care about:

DB_CONNECTION=sqlite
DB_DATABASE=/home/deploynix/example.com/shared/database/production.sqlite

QUEUE_CONNECTION=redis
CACHE_STORE=redis
SESSION_DRIVER=redis

With that split, SQLite holds users, orders, and posts, while the thousands of ephemeral writes per minute go to a store built for exactly that. If your queue volume is serious, our Laravel queues guide covers connection and worker tuning in detail. The short version: never point a busy queue at your SQLite file. It works right up until it doesn't, and the failure mode is your whole app slowing down together.

How Far Does One File Actually Go?

Honest answer: further than you think, and we're deliberately not going to invent benchmark numbers here, because SQLite throughput depends almost entirely on your write mix and your disk.

The qualitative framing that holds up in practice:

Read-heavy apps rarely hit the wall. The SQLite project itself states that any site getting fewer than 100,000 hits per day should work fine with SQLite, and describes that as a conservative estimate. On modern NVMe hardware with WAL mode, read throughput is bounded by your PHP layer long before the database.
Write-heavy apps hit the single-writer limit. If your core workload is high-frequency inserts from many concurrent sources (event ingestion, chat, real-time analytics), writes serialize and latency climbs. No pragma fixes an architectural mismatch.
The database size ceiling is not your problem. SQLite handles databases in the tens of gigabytes without drama. You'll outgrow the operational model (one server, one file) long before you outgrow the file format.

A useful mental test: pull up your production query log and count writes per second at peak, excluding cache, sessions, and queue traffic. If the number is in the single or low double digits, SQLite will not be your bottleneck. If it's in the hundreds and climbing, read the graduation section below.

Backups: The Part Everyone Gets Wrong

Here's the trap that catches almost everyone moving SQLite to production: cp database.sqlite backup.sqlite is not a safe backup.

If a write transaction is in flight while the copy runs, you can capture a torn, inconsistent snapshot. Worse, in WAL mode, recent committed transactions live in the -wal sidecar file. Copy only the main file and your "backup" is silently missing the newest data. It will restore. It will look fine. It will be wrong.

SQLite gives you two correct tools instead.

One-shot and scheduled backups

The .backup command uses SQLite's online backup API, which produces a consistent snapshot even while the app is writing:

sqlite3 /home/deploynix/example.com/shared/database/production.sqlite \
  ".backup '/home/deploynix/backups/production-$(date +\%Y\%m\%d-\%H\%M).sqlite'"

The alternative is VACUUM INTO, which also produces a consistent copy and compacts it at the same time, dropping the dead space left by deleted rows:

sqlite3 /home/deploynix/example.com/shared/database/production.sqlite \
  "VACUUM INTO '/home/deploynix/backups/production-$(date +\%Y\%m\%d).sqlite'"

On Deploynix, the practical setup is a scheduled cron job created from the dashboard: run one of the commands above nightly, then push the file to S3-compatible storage with rclone or the AWS CLI, and prune anything older than your retention window. Wasabi or a DigitalOcean Space costs pennies a month at typical SQLite database sizes. Ten minutes of setup, and you have the same offsite-backup posture a managed MySQL setup gives you.

Note the escaped % signs in those commands. In a crontab, a bare % is interpreted as a newline, and the resulting failure is silent. If you paste the command into a shell script that cron invokes, drop the backslashes.

Continuous replication with Litestream

Nightly backups mean you can lose up to a day of data. For anything with real users, run Litestream as well. It sits alongside your app, watches the WAL, and continuously streams every change to S3-compatible storage. Recovery point drops from "last night" to "a few seconds ago."

Install it and drop a config at /etc/litestream.yml:

dbs:
  - path: /home/deploynix/example.com/shared/database/production.sqlite
    replicas:
      - type: s3
        bucket: myapp-litestream
        path: production
        endpoint: https://s3.eu-central-1.wasabisys.com
        access-key-id: ${LITESTREAM_ACCESS_KEY_ID}
        secret-access-key: ${LITESTREAM_SECRET_ACCESS_KEY}
        retention: 72h

Litestream needs to run permanently, and this is where a process supervisor earns its keep. The packaged systemd unit works fine, or on Deploynix you can register litestream replicate as a daemon and let Supervisor handle restarts, exactly the way you'd run Horizon.

Disaster recovery is a single command against an empty path:

litestream restore -o /home/deploynix/example.com/shared/database/production.sqlite \
  s3://myapp-litestream/production

Do a test restore once, before you need it. A replication pipeline you've never restored from is a hypothesis, not a backup.

The Deployment Gotcha That Deletes Your Database

This is the SQLite production mistake we see most often, and it's brutal because everything works perfectly until your second deploy.

Zero-downtime deployment works by building each release in a fresh directory and atomically swapping a current symlink, which is how atomic deploys are structured on Deploynix and every similar tool. Now think about where Laravel puts SQLite by default: database/database.sqlite, inside the application directory. Inside the release.

Deploy once, and your database is born inside releases/20260713101500/. Deploy again, and the new release gets a brand-new empty file while your real data sits stranded in the previous release directory, waiting for the release-cleanup step to delete it entirely. Users vanish. Orders vanish. It looks exactly like a catastrophic data loss bug, and it's just a path.

The fix is the same pattern used for storage/ and .env: the database lives in the shared directory that survives every deploy, and the app points at it by absolute path.

/home/deploynix/example.com/
├── releases/
│   ├── 20260712091412/
│   └── 20260713101500/
├── shared/
│   ├── storage/
│   ├── .env
│   └── database/
│       └── production.sqlite       releases/20260713101500

Then in the shared .env:

DB_DATABASE=/home/deploynix/example.com/shared/database/production.sqlite

Add a deployment hook that guarantees the directory exists before migrations run, so the very first deploy on a fresh server doesn't fall over:

mkdir -p /home/deploynix/example.com/shared/database
touch /home/deploynix/example.com/shared/database/production.sqlite
php artisan migrate --force

Two smaller deployment notes worth knowing. First, migrations that rebuild tables (SQLite implements some ALTER TABLE operations as create-copy-swap) briefly hold the write lock; your configured busy_timeout means in-flight requests wait a few seconds rather than erroring, which is exactly the behavior you want mid-deploy. Second, remember that the -wal and -shm sidecar files live next to the database. They belong in shared/database/ too, and no backup script or deploy hook should ever touch them independently.

When Should You Graduate to MySQL or Postgres?

SQLite in production isn't a religion. It's a phase, and for plenty of apps it's a permanent one. But there are clear, unambiguous signals that the phase is over:

You need a second app server. This is the hard line. SQLite is a local file; two servers can't share it safely, and the workarounds (network filesystems, distributed SQLite layers) trade away the simplicity that justified SQLite in the first place. The moment horizontal scaling is on the roadmap, plan the migration.
Sustained concurrent writes are your core workload. If profiling shows writers regularly queuing behind busy_timeout at normal traffic, not just during spikes, you've outgrown the single-writer model.
You need read replicas, failover, or point-in-time recovery beyond what Litestream offers. A client-server database makes these first-class features rather than bolt-ons.
Your team or your compliance auditors need standard database tooling. Access control per user, audit logging, and established DBA workflows all assume a database server.

The migration itself is usually less painful than people fear, provided you stayed inside Eloquent and the query builder. Export with sqlite3 .dump, massage the schema, or more simply: point your migrations at the new connection, run them fresh, and write a one-off command that copies rows table by table. Apps that avoided driver-specific raw SQL typically move in an afternoon.

Choosing what to graduate to is its own decision. Our MySQL vs. MariaDB vs. PostgreSQL comparison breaks that down; the short version is that MySQL is the safe default for Laravel and Postgres wins when you need richer types and querying. Either way, provisioning a dedicated database server next to your app server is a few clicks, and if you're cost-sensitive about running a second box, Hetzner's price-to-performance keeps the graduation cheap.

The Decision Checklist

Run your app through this before committing either way.

SQLite is a strong fit if all of these are true:

One application server, and no multi-server plans for the next year or so
Read-heavy workload; peak writes per second in the low double digits or below
Queues, cache, and sessions are on Redis or Valkey, not the database
The database file lives on local NVMe, not network storage
You've set up WAL mode, busy_timeout, and either Litestream or scheduled .backup jobs
The database file lives in shared storage, outside your releases directory

Pick MySQL or Postgres from day one if any of these are true:

Load balancer and multiple app servers, now or soon
High-frequency concurrent writes are the product (ingestion, messaging, telemetry)
You need replicas, managed failover, or granular database-level access control
Ops or compliance requirements assume a client-server database

Notice what's not on either list: user count, revenue, or how "serious" the project is. Those are the wrong axes. The right axes are write concurrency and server topology.

The bottom line

SQLite in production for Laravel is neither hype nor heresy. It's a precise engineering trade: you give up multi-server topologies and heavy concurrent writes, and in exchange you get zero network latency, one less service to patch and monitor, and a database that backs up as a single file. For a single-VPS Laravel app with sane write volume, that trade is genuinely good, and the framework's defaults now reflect it.

The production checklist is short and non-negotiable: WAL mode with busy_timeout and synchronous=NORMAL, infrastructure workloads on Redis, .backup or Litestream instead of cp, and the database file in shared storage where atomic deploys can't orphan it. Every one of those steps fits naturally into a Deploynix setup: scheduled crons for backups, Supervisor daemons for Litestream, deployment hooks for the shared path, and one-click rollback for everything else. Get those four things right and one file really does beat a database server, right up until the day it doesn't, and you'll see that day coming from a long way off.

Upgrading to Laravel 13 in Production with Zero Downtime

Deploynix — Tue, 14 Jul 2026 16:20:15 +0000

Laravel 13 shipped on March 17, 2026, and it's the friendliest major upgrade the framework has had in years: effectively zero breaking changes, with the only hard requirement being PHP 8.3 or newer. The new toys are real too, including first-party AI primitives, native attribute syntax, JSON:API resources, and vector search support, all covered in the official release notes.

Here's the part that should get your attention: bug fixes for Laravel 12 end in August 2026. From where we're sitting in July, that's next month. After that, only security patches land on 12, and every framework-level bug you hit stays yours to work around.

So the upgrade window is now. But "run composer update and hope" is not a production strategy. This is a playbook for doing the upgrade on live servers, with real traffic flowing, without a maintenance page and without a single dropped request. We've run this process across dozens of production apps, and the steps below are in the order that actually keeps you safe.

Why August 2026 Is Your Deadline

Laravel's support policy is simple: each major release gets roughly 18 months of bug fixes and two years of security fixes. Laravel 12's bug-fix window closes in August 2026. Laravel 13's runs well into 2027.

That matters more than it sounds. Bug-fix EOL is the point where "we'll upgrade next quarter" turns into "we're patching vendor code in a fork." If a queue serialization edge case or an Eloquent regression bites you in September, the fix ships for 13, not for 12.

The good news is that the 12 to 13 jump is unusually cheap. The Laravel team explicitly designed it as a low-friction release. No renamed core methods, no removed helpers, no directory reshuffle. In our experience, the framework upgrade itself is a one-hour job for most apps. The production rollout is where teams get burned, and that's what the rest of this post is about.

Step 1: Verify PHP on the Server, Not Just Your Laptop

Laravel 13 requires PHP 8.3 at minimum. Your laptop probably has 8.4 already. Your production box is the one that will lie to you.

CLI and FPM Are Two Different PHPs

A server can happily run PHP 8.4 on the command line while Nginx routes every web request to a PHP 8.2 FPM pool. Check both:

# What the CLI runs (this is what artisan and composer use)
php -v

# What FPM pools are actually installed and running
systemctl list-units 'php*-fpm*'

# What your site actually uses: check the socket in your Nginx vhost
grep fastcgi_pass /etc/nginx/sites-enabled/your-app.conf
# fastcgi_pass unix:/run/php/php8.2-fpm.sock;    releases/20260710091500

Build Everything in the New Release First

Every expensive or risky operation happens inside the new release directory while the old one keeps serving traffic untouched:

RELEASE=/home/deploy/app/releases/20260713104500
git clone --depth 1 --branch main git@github.com:acme/app.git "$RELEASE"

ln -nfs /home/deploy/app/shared/.env "$RELEASE/.env"
rm -rf "$RELEASE/storage"
ln -nfs /home/deploy/app/shared/storage "$RELEASE/storage"

cd "$RELEASE"
composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction

php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache

Notice the caches are rebuilt inside the new release, before the swap. This matters more during a framework upgrade than on any normal deploy: bootstrap/cache/config.php is a serialized artifact of the framework version that generated it. A Laravel 12 config cache read by Laravel 13 code, or the reverse, is the classic source of "it deployed fine and then everything 500'd." Because caches live per-release, the live Laravel 12 release keeps its own caches and never sees the new ones.

One deliberate omission: there is no php artisan down anywhere in this process. Maintenance mode exists for deploys that mutate shared state in place. Atomic releases don't, so the maintenance page is pure self-inflicted downtime.

Migrations: Additive-Only, and Isolated

Migrations are the one step that touches shared state, so they get their own rule for the upgrade deploy: additive changes only. New tables, new nullable columns, new indexes. Nothing renamed, nothing dropped, no column type changes.

The reason is sequencing. Migrations run before the symlink swap, which means the old Laravel 12 code serves traffic against the new schema for a window of seconds. Old code ignores a column it doesn't know about; old code crashes hard on a column that vanished. Additive migrations make that window, and your rollback, safe. Destructive cleanup ships in a separate deploy a week later, once 13 is proven.

Run them from the new release:

php artisan migrate --force --isolated

The --isolated flag takes a cache-backed lock so that two servers deploying at once can't both run the migrations. If you deploy to multiple app servers, it's not optional.

The Swap

The cutover is one atomic rename:

ln -nfs "$RELEASE" /home/deploy/app/current-new
mv -T /home/deploy/app/current-new /home/deploy/app/current

mv -T on a symlink is atomic on Linux. Every request before it sees Laravel 12; every request after it sees Laravel 13. No request ever sees a mixture, provided your Nginx config uses $realpath_root (as in the vhost above) so PHP resolves the real release path instead of caching the current symlink. Follow the swap with a graceful systemctl reload php8.4-fpm to flush opcache, which finishes in-flight requests before recycling workers.

This releases-plus-symlink flow with per-release cache builds is exactly what Deploynix runs on every deploy, on DigitalOcean, Hetzner, Vultr, Linode, AWS, or your own VPS, with deployment hooks for the migration and cache steps. If you'd rather not maintain the bash yourself, that's the button. The definitive guide to Laravel deployment in 2026 walks through the full pipeline.

Step 5: Restart Everything That Holds Code in Memory

The symlink swap updates what Nginx and FPM serve. It does nothing for long-lived processes that loaded your code at boot and kept it in memory. This is the single most common way a "successful" Laravel 13 deploy fails in production.

Picture it: your web tier is on 13, but a Horizon worker started yesterday is still executing Laravel 12 framework code, reading jobs that your new code serialized with 13's payload expectations, resolving config through a bootstrapped 12 kernel. You get intermittent job failures that don't reproduce anywhere, because they depend on which worker picks up the job. We've seen teams chase this for days.

So the swap is immediately followed by:

# Horizon: finishes current jobs, exits, Supervisor boots it on the new code
php artisan horizon:terminate

# Plain queue workers, if you run any outside Horizon
php artisan queue:restart

# Scheduler needs nothing: each tick is a fresh process via cron

Both commands are graceful. Workers complete the job in hand before exiting, so nothing is lost mid-flight, and Supervisor restarts them inside the new release path. If Supervisor's command points at a hardcoded old release directory instead of current, fix that first; it's a rollback landmine. Deploynix manages Horizon and queue daemons through Supervisor and issues the terminate as a post-deploy step automatically; there's a full walkthrough in Running Laravel Horizon on Deploynix.

Running Octane? Same principle, different command:

php artisan octane:reload

Octane with FrankenPHP or Swoole keeps the entire framework booted in memory between requests, so a stale Octane master is even worse than a stale queue worker: it's your whole web tier serving old code after the "deploy" finished. The reload recycles workers gracefully. More on those trade-offs in PHP-FPM vs. Laravel Octane.

The Rollback Plan

You don't have a rollback plan unless you've defined it before the deploy. For an atomic-release upgrade, the plan is short because the design did the work.

Code rollback: point the symlink back.

ln -nfs /home/deploy/app/releases/20260710091500 /home/deploy/app/current-new
mv -T /home/deploy/app/current-new /home/deploy/app/current
cd /home/deploy/app/current && php artisan horizon:terminate && php artisan queue:restart
sudo systemctl reload php8.4-fpm

Fifteen seconds, and you're back on Laravel 12. This works because the old release directory is completely intact: its own vendor directory, its own composer.lock, its own config caches. You never rolled back by downgrading packages in place, which is slow, and fails at the worst possible moment. The lockfile in each release is your time machine; keep at least three old releases around. In Deploynix this is the one-click rollback button doing the same symlink move plus the worker restart.

Database rollback: don't. The schema is the real risk in any upgrade deploy, and the answer is that you already de-risked it in Step 4. Because your migrations were additive-only, Laravel 12 code runs perfectly well against the post-upgrade schema; the extra columns just sit there unread. Running migrate:rollback on a production database under incident pressure is how a five-minute code rollback becomes a data-loss postmortem. Roll code back freely; roll schema forward only.

The Pre-Flight Checklist

Print this, or paste it into the pull request description:

[ ] Production PHP verified at 8.3+ on both CLI and the FPM pool Nginx actually uses
[ ] PHP upgrade (if needed) shipped and soaked as its own deploy, days before the framework upgrade
[ ] composer why-not laravel/framework 13.0 returns nothing
[ ] Framework and first-party packages (Horizon, Reverb, Sanctum, Pest) bumped in one lockfile change
[ ] composer audit clean; lockfile diff reviewed for unfamiliar packages
[ ] Full test suite green in CI on the production PHP version
[ ] Queued job serialize/deserialize covered by a test
[ ] Deploy uses atomic releases; config:cache, route:cache, view:cache run inside the new release before the swap
[ ] No php artisan down in the deploy script
[ ] Migrations in this deploy are additive-only; destructive changes parked for a follow-up
[ ] migrate --force --isolated if more than one server deploys
[ ] Post-swap: horizon:terminate / queue:restart / octane:reload as applicable, plus FPM reload
[ ] Supervisor programs point at current, not a hardcoded release path
[ ] Previous release retained; rollback command written down before the deploy starts
[ ] Error tracker and server monitoring open in a tab for thirty minutes after cutover

Deploy on a quiet weekday morning, not Friday at 5 p.m. You want a full working day of real traffic on Laravel 13 while everyone's at their desk.

Where This Leaves You

Laravel 13 is the rare major version where the framework side of the upgrade is nearly free: no meaningful breaking changes, a PHP 8.3 floor, and 12's bug fixes ending in August 2026. The engineering work isn't in the version bump. It's in the rollout: knowing what PHP your FPM pool really runs, building caches per release, keeping migrations additive, and never letting a stale worker execute old code against new state.

Do it in that order and the upgrade is an anticlimax, which is exactly what a production upgrade should be. Your users see nothing. Your error tracker sees nothing. Next month, when Laravel 12's bug-fix window closes, you're already on the version that gets the fixes.

If the atomic releases, symlink swaps, Horizon restarts, and one-click rollbacks are the part you'd rather not hand-maintain in bash, that's the layer Deploynix automates on any server you point it at, from a $5 Hetzner box to your existing AWS account. The upgrade playbook stays the same either way. What matters is that you run it before August.