DEV Community: Deploynix

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

$12 flat

Egress (2 TB, within included allowance)

Backups to S3-compatible storage

pennies per month

Total

~$35-45/month

That's roughly $420-540 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.

Migrating Laravel from Railway, Render, or Fly.io to a VPS

Deploynix — Tue, 14 Jul 2026 15:52:17 +0000

Railway, Render, and Fly.io are genuinely good at what they're built for: getting a container on the internet in an afternoon. The trouble starts six months later. Your queue worker is a separately billed "service." Your Postgres add-on costs more than a whole server would. Egress is metered. And PHP is clearly a second-class citizen on platforms designed around Node and Go, so things Laravel considers basic, like the scheduler or Horizon, feel bolted on.

If you want the full argument for leaving, we've already made it in why Laravel developers are leaving generic PaaS. This post is the other half: the how. It's a numbered runbook you can follow this weekend, with real commands for each platform, a database migration plan that keeps downtime to minutes, and a rollback path in case something goes sideways.

You're in good company making this move. In a Barclays CIO survey, 86% of CIOs said they plan to move at least some workloads back from public cloud, up from 43% in 2020. At the extreme end, 37signals reports saving roughly $2M per year, about $10M over five years by leaving AWS. Your numbers will be smaller. The direction is the same.

Step 1: Inventory Everything You're Actually Running

Before you touch a server, write down every moving part of your app. PaaS platforms hide a lot behind toggles, and the migrations that go wrong are almost always the ones where someone forgot a cron job or a webhook URL.

Your checklist:

Web process: how many instances, how much RAM, which PHP version
Queue workers: how many, which queues, Horizon or plain queue:work
Scheduler: is schedule:run wired up as a cron service or a dedicated process
Database: engine, version, size on disk
Redis/Valkey: used for cache only, or also queues and sessions
Object storage: platform volumes, Tigris, or external S3
Environment variables: all of them, including the ones set years ago
Inbound integrations: Stripe webhooks, OAuth callbacks, anything that points at your current URL

Exporting environment variables

This is the part people do by hand, badly, at 11pm. Use the CLI instead.

Railway:

npm i -g @railway/cli
railway login
railway link          # select your project and environment
railway variables --kv > railway.env

The --kv flag gives you KEY=value lines you can diff against your local .env.

Render: the dashboard's Environment tab works for small apps, but the API is faster and complete:

curl -s -H "Authorization: Bearer $RENDER_API_KEY" \
  "https://api.render.com/v1/services/$SERVICE_ID/env-vars?limit=100" \
  | jq -r '.[].envVar | "\(.key)=\(.value)"' > render.env

Fly.io: fly secrets list only shows digests, not values, by design. The reliable way to get actual values is to dump them from a running machine:

fly ssh console -C "printenv" \
  | grep -E '^(APP_|DB_|DATABASE_|REDIS_|CACHE_|QUEUE_|MAIL_|AWS_|SESSION_|BROADCAST_)' \
  > fly.env

Now audit the export. Strip platform-injected variables (RAILWAY_*, RENDER_*, FLY_*, PORT) since they won't exist on your VPS. Note every variable that contains a platform hostname, like an internal postgres.railway.internal DB host. Those all change. Treat the exported file as radioactive: it contains production secrets, so keep it out of Git and delete it when you're done.

Step 2: Provision the VPS

One honest advantage PaaS platforms have is that they made you forget how cheap raw compute is. A 4 GB Hetzner CPX-class instance runs about €7.99/month, versus $24/month for the equivalent 4 GB DigitalOcean droplet. Either is a fraction of what most teams pay a PaaS for the same workload once you add up web, worker, database, and Redis line items.

Sizing guidance from apps we've migrated:

Your PaaS footprint

VPS to start with

One small web service, hobby DB

2 vCPU / 4 GB (Hetzner ~€7.99, DO $24)

Web + worker + 1-5 GB database

4 vCPU / 8 GB

Multiple workers, Horizon, busy DB

4-8 vCPU / 16 GB, or split app and DB onto two servers

Start with everything on one box: Nginx, PHP-FPM, MySQL or Postgres, Valkey, workers. It simplifies the migration enormously, and splitting the database out later is a much smaller project than this one. Egress pricing is also worth noticing: Hetzner charges around €1.19/TB against DigitalOcean's $10/TB and AWS's roughly $90/TB, which matters if your app serves files.

You have two ways to do this step. Manually: create the server in the provider console, then spend an evening with apt, PHP repositories, and config files. Or provision it through Deploynix, which connects to Hetzner, DigitalOcean, Vultr, Linode, AWS, or any custom VPS over SSH, and installs the full Laravel stack (Nginx, PHP-FPM, your database, Valkey, Supervisor) with production settings in one pass. We've written up why Hetzner plus Deploynix is our favorite price-to-performance combo if you want the detailed reasoning.

Either way, by the end of this step you should be able to SSH in and see PHP 8.3 or 8.4 (Laravel 13 requires PHP 8.3 or higher), your database engine, and Nginx answering on port 80.

Step 3: Recreate Your Services on the VPS

Everything the PaaS gave you as a toggle now becomes a config file. There are exactly four of them that matter. None is complicated.

Nginx + PHP-FPM for the web process

server {
    listen 80;
    server_name app.example.com;
    root /var/www/app/current/public;

    index index.php;
    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

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

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Note the root points at current/public. Deploy into timestamped release directories and symlink current to the live one; that structure is what makes atomic deploys and instant rollbacks possible, as covered in the anatomy of a zero-downtime deploy.

Supervisor for queue workers

Your PaaS "worker service" becomes a Supervisor program:

[program:app-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/current/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
numprocs=4
user=deploy
stopwaitsecs=3600
stdout_logfile=/var/log/supervisor/app-worker.log

Match numprocs to however many worker instances you ran on the PaaS. If you use Horizon, run one php artisan horizon program instead and let it manage the worker pool itself.

Cron for the scheduler

One line, and it's the line PaaS platforms made weirdly hard:

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

The database and Valkey

Install MySQL or Postgres locally, create the production database and a dedicated user, and point DB_HOST=127.0.0.1. Same for Valkey (REDIS_HOST=127.0.0.1). Localhost round trips are measured in microseconds; you'll likely notice queries getting faster compared to a managed add-on in another availability zone.

If you provisioned through Deploynix, all four of these are dashboard items rather than files: sites get the Nginx template automatically, queue workers and daemons are Supervisor entries you create in the UI, and cron jobs are a form field. The result on disk is the same.

Finally, deploy the app itself to the new server, with the adapted env file from Step 1, and run it against a copy of staging data or an empty database for now. You want the code proven on the new box before the real data arrives.

Step 4: Migrate the Database with Minimal Downtime

This is the step people fear, and for most apps the fear is oversized. For small-to-mid-size databases, a dump-and-restore inside a short maintenance window is simpler and safer than anything clever.

The maintenance window approach

First, do a full rehearsal restore days before cutover, with the app still live on the PaaS. This tells you exactly how long the real one will take.

Postgres (Railway, Render, and Fly all hand you a DATABASE_URL):

# Dump from the PaaS database
pg_dump "$DATABASE_URL" --format=custom --no-owner --no-acl -f app.dump

# Restore on the VPS
pg_restore --no-owner --no-acl --clean --if-exists \
  -d "postgresql://app:secret@127.0.0.1/app_production" app.dump

MySQL:

mysqldump --single-transaction --quick --routines --triggers \
  -h PAAS_HOST -u USER -p app_production | gzip > app.sql.gz

gunzip < app.sql.gz | mysql -h 127.0.0.1 -u app -p app_production

--single-transaction gives you a consistent snapshot without locking InnoDB tables, so even the rehearsal dump is safe to run against production.

On cutover day, the real sequence is:

# 1. On the PaaS app: stop accepting writes
php artisan down --secret="migrating-2026" --retry=60

# 2. Final dump and restore (you know the duration from the rehearsal)
# 3. Verify (below), then bring the VPS app up
php artisan up

The --secret flag matters: it gives you a bypass cookie so you can poke at the old app while users see the maintenance page.

Verifying the restore

Never trust a restore you haven't counted. On both databases, compare row counts table by table.

On Postgres, don't lean on pg_stat_user_tables.n_live_tup for this: it's a statistics estimate and can read zero or stale right after a pg_restore. Run real counts on your three or four hottest tables instead:

SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM orders;
SELECT COUNT(*) FROM subscriptions;
SELECT MAX(id), MAX(created_at) FROM orders;

Same idea on MySQL, where information_schema counts are also estimates:

SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM orders;
SELECT MAX(id), MAX(created_at) FROM orders;

Check MAX(created_at) on your hottest tables against the old database. If the newest row on the VPS matches the newest row on the PaaS, you captured everything up to the freeze.

When the window won't fit

If your database is large enough that dump-and-restore blows past an acceptable window, use replication instead: take a base dump early, configure the VPS database as a replica of the PaaS one (logical replication on Postgres, binlog replication on MySQL, assuming your PaaS tier exposes the access), let it catch up over hours or days, then cutover is just "stop writes, wait for replication lag to hit zero, promote." It's more setup for near-zero downtime. Most apps reading this post don't need it; a modest database restores in minutes.

Step 5: Move Object Storage and User Uploads

Where your files live decides how hard this step is.

Already on external S3, R2, or Spaces? You're done. The bucket doesn't care where your compute runs. Copy the same AWS_* credentials to the VPS and skip ahead.

On Fly.io with Tigris, it's S3-compatible, so rclone moves everything:

rclone sync tigris:my-app-bucket spaces:my-app-bucket --progress --checksum

On Railway or Render persistent volumes, the files live inside the platform's disk. On Render, render ssh (or the SSH details in the dashboard) lets you tar the disk and pull it over. On Railway, the least painful route is a one-off artisan command that pushes the local disk to S3-compatible storage using Laravel's own filesystem abstraction:

$files = Storage::disk('local')->allFiles('uploads');

foreach ($files as $path) {
    Storage::disk('s3')->writeStream(
        $path,
        Storage::disk('local')->readStream($path)
    );
}

Run it inside the deployed service: railway ssh gives you a shell in the running container, and you run php artisan uploads:push from there. Don't reach for railway run here; it executes the command on your local machine with Railway's env vars injected, so it would read your local disk and silently push the wrong files. Once the command finishes, point the VPS at the bucket.

Our opinionated recommendation: use the migration as the excuse to move uploads to S3-compatible object storage permanently, even though your VPS has plenty of disk. It keeps servers disposable, makes the next migration trivial, and backup tooling for buckets is better than backup tooling for random directories. Sync twice: once days ahead for the bulk, once during the maintenance window for stragglers. rclone sync is idempotent, so the second pass only moves what changed.

Step 6: Cutover

Cutover is a DNS change, but good cutovers are boring because of what happened in the 48 hours before.

48 hours out: lower your DNS TTL. Find the record pointing at the PaaS (often a CNAME to yourapp.up.railway.app or similar) and drop the TTL to 300 seconds. Resolvers worldwide need time to expire the old, long TTL before the short one takes effect, which is why you do this early.

24 hours out: smoke test the VPS as if it were live. Don't wait for DNS to test. Force your own machine to resolve the domain to the new server:

curl --resolve app.example.com:443:203.0.113.10 https://app.example.com/up

Laravel's built-in /up health route should return 200. Then walk the app the same way: log in, create a record, upload a file, trigger a job and watch it process, fire a test Stripe webhook. Every service from Step 3 gets exercised before a single user touches it.

Cutover hour, in order:

php artisan down on the PaaS app (Step 4).
Final incremental database sync and storage sync.
Verify row counts.
Flip DNS: change the record to an A record pointing at the VPS IP.
php artisan up on the VPS.
Watch it land.

For step 6, keep two terminals open on the VPS:

tail -f /var/www/app/current/storage/logs/laravel.log
tail -f /var/log/nginx/access.log

With a 300-second TTL, most traffic follows within minutes of the TTL expiring. Stragglers with stubborn resolvers can take a few hours, which is exactly why the old app shows a maintenance page instead of being deleted. Watch for a wall of 500s (env problem), 404s on uploads (storage path problem), or jobs stacking up in Redis (Supervisor problem). Silence plus normal access logs means you're done.

Update the external pointers from your Step 1 inventory now: webhook URLs at Stripe and friends, OAuth redirect URIs, uptime monitors.

Step 7: The Rollback Plan You Hopefully Won't Use

Write this down before cutover, not during an incident.

Rule one: don't delete the PaaS app. Scale it down if the platform bills by usage, but keep it deployable for at least a week. Rollback is then the cutover in reverse: point DNS back at the PaaS, bring its app out of maintenance mode.

Rule two: the database defines your point of no return. DNS is instantly reversible. Data is not. Once real users have written rows to the VPS database, rolling back to the PaaS means either losing those writes or dumping the VPS database back the other way. So define the decision window explicitly: "if the new stack isn't healthy within 60 minutes of DNS flip, we go back." Inside that window, writes are few and a reverse dump is quick. After you declare success, the PaaS database becomes a stale artifact and the VPS is the single source of truth.

Rule three: rehearse the health check, not just the migration. Decide in advance what "healthy" means: /up returning 200, queue depth near zero, error rate in the logs comparable to a normal day, checkout completing. Vague success criteria are how one-hour rollback windows become three-day debugging sessions with traffic split across two stacks.

Application-level rollbacks, as opposed to migration rollbacks, get much easier after this move. Release-based deploys mean reverting a bad deploy is just a symlink swap back to the previous release directory.

Step 8: Post-Migration Checklist

The PaaS did a few things silently that are now your job. Do these in the first 48 hours, not "eventually."

SSL. Issue a Let's Encrypt certificate and confirm auto-renewal is actually scheduled. On a manual setup that's certbot --nginx -d app.example.com plus the systemd timer it installs.
Backups. Your managed database's automatic backups are gone. Set up nightly dumps shipped off-server to S3-compatible storage, and restore one to prove the pipeline works. A backup you've never restored is a hope, not a backup.
Firewall. Default deny inbound, then allow only what you serve: ufw allow OpenSSH && ufw allow 80,443/tcp && ufw enable. MySQL, Postgres, and Redis ports should never be reachable from the internet.
Monitoring. CPU, memory, disk, and an external uptime check. You lost the platform dashboard; replace it with something before you need it, not after.
Unattended security updates. apt install unattended-upgrades so kernel and OpenSSL patches don't wait for you to remember.
SSH hardening. Key-only auth, PermitRootLogin no, and consider fail2ban. The full list lives in our production security checklist.
Log rotation. Confirm logrotate covers Nginx and Laravel logs, or the disk fills up in month three.

Also worth doing while everything is fresh: cancel the PaaS services once your rollback window closes, and calendar a reminder to verify the first certificate renewal actually happened.

Before and After: What the Move Does to Your Bill

A typical Laravel app on a generic PaaS pays for four to six separately metered line items. On a VPS, they collapse into one server plus a flat management fee.

Line item

Generic PaaS

Your own VPS

Web service

Metered per instance/RAM

Included in the server

Queue worker

A second billed service

A Supervisor program on the same box

Managed Postgres/MySQL

Separate add-on, priced by storage and compute

Included in the server

Managed Redis

Another add-on

Valkey on the same box

Bandwidth

Metered egress

Hetzner ~€1.19/TB; DO $10/TB, with generous included allowances

Server management

Included (it's the product)

Deploynix from $0 free tier, $12/mo Starter

The after column, concretely: a 4 GB Hetzner instance at ~€7.99/month plus Deploynix Starter at $12/month lands around $21/month, flat, with no usage metering. The same 4 GB of RAM on DigitalOcean is $24/month if you'd rather have US datacenters and a familiar console. We won't quote a "typical" PaaS bill because it varies wildly with usage, which is rather the point. Pull up your last invoice and put it next to that table. For most apps past the hobby stage, the VPS column wins by a multiple, not a percentage, and the gap widens every month your traffic grows.

What you give up is real too: no more git push and forget, and the OS is your responsibility now (that's what the Step 8 checklist and a management layer are for). What you gain is a stack where Laravel is the first-class citizen: the scheduler is a cron line, Horizon is a daemon, and nobody bills you extra for either.

Where This Leaves You

The whole migration, condensed: inventory and export everything, provision one adequately sized VPS, turn platform toggles into four config files, rehearse the database restore before you need it, move uploads to object storage, lower TTLs early, cut over behind a maintenance page, and keep the old stack alive until you've declared success against criteria you wrote down in advance.

None of the individual steps is hard. The failure mode is skipping the boring ones: the rehearsal restore, the row-count verification, the written rollback window. Do those and the actual cutover is fifteen quiet minutes of watching access logs.

If you'd rather compress Steps 2, 3, and 8 into an afternoon, Deploynix provisions the server, configures Nginx, PHP-FPM, your database, Supervisor workers, cron, SSL, and monitoring, and gives you zero-downtime deploys with one-click rollback from day one, on your own Hetzner, DigitalOcean, Vultr, Linode, AWS, or custom server. The free tier covers one server and three sites, which is exactly the shape of a freshly escaped PaaS app. Either way, manual or managed, the destination is the same: your app, on hardware you control, at a price that stops scaling against you.

The New Laravel Forge, Nine Months Later: An Honest Review

Deploynix — Tue, 14 Jul 2026 11:40:59 +0000

On October 1, 2025, Laravel relaunched Forge with a complete redesign: zero-downtime deployments turned on by default, per-domain SSL, health checks from three regions, a new Organizations model for teams, and a first-party hosting option called Laravel VPS starting at $6/month with sub-10-second provisioning.

That was nine months ago. The launch-week hot takes have cooled, real teams have run real production workloads through it, and we can now answer the question that actually matters: did Forge 2.0 change the calculus for anyone deciding between Forge and its alternatives?

Short answer: yes, in both directions. Some of what shipped is genuinely excellent and removed long-standing reasons to leave. Some of it introduced new fine print that didn't exist before. This post walks through both, and we'll be upfront: we build Deploynix, a Forge alternative. That makes it more important, not less, that this assessment gives Forge real credit where it's earned. Judge for yourself whether it does.

What Forge 2.0 Actually Shipped

The relaunch wasn't a facelift. Laravel rebuilt the product, and the headline changes were substantial:

Zero-downtime deployments by default. Every new site deploys atomically, no configuration required.
A full UI redesign. The new interface is noticeably faster and better organized than old Forge's page-per-setting sprawl.
Laravel VPS. Servers hosted on Laravel's own infrastructure, from $6/month, provisioned in under 10 seconds, with no cloud provider account needed.
Per-domain SSL. Certificates are managed per domain rather than per site, which cleans up multi-domain setups considerably.
Health checks from three regions. Built-in HTTP uptime monitoring that pings your app from multiple geographic locations.
Organizations replacing Circles. A proper team and permissions model instead of the old server-sharing workaround.

Nine months in, all of these have held up in production. This wasn't a rushed rebrand; it was the biggest improvement to Forge since its launch.

Credit Where It's Due: Three Things Forge Got Right

Zero-Downtime by Default Was Overdue, and It's Genuinely Good

For years, a stock Forge deployment was a git pull in place followed by composer install and cache rebuilds, all against the live document root. During those seconds, requests could hit a half-updated application. You could avoid it with Envoyer (a separate subscription) or a hand-rolled deploy script, but the default was in-place mutation.

Forge 2.0 made atomic deployments the default: each deploy builds in a fresh release directory, and traffic switches over in a single symlink swap. That's the correct architecture, and making it the default rather than an upsell was the right call. If you want the mechanics of why this pattern works, including the gotchas around OPcache, queue workers, and shared storage, we've written up the anatomy of a zero-downtime deploy in detail. Deploynix has used the same releases-plus-symlink model since day one, so consider this one point of genuine convergence: the whole ecosystem now agrees on how Laravel deploys should work.

The Redesign Is Actually Faster

Old Forge accumulated a decade of UI. The new interface loads faster, groups settings sensibly, and the command palette makes jumping between servers and sites quick. This sounds cosmetic, but if you touch your deployment panel daily, interface speed is a real quality-of-life gain. No caveats here.

Laravel VPS Removed a Real Onboarding Step

Before Laravel VPS, the very first thing a new Forge user did was leave Forge: go create a DigitalOcean or Hetzner account, generate an API token, come back, paste it in. For a beginner deploying their first app, that detour was where a meaningful number of people stalled.

Laravel VPS collapses that: sign up, click, and you have a running server in under 10 seconds. For prototypes, client demos, and first deployments, that's a legitimately great experience. Provisioning a fresh server on a cloud provider API typically takes a few minutes; sub-10-seconds suggests Laravel is handing you a pre-warmed instance, and the effect is that "deploy my app" stops feeling like an infrastructure project.

Laravel VPS: The Fine Print Nobody Reads at Launch

Here's where the practitioner's assessment diverges from the launch coverage. Laravel VPS is convenient precisely because of a trade you should make with your eyes open: the server lives on Laravel's infrastructure, under Laravel's pricing, inside Laravel's platform.

You Don't Own the Account Underneath

With bring-your-own-VPS, there are two relationships: you and your cloud provider (Hetzner, DigitalOcean, wherever), and you and your management panel (Forge, Deploynix, whatever). Cancel the panel and your server keeps running untouched. You still have root SSH, the provider's console, snapshots, and backups. The panel is a layer you can peel off.

With Laravel VPS, those two relationships collapse into one. The server exists inside Forge. If you decide to leave, you're not just switching panels; you're migrating hosts. That's a fundamentally stickier arrangement, and stickiness is the point. It's not sinister, it's the same model every PaaS uses, but you should price it in before you build on it.

You Take Their Pricing, Not the Market's

The market for commodity VPS compute is brutally competitive, and the spread is enormous. A 4 GB Hetzner instance runs about €7.99/month, while a comparable 4 GB DigitalOcean droplet is $24/month, three times the price for similar specs. Egress is even more lopsided: overage bandwidth costs roughly €1.19/TB on Hetzner versus $10/TB on DigitalOcean and around $90/TB on AWS.

When you bring your own server, you get to arbitrage that spread. You can put your app on Hetzner, your US-latency-sensitive workload on Vultr, and your compliance-bound client on AWS, and manage them all from one panel. With Laravel VPS, the $6 entry point is attractive, but as you scale up the tiers you're paying whatever Laravel charges, with no ability to shop the underlying compute. For a side project, irrelevant. For a SaaS whose server bill grows with revenue, it compounds. We've broken down what the Hetzner route looks like in practice in our Hetzner price-to-performance guide.

Flexibility at the Edges

Owning the provider account also means owning the escape hatches: resizing to whatever instance type the provider offers (including CPU-optimized or dedicated-vCPU shapes), taking provider-level snapshots before risky changes, attaching block storage, moving a server between projects or teams at the provider level, or handing the whole account to a client at the end of an engagement. Client handoffs in particular are a big deal for agencies: "the server is in your DigitalOcean account, here are the keys" is a clean ending. "The server is inside our Forge organization" is not.

None of this makes Laravel VPS bad. It makes it a PaaS-shaped choice wearing VPS clothing. And it's worth noting the industry backdrop: a Barclays CIO survey found 86% of CIOs plan to move at least some workloads back off public cloud platforms, up from 43% in 2020, and 37signals has documented roughly $2M/year in savings from leaving AWS. The broad movement is toward owning your infrastructure, not renting it through more layers. Laravel VPS swims against that current, deliberately, in exchange for convenience.

Organizations: A Better Model with a Per-Seat Meter Attached

Replacing Circles with Organizations was the right structural move. Circles were always a workaround: a way to share servers that predated any real concept of a team. Organizations bring proper membership and permissions, and if you've managed a multi-developer Forge account, it's a clear upgrade.

The catch is the pricing model that came with it. Organizations meter by people: your cost scales with the number of humans you add. For a solo developer, that's invisible. For a five-person team, every hire now has an infrastructure-panel line item attached, and the incentive it creates is quietly corrosive: teams start sharing logins to avoid seats, which defeats the entire purpose of an audit-trailed permissions model.

This is the single sharpest philosophical difference with Deploynix, which includes team seats on every tier, including the Free plan. The reasoning is simple: a deployment panel gets safer as more of the team can see it, so charging per set of eyeballs optimizes for the wrong thing. Whether that difference matters to you depends entirely on your headcount; solo developers can skip this section's implications, five-person agencies cannot.

Forge 2.0 vs Deploynix, Feature by Feature

Here's the honest side-by-side as of July 2026. Where the products differ in kind rather than degree, the notes below the table explain.

Capability

Forge 2.0

Deploynix

Zero-downtime deploys

Default on new sites since Oct 2025

Atomic releases + symlink swap, all plans

Rollback

Via retained releases

One-click rollback to any retained release

Team access

Organizations, priced per user

Team seats included on every tier, including Free

Monitoring

HTTP health checks from 3 regions

Real-time CPU/memory/disk metrics with alerts

Database backups

Supported

Automated MySQL backups

SSL

Per-domain Let's Encrypt

Free Let's Encrypt, auto-renewed

Queues & daemons

Supervisor-managed workers, Horizon

Supervisor-managed workers, Horizon, Reverb

Server providers

Major clouds, custom VPS, plus Laravel VPS

DigitalOcean, Hetzner, Vultr, Linode, AWS, any custom VPS via SSH

First-party hosting

Laravel VPS from $6/mo

None; bring your own provider by design

Git sources

GitHub, GitLab, Bitbucket, custom

GitHub, GitLab, Bitbucket, self-hosted Git

API

Full API

Pricing model

Subscription plus per-user team seats

Flat: Free (1 server / 3 sites), $12, $19, $39/mo

Three rows deserve honest elaboration.

Rollback is a difference of friction, not capability. Both products keep old releases on disk, so both can technically return to a previous version. The distinction is what that costs you at 2 a.m.: on Deploynix, rollback is a single click that swaps the symlink back and restarts your workers. On Forge, you're working with the retained releases yourself. When a deploy goes sideways in front of users, the gap between "click" and "figure it out under pressure" is exactly when it matters most. A rollback path you've never rehearsed isn't really a rollback path, and defaults decide what gets rehearsed.

Monitoring measures different things. Forge's health checks answer "is my site responding, from three places in the world?" That's outside-in uptime monitoring, and it's useful. Deploynix's monitoring answers "is my server about to fall over?" with CPU, memory, and disk telemetry plus alert thresholds. Ideally you want both kinds; neither product fully replaces a dedicated observability tool, and pretending otherwise would be marketing, not analysis.

The providers row is a philosophy, not a checklist. Both products connect to the major clouds and custom servers. The difference is direction of travel: Forge 2.0's flagship addition pulls hosting inward onto Laravel's infrastructure, while Deploynix deliberately has no hosting of its own, so its incentives stay aligned with you shopping for the cheapest, best-fit compute. Neither stance is wrong. They're bets on different futures.

For a wider comparison that includes Ploi, see our three-way honest comparison.

Who Should Stay on Forge

Being fair means saying this plainly: for a lot of people, Forge 2.0 removed the reasons to leave.

Stay if you're a solo developer who's already there. The old arguments for switching (in-place deploys, dated UI) are gone. Zero-downtime is default, the panel is fast, and per-user pricing doesn't bite a team of one. Migration has a cost, and for you the payoff is thin.

Stay if first-party matters to you. Forge is built by the people who build the framework, and the surrounding ecosystem is real: Laravel Cloud now offers managed application hosting from $5/month with scale-to-zero hibernation, and Forge slots into that product family. If you want one vendor accountable for your whole stack, from framework to host, that's a coherent position and Laravel is the only one who can sell it to you.

Stay if Laravel VPS fits your actual workload. Prototypes, demos, course projects, low-stakes client sites: the sub-10-second provisioning and the $6 entry tier are hard to beat for speed-to-running-app, and the lock-in concerns above genuinely don't matter for throwaway infrastructure.

Stay if you're mid-launch or mid-crisis. A deployment platform migration is one of those tasks that's easy in a quiet week and reckless in a busy one. If you're weeks from a launch, onboarding a big client, or firefighting production issues, the switching math doesn't change but the timing does. Bookmark the comparison, ship the thing, and revisit when the calendar clears. Forge 2.0 is a perfectly good place to be standing while you decide.

Who Should Reconsider

Reconsider if you're a team paying per seat. Add up your Organizations bill and compare it against a flat $12 to $39/month with unlimited team members. For agencies and product teams of three or more, this is usually the largest single line-item difference, and it grows with every hire.

Reconsider if your strategy is cheap compute. If your cost model is built on Hetzner's €7.99 4 GB instances and €1.19/TB egress, you want a panel whose incentives point the same direction as yours: toward your own provider account, resized and shopped at will. A management layer that also sells hosting will always, structurally, nudge you toward its hosting.

Reconsider if exit-cost bothers you. If reading the Laravel VPS section made you slightly uncomfortable, trust that instinct. Owning the provider account means any panel, Deploynix included, remains a removable layer rather than a landlord.

If you land in this second group, the switch is more mechanical than you'd expect: server provisioning, site setup, SSL, queues, and cron all map one-to-one. We've documented the whole process, including how to cut over DNS without downtime, in our Forge-to-Deploynix migration guide.

Where This Leaves You

Nine months later, the honest scorecard on Forge 2.0 reads like this. The engineering was real: zero-downtime by default fixed the product's oldest flaw, the redesign made daily use faster, and Laravel VPS built the smoothest first-deploy experience in the ecosystem. Anyone telling you Forge 2.0 was just a coat of paint hasn't used it.

But the strategic direction shipped alongside the engineering. Laravel VPS moves hosting onto Laravel's infrastructure and pricing, and Organizations put a per-person meter on team access. Both are defensible business decisions, and both shift cost and control away from you in ways the launch posts didn't dwell on.

So the Forge-alternative decision in mid-2026 is no longer "Forge is dated, look elsewhere." It's a cleaner question: do you want convenience that deepens your dependence on one vendor, or ownership that keeps every layer of your stack replaceable? If it's the former, Forge 2.0 is the best it has ever been, and you should use it without apology. If it's the latter, that's the exact position Deploynix was built for: your servers, your provider account, flat pricing, and your whole team in the room. The pricing page and the migration guide are there when you've decided which kind of team you are.

Laravel Cloud's $5 Plan vs a $5 VPS: The Real Cost Math

Deploynix — Tue, 14 Jul 2026 10:39:46 +0000

In June 2026, Laravel Cloud restructured its pricing around three tiers: a $5/month Starter, a $20/month Growth, and a $200/month Business plan. The headline feature is scale-to-zero hibernation: idle apps go to sleep, wake in under 500ms, and you can set spending caps so a traffic spike never turns into a four-figure invoice.

On paper, that reads like the end of the $5 VPS. Why manage a Linux box when a first-party platform runs your app for the same monthly price?

Because "$5/month" means two very different things on a usage-metered platform and on a flat-rate server. One is a floor. The other is the bill. This post does the total-cost-of-ownership math for a real Laravel app, the kind with a web process, a queue worker, a scheduler, a MySQL database, and a Valkey cache, and shows where each option genuinely wins. Laravel Cloud is a good product. It's also not the cheapest way to run every Laravel app, and the difference is bigger than most comparisons admit.

What $5 Actually Buys on Laravel Cloud

The $5 Starter tier is an entry point into a usage-metered platform, not a fixed allocation of hardware. You pay the base fee, and then compute, database, and data transfer are billed by what you consume. The June update added the two features that make the low tier viable: hibernation, so an idle app consumes nothing, and spending limits, so consumption has a ceiling you choose.

For the right app, this is a genuinely great deal. A portfolio site, a demo you show clients twice a month, a side project with three users: these apps are idle almost all the time, and on a flat-rate VPS you're paying for that idle time. Scale-to-zero means you mostly pay the $5 base and very little else. The sub-500ms wake is fast enough that visitors won't notice the app was asleep.

But "a real Laravel app" is rarely just a web process. Here's where the model starts to strain.

Queue workers don't hibernate well

Hibernation saves money when nothing is running. A queue worker's entire job is to run continuously. If you use Laravel Horizon, there's a master process supervising worker processes that poll Redis constantly, that's how Horizon works by design. A process that polls every second can never scale to zero, so that compute is metered around the clock. You've reintroduced the always-on cost you thought hibernation eliminated, except now it's usage-billed instead of flat.

The alternative is letting the queue sleep and accepting that jobs wait until something wakes the app. For a contact-form email, fine. For a SaaS where a user expects their export or their webhook processed within seconds, not fine.

The scheduler is a wake-up call, literally

Laravel's scheduler assumes a cron tick every minute. Every tick is a wake event for a hibernated app. An app that "sleeps when idle" but runs schedule:run every 60 seconds is never meaningfully idle. You can space out your scheduled tasks, but most production apps accumulate them: queue pruning, backup triggers, subscription checks, cache warming. The scheduler quietly converts a scale-to-zero app back into an always-on one.

The database never sleeps at all

Your database instance and your cache store are separate metered line items, and unlike the web tier, your data can't hibernate away. Whatever the per-hour or per-GB rate, it accrues 24/7. On the $5 tier, the database is routinely the largest number on the invoice, and it's the one the marketing page talks about least.

None of this is a criticism of the engineering. It's the inherent shape of usage-metered platforms: the pricing is brilliant for idle workloads and mediocre for steady ones. The question is which one your app is.

What $5 to $9 Buys on a VPS

A Hetzner CX22 costs about $5/month and gives you 2 vCPUs, 4 GB of RAM, and 40 GB of NVMe storage. Not credits, not compute units: a whole virtual machine that's yours around the clock. Stepping up, Hetzner's CPX-class 4 GB instance runs about €7.99/month, where DigitalOcean charges $24/month for a comparable 4 GB droplet, so even among VPS providers the spread is wide.

On that one box you run everything the small SaaS needs:

Nginx and PHP-FPM serving the app
Horizon supervising your queue workers, 24/7, at no marginal cost
The scheduler ticking every minute, at no marginal cost
MySQL with several gigabytes of RAM for its buffer pool
Valkey for cache and queues

That last point is the structural difference. On a flat-rate server, an always-on queue worker costs you nothing extra. The CPU cycles are already paid for. The very workloads that break the scale-to-zero pricing model, workers, schedulers, databases, are exactly the workloads a VPS absorbs for free.

And 4 GB of RAM goes further than people assume. We've load-tested Laravel on a $5 server and a tuned single box comfortably handles the traffic of most small SaaS products, tens of thousands of requests a day, without breathing hard.

Egress is the sleeper line item. Hetzner charges roughly €1.19/TB for overage beyond its generous included transfer, DigitalOcean around $10/TB, and AWS-style platforms roughly $90/TB. If your app serves file downloads, images, or API responses at any volume, metered egress on a hyperscaler-backed PaaS can quietly exceed your entire VPS bill.

The Hidden Line Items, in Both Directions

An honest comparison has to count the costs each side's fans prefer to skip.

What PaaS invoices actually accumulate

Database and cache. Metered separately, billed continuously, and sized by usage you can't always predict. This is usually the gap between the $5 headline and the real monthly total.
Always-on compute. Queue workers and frequent schedulers, as covered above.
Egress. Metered per GB, at hyperscaler-adjacent rates rather than Hetzner rates.
Extra environments. A staging environment is a second app with its own compute and its own database. On a VPS, staging is a second site on the same box, and it costs nothing.
The cap trade-off. Spending limits are a real improvement, and credit where due, Laravel shipped them. But a cap protects your bill, not your workload: the ceiling you set is the point where you've chosen cost over capacity. A flat-rate server never presents that choice mid-month.

What the VPS actually costs you

Fair is fair, so here's the other side of the ledger.

Your time. Someone has to provision the box, configure Nginx and PHP-FPM, set up deployments, and keep it all running. Done by hand, the initial setup is an afternoon and the ongoing care is a couple of hours a month. Your hourly rate makes that real money.
Security patching. An unpatched VPS is your liability, not a vendor's, and the secrets living on it raise the stakes. The May 2026 Laravel-Lang supply-chain attack pushed 700+ compromised package versions delivering a credential stealer that hunted cloud keys, CI/CD tokens, and SSH keys. A Composer attack like that hits PaaS apps just as hard; the difference is that a self-managed box concentrates more for a stealer to grab, .env files, deploy keys, and server SSH keys included. The baseline is well understood, but it still has to be done.
Backups and monitoring. A PaaS bundles these. On a raw VPS you set up both or you gamble.
No built-in autoscaling. If your traffic 20x's overnight, a single VPS falls over. For most small apps this risk is theoretical; for a few it's the whole reason PaaS exists.

The honest summary: PaaS converts your time into a metered bill, and a VPS converts a metered bill into your time. A management platform (Forge, Ploi, Deploynix) is the middle path, buying back most of the time for a flat fee. Forge's 2.0 relaunch even added Laravel VPS instances from $6/month with sub-10-second provisioning, which tells you Laravel itself sees the flat-rate server as very much alive.

Three Scenarios, Worked Through

Abstract pricing arguments are useless, so here are three real shapes of Laravel app and where the math lands for each.

Scenario 1: A hobby project with spiky traffic

A side project that gets featured on a newsletter once a quarter and is otherwise near-dead. Traffic: bursts of a few thousand visits, then weeks of silence. No queue urgency, a couple of scheduled tasks a day, a tiny database.

Laravel Cloud wins, and it isn't close. This is the exact workload scale-to-zero was built for. The app hibernates through the quiet weeks, wakes in under 500ms when the newsletter hits, and the spending cap means a viral moment can't hurt you. A VPS would work fine too, but you'd be paying for a server that idles almost all the time and patching it for an app three people use. Take the $5 tier and move on with your life.

Scenario 2: A steady-traffic SaaS with queues

A small B2B SaaS: a few hundred daily active users, Horizon processing jobs all day (emails, report generation, third-party syncs), a scheduler with a dozen tasks, a 2 GB MySQL database, Valkey for cache and sessions. Traffic is boringly consistent, weekdays 8 to 6.

The VPS wins on cost, clearly. This app is never idle, so hibernation saves nothing. The worker meters 24/7, the database meters 24/7, the scheduler wakes everything every minute anyway. Every attribute that makes usage-based pricing attractive is absent, and every attribute that makes it expensive is present. Meanwhile a single $5 to $10 Hetzner box runs the entire stack at a fixed price, with the always-on worker and database costing literally nothing extra. This is the workload where flat-rate infrastructure is at its strongest, and it happens to describe most bootstrapped SaaS products.

There's a reason the broader industry is rediscovering this. A Barclays CIO survey found 86% of CIOs plan to move some workloads back from public cloud, up from 43% in 2020, and 37signals reports saving around $2M per year, roughly $10M over five years, after leaving AWS. Steady workloads on metered infrastructure is the pattern everyone eventually notices on the invoice.

Scenario 3: An agency with many client apps

Fifteen client sites: marketing sites, a few small apps, two or three with queues. Each client billed monthly for hosting and maintenance.

VPS plus a management platform wins, structurally. On a per-app-priced PaaS, fifteen apps means fifteen base fees plus fifteen sets of metered databases before you've written a line of code, and the invoice scales linearly with every client you sign. On flat-rate servers, several small client sites share one box, bigger clients get their own, and your management platform gives every project the same deploy pipeline, SSL automation, and monitoring. Your hosting margin improves with every client instead of staying flat. This is also where team seats matter: agencies have juniors, contractors, and project managers who all need dashboard access, and per-seat pricing punishes exactly that.

The 12-Month Table: A Typical Small SaaS

Here's Scenario 2 priced over a year. The VPS column uses published flat rates. The Laravel Cloud column is honest about what's knowable: the base fee is fixed and public, while compute, database, and transfer are usage-metered and vary by app, so we mark them as such rather than inventing numbers.

Line item

Laravel Cloud

Hetzner VPS + Deploynix

Base plan

$5–20/mo ($60–240/yr)

Server

included (web tier)

Hetzner CX22, ~$5/mo ($60/yr)

Queue worker (24/7)

metered, cannot hibernate

included on the same box

Scheduler

metered wake events

included (cron)

MySQL/Postgres

metered, billed continuously

included on the same box

Valkey/Redis cache

metered

included on the same box

Staging environment

second app + second database, metered

second site on same box, $0

Egress

metered per GB

~€1.19/TB overage, generous included quota

Management platform

n/a (built in)

Deploynix Starter, $12/mo ($144/yr)

Backups

included

pennies per month to S3-compatible storage

SSL, deploys, monitoring

included

included in Deploynix

12-month total

$60–240 floor + metered usage

~$205 flat, all-in

Read that last row carefully. The VPS column is a ceiling: roughly $205 for the year, known in advance, regardless of how busy your queue gets. The Cloud column is a floor: $60 to $240 before any metered usage, and for an always-on app with a database, the metered usage is the bulk of the bill. If you'd rather skip the platform fee entirely and manage the box by hand, the year costs ~$61 plus your time, and only you know what your time is worth.

For a hibernating hobby app, the same table inverts: the Cloud column collapses toward its $60 floor and the VPS column becomes money spent on idle silicon. The table doesn't have a winner. Your traffic pattern picks one.

Where Deploynix Fits

Deploynix exists for the middle path in that table: you own flat-rate servers, and a flat-rate platform removes the sysadmin work that makes people flee to PaaS in the first place.

The Starter plan is $12/month, flat, with no usage metering of any kind. It provisions servers on Hetzner, DigitalOcean, Vultr, Linode, AWS, or any VPS you can SSH into, then handles the parts you'd otherwise do by hand: zero-downtime deployments with one-click rollback, free Let's Encrypt SSL, MySQL provisioning with automated backups, cron, and queue workers and Horizon under Supervisor. Team seats are included on every tier, including Free, so the agency in Scenario 3 doesn't pay per collaborator. The Hetzner-plus-Deploynix combination is the specific pairing we'd recommend for Scenario 2: the cheapest solid hardware in the industry under a fixed management fee.

That's the extent of the pitch. The point of this post is the math, and the math doesn't always favor us either: for Scenario 1, we'd genuinely tell you to use Laravel Cloud.

A Decision Framework

Skip the brand loyalty and answer four questions about your actual app:

Is your app idle more than half the time? If yes, scale-to-zero is real money saved and Laravel Cloud's $5 tier is probably your cheapest option. If your app serves steady traffic, hibernation saves you nothing and you're paying metered rates for always-on work.
Do queues need to process within seconds, around the clock? An always-on Horizon worker is free marginal capacity on a VPS and a continuous metered charge on a PaaS. Latency-tolerant queues weaken this; busy real-time queues make it decisive.
How big is the database, and does it grow? Your data can't hibernate. A continuously metered database is the line item that most often drags a "$5" PaaS bill into serious territory, while on a VPS it's RAM you already own.
How many apps are you running? One app: either model works. Ten apps: per-app base fees and per-app databases stack up fast, and shared flat-rate servers win on structure, not just price.

Rough scoring: mostly-idle single app, take Laravel Cloud and enjoy it. Steady SaaS with queues, take a VPS. Many apps or client work, take VPSes plus a management platform and protect your margins.

The Bottom Line

Laravel Cloud's $5 tier is a real product improvement, not a gimmick. Scale-to-zero with sub-500ms wakes and spending caps solves the exact problem that made usage-based platforms scary for hobbyists, and for spiky, mostly-idle apps it's the best deal in the Laravel ecosystem right now.

But the $5 is a floor, and floors are only meaningful for apps that stay near them. The moment your Laravel app looks like production, an always-on worker, a scheduler, a growing database, a cache, the metered model charges you for every hour of that steadiness, while a $5 Hetzner box absorbs all of it at a fixed price. Over 12 months, a typical small SaaS runs about $205 flat on a VPS with Deploynix managing it, versus a $60 to $240 floor plus open-ended usage on the platform side.

Price the app you actually have, not the demo. If it sleeps, rent the nap. If it works for a living, buy it a server.

Self-Hosted PaaS Showdown 2026: Coolify vs Dokploy vs CapRover vs Deploynix

Deploynix — Sun, 21 Jun 2026 23:58:58 +0000

Self-hosted PaaS tools exploded in 2026 because cloud bills did. With 86% of CIOs in Barclays' late-2024 technology survey planning to repatriate at least some public-cloud workloads — the highest figure on record, per Puppet's analysis — developers are racing to recreate the Heroku experience on infrastructure they control. Three open-source projects lead that movement: Coolify (~57,300 GitHub stars), Dokploy (~35,000 stars), and CapRover (~15,100 stars), all verified on GitHub as of June 22, 2026. This guide compares them head-to-head, then adds a fourth option built on a different model entirely — Deploynix, a Laravel-first managed control plane for your own servers.

Key takeaways

Coolify is the most feature-complete all-rounder: 280+ one-click services, Docker Compose, native multi-server, and a free self-hosted tier under Apache-2.0.
Dokploy is the fast-rising lightweight challenger — Docker Swarm + Traefik, clean UI, native Compose — but still pre-1.0 (v0.29.x).
CapRover is the battle-tested veteran (since 2017): rock-stable, simple, but a dated UI, slower release cadence, and weaker Compose support.
Deploynix is the odd one out by design: a managed SaaS that provisions native, non-Docker servers on your own DigitalOcean/Hetzner/Vultr/Linode/AWS account — purpose-built for Laravel and PHP, a Forge-style alternative.
The real decision isn't "which panel" — it's "do I want to run the control plane myself (Coolify/Dokploy/CapRover) or have it managed (Deploynix)?"

The quick verdict: which self-hosted PaaS is right for you?

For most teams in 2026, Coolify is the safest all-purpose pick, Dokploy is best if you want a lean Swarm-native panel, CapRover suits people who value stability over features, and Deploynix fits Laravel/PHP teams who'd rather not babysit Docker or the control plane at all. All three open-source tools are free to self-host under Apache-2.0; Deploynix is a paid managed service that runs on infrastructure you own and pay your cloud provider for directly.

Tool

Model

Best for

Watch out for

Coolify

OSS self-hosted panel

Feature-rich, polyglot, production all-rounder

You maintain the panel and the server

Dokploy

OSS self-hosted panel

Lightweight, modern, Swarm-native clustering

Still pre-1.0; younger ecosystem

CapRover

OSS self-hosted panel

Simplicity and long-term stability

Dated UI, slow cadence, limited Compose

Deploynix

Managed SaaS, your VPS

Laravel/PHP teams wanting native, zero-maintenance hosting

Subscription cost; PHP/Laravel focus

Why self-hosted PaaS is booming in 2026

The self-hosted PaaS surge is fundamentally a cost story. Cloud repatriation hit record interest in 2024–2026, with cost cited as the number-one driver in most surveys and high-profile exits making headlines. 37signals (makers of Basecamp and HEY) reported saving roughly $2 million per year after leaving AWS, a figure its co-founder DHH has repeated publicly and that became a rallying cry for the movement. When a hobby project's $0 Heroku dyno turns into a $25–$100/month bill, a $5 VPS plus a free control panel looks irresistible.

Developer mindshare followed the money. Coolify and Dokploy have become the two breakout repositories in this niche, and search demand for terms like "Coolify vs CapRover," "CapRover alternative," and "Dokploy vs Coolify 2026" has climbed accordingly. The pattern is consistent: teams want the Heroku/Vercel developer experience — git push, automatic SSL, instant databases — without the per-seat, per-build, egress-metered Heroku/Vercel bill.

It's worth keeping perspective: repatriation is selective, not wholesale. IDC data cited in the same roundups suggests only about 8% of organizations move entire workloads off the public cloud. The dominant pattern is hybrid — keep some things managed, self-host the rest. That's exactly the gap these four tools fill.

The four contenders at a glance

Here's the data-driven snapshot. Star counts come straight from each project's GitHub repository on June 22, 2026; pricing is from each vendor's official pricing page on the same date. Self-hosting every open-source option is free — you pay only for the server it runs on.

Metric

Coolify

Dokploy

CapRover

Deploynix

GitHub stars (Jun 2026)

~57,300

~35,000

~15,100

n/a (closed SaaS)

First released

2021

2024

2017

2026

Latest version

v4.x (stable)

v0.29.x (pre-1.0)

v1.14.2

Continuous SaaS

License

Apache-2.0

Proprietary (SaaS)

Built with

PHP / Laravel

TypeScript

Node.js / TypeScript

PHP / Laravel

Container model

Docker + Compose

Docker Swarm + Traefik

Docker Swarm + Nginx

Native (no Docker required)

Multi-server

Yes (native)

Yes (Swarm cluster)

Yes (manage many VPS)

Managed cloud option

$5/mo (2 servers)

$4.50/server (Hobby)

None

Free plan; Starter $12/mo

Self-host cost

Free

n/a (control plane hosted)

Coolify: the feature-rich front-runner

Coolify is the category leader by adoption and breadth, sitting at roughly 57,300 GitHub stars as of June 2026 (coollabsio/coolify). Built in PHP/Laravel and licensed Apache-2.0, it positions itself as an open-source replacement for Heroku, Netlify, and Vercel combined — and largely delivers, with git-based deployments, automatic Let's Encrypt SSL, managed databases, and a library the project advertises as 280+ one-click services.

What Coolify does well

Breadth of features. Dockerfile and Nixpacks builds, Docker Compose, managed databases (PostgreSQL, MySQL, MariaDB, MongoDB, Redis), backups, monitoring, and native multi-server orchestration from a single dashboard.
Genuinely free self-hosting. The full feature set is free forever when you host it yourself — no artificial limits, no "open core" lockout of essentials.
Active, independent development. Founder Andras Bacsai went full-time on Coolify and has publicly declined VC funding, sustaining the project through GitHub Sponsors, Open Collective, and the optional Coolify Cloud. Development is moving toward a v5 focused on core scalability.
Optional managed plane. Coolify Cloud starts at $5/month connecting up to two of your servers, with additional servers at +$3/month — useful if you want Coolify to run the control plane while your apps stay on your own machines.

Where Coolify costs you

Power has a price: Coolify's surface area is large, and a self-hosted control plane is still your control plane. You patch it, you recover it when an upgrade misbehaves, and you own the blast radius if the single server hosting both Coolify and your apps goes down. Teams that want "set it and forget it" sometimes find Coolify's breadth is more than they need.

Dokploy: the lightweight challenger

Dokploy is the fastest-rising name in the space, climbing to about 35,000 GitHub stars (Dokploy/dokploy) within roughly two years of its 2024 launch by Mauricio Siu. Written in TypeScript and built on Docker Swarm with Traefik for routing and load balancing, it markets itself as an open-source alternative to Vercel, Netlify, and Heroku with a deliberately clean, modern interface.

What Dokploy does well

Native multi-node clustering. Because it's Swarm-native, scaling from one server to a cluster is a first-class concept, not an afterthought.
Full Docker Compose support and multiple build methods (Nixpacks, Dockerfile, buildpacks), plus managed PostgreSQL, MySQL, MariaDB, MongoDB, and Redis with automated backups to external storage.
Clean UX and templates. One-click templates for popular open-source apps and per-resource CPU/memory/network monitoring make it approachable.
Flexible cloud pricing. Dokploy Cloud offers a Hobby plan at $4.50/month per server and a Startup plan from $15/month for three servers, with enterprise/self-hosted options above that.

Where Dokploy costs you

Dokploy is still on a 0.x version line (v0.29.x as of mid-2026). It's stable enough that many run it in production, but "pre-1.0" means APIs and behaviors can still shift, and its ecosystem of guides and third-party integrations is younger than Coolify's or CapRover's. In January 2026 the project also updated its licensing, keeping the core Apache-2.0 while introducing a separate source-available license for future paid features — worth reading if license purity matters to you.

CapRover: the battle-tested veteran

CapRover is the elder statesman, in continuous development since 2017 and sitting at roughly 15,100 GitHub stars (caprover/caprover). It's built on Docker Swarm with Nginx as the reverse proxy, ships automatic Let's Encrypt SSL and NetData monitoring, and is famous for a one-line install and 100M+ Docker Hub pulls. Its latest release, v1.14.2, landed in May 2026 as a security hotfix — proof it's still maintained.

What CapRover does well

Maturity and stability. Eight-plus years in production make it a known quantity. Maintainer Kasra Bigdeli deliberately avoids niche features to keep the maintenance burden low and the platform dependable.
Simplicity. A straightforward web GUI and CLI, one-click apps and databases, and a simple captain-definition file for deployments. In-place upgrades are painless.
Swarm clustering. You can add worker nodes through the UI for horizontal scaling (a Docker registry is required for multi-node setups).

Where CapRover costs you

CapRover lands last on modernity in nearly every 2026 comparison. The UI feels dated and is occasionally buggy; the release cadence is slow (a handful of releases per year); Docker Compose support is limited to a custom format rather than full Compose; and there's no preview-deployment or multi-environment workflow. It's also effectively a solo-maintained project, and there is no official managed cloud — CapRover is self-host only. If you want cutting-edge features, CapRover will frustrate you; if you want something that just keeps working, that conservatism is the point.

Deploynix: the Laravel-first managed option

Deploynix is intentionally a different animal. Rather than an open-source panel you install and maintain, it's a managed SaaS control plane that provisions and operates native servers on cloud accounts you already own — DigitalOcean, Hetzner, Vultr, Linode, AWS, or any custom Ubuntu box over SSH. There's no Docker layer between your code and the metal: it installs Nginx, PHP 8.1–8.4, MySQL/MariaDB/PostgreSQL, Redis/Valkey, Node, Supervisor, and Certbot directly, the way a senior Laravel ops engineer would. In that sense it's less a Coolify competitor and more a Laravel Forge alternative.

What Deploynix does well

Zero infrastructure to babysit. The control plane is hosted and maintained for you. You never patch a panel or recover a crashed dashboard — you connect a provider and deploy.
Native, not containerized. Apps run on native PHP-FPM and Nginx, which removes container overhead and matches how most production Laravel apps actually run. Provisioning a ready server takes about three minutes.
True zero-downtime deploys. Each release lands in its own directory; once the build succeeds and health checks pass, a symlink switches atomically. If anything fails, the previous version stays live, and you can roll back instantly.
Laravel-aware management. First-class handling of Laravel Horizon, queues, scheduled tasks, daemons, SSL, database management, and automated backups — with SSH keys and environment variables encrypted at rest.
You own the infrastructure. Servers live in your cloud account and you pay the provider directly, so there's no markup on compute and no lock-in to someone else's hardware.

Where Deploynix costs you

Deploynix is opinionated: it's built for Laravel and PHP, so polyglot teams deploying Go, Rust, or arbitrary Docker images are better served by Coolify or Dokploy. And unlike the open-source trio, the control plane itself is a paid product — there's a free plan, with the Starter tier at $12/month (cloud-provider fees are separate, as they are for everyone). You're trading the "free but you run it" model for "paid but maintained for you."

The differences that actually matter

Feature checklists blur together; three decisions don't.

Docker panel vs native provisioning

Coolify, Dokploy, and CapRover all containerize your apps — great for polyglot stacks and isolation, but it adds a layer to understand and debug. Deploynix provisions native services with no Docker requirement, which Laravel/PHP teams often prefer for performance and operational simplicity. If your stack is heterogeneous, containers win; if it's PHP-centric, native is leaner.

Self-managed control plane vs managed SaaS

This is the core fork in the road. With the open-source three, the control panel runs on your server — usually the same server as your apps in small setups — so a bad panel upgrade or a host failure can take down both. With Deploynix, the control plane is SaaS: if it has an issue, your already-deployed apps keep serving traffic because they run on your independent VPS. You pay for that separation with a subscription.

Pricing model

"Free" open-source tools still cost you a server plus your time to run and secure the panel. Paid managed planes (Coolify Cloud at $5/mo, Dokploy Cloud from $4.50/server, Deploynix from $12/mo) trade dollars for that time. The honest comparison isn't free-vs-paid; it's "how much is an hour of your ops time worth?" For a solo developer with one side project, free self-hosting wins easily. For a team shipping client work, a managed plane often pays for itself in a single avoided outage.

Which self-hosted PaaS should you choose?

Match the tool to the situation rather than chasing star counts:

Choose Coolify if you want the most capable free, self-hosted panel for a mixed stack and don't mind maintaining it.
Choose Dokploy if you want a modern, lightweight, Swarm-native panel and are comfortable on a pre-1.0 (but rapidly maturing) project.
Choose CapRover if you value stability and simplicity over features and want a tool that has quietly worked for years.
Choose Deploynix if you run Laravel or PHP, want native zero-downtime deploys on your own cloud account, and would rather pay a little than maintain a control panel at all.

Many teams end up using two: an open-source panel for experiments and a managed plane for the apps that pay the bills. There's no wrong answer — only the wrong fit for your stack and your tolerance for ops work.

What about Dokku, Kubernetes, and other alternatives?

The four tools above dominate the conversation, but they aren't the only options — and knowing the neighbors clarifies the trade-offs. Dokku is the original lightweight, single-server, git-push PaaS; it's powerful and free but CLI-first with no real web UI, so it appeals to terminal purists rather than teams who want a dashboard. Kubernetes (via k3s, or managed control planes) is the heavyweight answer: maximal flexibility and scale, but operational complexity that's overkill for the vast majority of apps these PaaS tools target. And fully managed platforms like Render and Railway recreate the Heroku experience without any self-hosting — convenient, but they put you back on someone else's metered infrastructure, which is the exact bill most people are trying to escape.

The honest framing: Coolify, Dokploy, and CapRover sit in the sweet spot between Dokku's bare-bones minimalism and Kubernetes' complexity, while Deploynix sits between the open-source panels and the fully managed platforms — managed control plane, self-owned servers. Where you land depends on how much control, and how much maintenance, you actually want.

Frequently asked questions

Is Coolify or Dokploy better in 2026?

Coolify is more feature-complete and has a larger community (~57,300 vs ~35,000 GitHub stars in June 2026), making it the safer default. Dokploy is lighter, has a cleaner UI, and is Docker Swarm-native, which some prefer for clustering — but it's still pre-1.0. Choose Coolify for breadth, Dokploy for a lean, modern footprint.

Is CapRover still worth using in 2026?

Yes, if stability matters more than features. CapRover has been maintained since 2017, shipped a security release (v1.14.2) in May 2026, and remains rock-solid. Its trade-offs are a dated UI, slower release pace, and limited Docker Compose support compared with Coolify and Dokploy.

Are these self-hosted PaaS tools really free?

Coolify, Dokploy, and CapRover are all free to self-host under Apache-2.0 — you pay only for the server they run on. Each also offers (or, for CapRover, doesn't) an optional paid managed cloud. Deploynix is a paid managed service, with a free plan and a Starter tier at $12/month, where you still bring and pay for your own cloud servers.

How is Deploynix different from Coolify, Dokploy, and CapRover?

Deploynix is a managed SaaS control plane, not an open-source panel you install. It provisions native (non-Docker) servers on your own DigitalOcean, Hetzner, Vultr, Linode, or AWS account and is purpose-built for Laravel and PHP — closer to Laravel Forge than to the Docker-based trio. You get zero-downtime deploys and managed Horizon/queues/SSL without maintaining the control plane yourself.

Can I move off Heroku or Vercel to these tools?

Yes — that's exactly what they're built for. All four recreate the core Heroku/Vercel experience (git deploys, automatic SSL, instant databases) on infrastructure you control, typically at a fraction of the cost. Pick a Docker panel (Coolify/Dokploy/CapRover) for polyglot apps, or Deploynix if your workload is Laravel/PHP and you want it managed.

Laravel Telescope vs Pulse vs Nightwatch (2026): Which Should You Use?

Deploynix — Thu, 18 Jun 2026 17:23:10 +0000

Laravel now ships three first-party tools for looking inside your app — and they're easy to confuse. Telescope, Pulse, and Nightwatch all "monitor" something, but they solve different problems, run in different places, and only one of them costs money. Picking the wrong one means either flying blind in production or paying for observability you don't need yet.

Here's the short version: they're complementary, not competitors. Telescope is for local debugging, Pulse is a self-hosted production dashboard, and Nightwatch is hosted, full-fidelity production observability. Most serious apps end up running Telescope locally plus either Pulse or Nightwatch (or both) in production. This guide breaks down exactly what each does, what it costs, and how to choose.

Key takeaways- Telescope = local debugging. Self-hosted, free (MIT), stores every request in your app database. Not built for production. - Pulse = self-hosted production dashboard. Free (MIT), shows aggregated metrics (slow queries, jobs, exceptions, server load). - Nightwatch = hosted SaaS observability. Keeps every event with tracing, alerts, and an exception-to-issue workflow. Free tier (300k events/mo), then $20–$300+/mo. - They stack: debug locally with Telescope, watch production with Pulse and/or Nightwatch. - Nightwatch pricing changed once since its June 2025 launch — always confirm current numbers on the official pricing page.

What's the difference between Telescope, Pulse, and Nightwatch?

The cleanest way to understand the three is on two axes: where they run (local vs production) and what they record (every individual event vs aggregated metrics).

Where it shines

Data model

Hosting

Cost

Telescope

Local development

Every event, full single-request detail

Self-hosted (your app DB)

Free (MIT)

Pulse

Production

Pre-aggregated metrics ("buckets")

Self-hosted (your DB)

Free (MIT)

Nightwatch

Production

Every event, retained in the cloud

Hosted SaaS

Free tier, then paid

Laravel's own framing says it best. From the Nightwatch announcement: "Telescope helps you debug locally. Pulse shows you aggregated metrics. Nightwatch gives you the full story of what's happening in production" (Laravel Blog, 2025). That single sentence is the decision tree. The rest of this article fills in the detail.

What is Laravel Telescope and when should you use it?

Telescope is the official debugging companion for your local Laravel environment. It records every request, query, job, exception, mail, notification, cache operation, scheduled task, and dump — then lets you drill into any single one with full context. The docs describe it as "a wonderful companion to your local Laravel development environment" (Laravel Docs).

Telescope stores its entries in your own application database, in a telescope_entries table created by its migrations. That's exactly why it's a local tool: on a busy production app, that table fills up fast. The docs are blunt about the trade-offs — you should schedule telescope:prune daily (it clears entries older than 24 hours by default), and the Nightwatch comparison page states plainly that Telescope is "not recommended for production environments."

You can run it in production behind an authorization gate, and some teams do for short-lived deep debugging. But its design intent is local. By default the dashboard is only reachable when APP_ENV is local; expose it elsewhere and you must add a gate, or the dashboard becomes publicly accessible.

It is very much alive — the latest release is v5.20.0 from April 2026, and it's MIT-licensed and free. Telescope's role just narrowed once Pulse and Nightwatch arrived: it owns the local-debugging niche, and the other two cover production.

Use Telescope when: you're developing locally and need to see exactly what a single request did — every query, the bindings, the timing, the exception stack. It's the fastest way to answer "why did this request behave that way?"

What is Laravel Pulse and how is it different from Telescope?

Pulse is a lightweight, self-hosted production dashboard that shows aggregated performance and usage at a glance. Where Telescope keeps every individual event, Pulse rolls data into pre-computed buckets — averages, counts, maxes — so it stays cheap to run even under real traffic. The Pulse docs draw the line explicitly: "For in-depth debugging of individual events, check out Laravel Telescope" (Laravel Docs).

Out of the box, Pulse gives you cards for server health (CPU, memory, storage via pulse:check), top application usage, exceptions, queues, slow requests, slow jobs, slow queries, slow outgoing requests, and cache hit/miss rates. The default "slow" threshold is 1,000ms. The dashboard is a Livewire app served at /pulse, and like Telescope it's local-only by default — in production you add a viewPulse gate to control access.

The headline feature is that it "drops into an existing application without requiring any additional infrastructure." For low and medium traffic, it just writes to your existing database. As you scale, Pulse offers three levers to keep overhead down:

A dedicated database connection (PULSE_DB_CONNECTION) so monitoring writes don't touch your primary.
Redis ingest (run pulse:work) to buffer captures instead of writing synchronously.
Sampling — e.g. a sample rate of 0.1 records roughly 10% of events and scales the numbers up.

Pulse also fails silently if a capture errors, so a monitoring hiccup never takes down your app. It's MIT-licensed, free, and stable (latest release v1.7.4, June 2026). One requirement to note: Pulse's first-party storage needs MySQL, MariaDB, or PostgreSQL.

Use Pulse when: you want production signal — what's slow, what's erroring, which users are hammering the app — without a SaaS bill, without sending your data off-site, and without new infrastructure. It answers "is my app healthy right now, and where are the bottlenecks?"

What is Laravel Nightwatch and what does it cost?

Nightwatch is Laravel's hosted observability platform, purpose-built for production. Unlike Telescope and Pulse, it's a managed SaaS: you install a package and a token, and an agent running out of process ships events to Nightwatch's cloud. Because the agent is separate from your app, the overhead is tiny — the docs cite "typically less than 3ms per request" (Nightwatch FAQ).

The big difference from Pulse is fidelity. Nightwatch keeps every individual event — requests, outgoing requests, jobs, queries, mail, commands, cache operations, scheduled tasks, notifications, and exceptions — not just aggregates. On top of that raw stream it layers the things a team actually needs in production:

Timelines and tracing for individual requests, queries, and jobs (middleware → controller → cache → query timing).
An exception-to-issue workflow — exceptions become trackable issues with assignment, priority, and status.
Smart alerts routed by issue type.
Per-user impact so you can see who a problem actually affected.
Team collaboration, which is a core selling point over the single-developer dashboards.

Data is stored in US, EU, or Australia regions, with a default retention of 90 days (the usable "lookback" window varies by plan). Nightwatch was announced at Laracon AU in November 2024 and went generally available on June 16, 2025 (Laravel News; Laravel Blog).

Nightwatch pricing (as of June 2026)

Plan

Price/mo

Events/mo included

Lookback

Overage per 100k

Performance monitors

Free

300,000

14 days

$0.50

Pro

$20

7.5M

30 days

$0.35

Team

$60

30M

60 days

$0.35

Business

$300

180M

90 days

$0.20

Enterprise

Custom

—

All plans include unlimited seats. Beyond your quota, you can opt in to additional event ingestion billed per 100k up to a limit you set, invoiced at the end of the cycle.

One important caveat: these numbers have already changed once since launch (the free tier was 200k events and Pro was 5M at GA; both went up). So treat the table above as a June 2026 snapshot and confirm the live figures on the official pricing page before you budget.

Use Nightwatch when: you're running real production traffic, you need to debug incidents after they happen (not just see that they happened), and a team needs to triage exceptions together with alerting. It answers "what exactly happened in production, to whom, and who's fixing it?"

Telescope vs Pulse vs Nightwatch: which should you choose?

Choose by where you are in the app's life and what question you're trying to answer:

Just developing locally? Telescope. Free, deep, instant.
App is in production, you want free insight and to keep data in-house? Pulse. Self-hosted aggregates, no bill, no external egress.
Production app where incidents cost money and a team responds to them? Nightwatch. Per-event tracing, alerts, and an issue workflow are worth paying for.
All of the above? Run all three. That's the intended setup.

Pulse and Nightwatch are the only two that genuinely overlap, both living in the production-monitoring space. The trade-off is straightforward: Pulse is free, self-hosted, and aggregated; Nightwatch is paid, hosted, and keeps every event with tracing and team features. Plenty of teams run Pulse for the always-on free dashboard and Nightwatch for deep incident analysis — they answer different questions.

How this fits a Deploynix deployment

Both self-hosted options run on the server you deploy to — which makes them a natural fit when you ship a Laravel app with Deploynix. Telescope rides along in your repo for local work and stays out of production behind its environment gate. Pulse runs on your production server with zero extra infrastructure, writing to the MySQL, MariaDB, or PostgreSQL database your stack already includes; add the pulse:check command to your scheduler for server metrics and a viewPulse gate so only your team can reach /pulse.

Nightwatch needs nothing from your server beyond the package and token, since its agent ships data to the cloud. Whichever you choose, wire the setup (migrations, the telescope:prune schedule, the pulse:work worker if you use Redis ingest) into your deploy hooks so monitoring is provisioned the same way every release.

Frequently asked questions

Can I run Telescope, Pulse, and Nightwatch at the same time?

Yes — they're designed to coexist, and Laravel's own documentation cross-references them. The common pattern is Telescope for local debugging, then Pulse and/or Nightwatch in production. Pulse and Nightwatch overlap, so many teams pick one as primary, but there's no technical conflict in running all three.

Is Laravel Telescope safe to use in production?

It's not recommended. Telescope stores every event in your application database, which grows quickly under real traffic, and its dashboard is only gated to local by default. You can enable it in production behind an authorization gate for short-term debugging, but Pulse or Nightwatch are the tools built for ongoing production monitoring.

Are Telescope and Pulse really free?

Yes. Both are open-source under the MIT license and cost nothing to use — you host them yourself on your own infrastructure. Your only "cost" is the database storage and minimal overhead they add. Nightwatch is the paid option, though it offers a free tier of 300,000 events per month.

What counts as an "event" in Nightwatch billing?

Nightwatch counts requests, outgoing requests, jobs, queries, mail, commands, cache operations, scheduled tasks, notifications, and exceptions as billable events. A single web request can generate several events (the request plus its queries and cache hits), so estimate your volume before choosing a plan, and use sampling to control it.

Does Pulse or Nightwatch slow down my app?

Both are built for low overhead. Pulse writes asynchronously, fails silently on capture errors, and supports Redis ingest plus sampling to stay light under load. Nightwatch runs its agent out of process and reports typically under 3ms of added latency per request. For high-traffic apps, sampling in either tool keeps the cost and overhead down.

The bottom line

There's no single winner here — the right answer depends on the question you're asking. Telescope is your local microscope. Pulse is your free, self-hosted production dashboard for spotting bottlenecks. Nightwatch is your hosted, full-fidelity production observability platform for when incidents matter and a team responds to them. Start with Telescope while you build, add Pulse the day you go live, and reach for Nightwatch when production traffic and team workflows justify it.

Whatever you run, the easiest place to operate it is on infrastructure you control. Deploy your Laravel app with Deploynix and wire Telescope, Pulse, or Nightwatch into your release process from day one.

Sources (retrieved 2026-06-18): *Laravel Telescope docs, Laravel Pulse docs, Announcing Laravel Nightwatch — Laravel Blog, Nightwatch pricing, Nightwatch FAQs, Nightwatch vs Pulse, Laravel Nightwatch — Laravel News. Nightwatch pricing is a June 2026 snapshot and may change — verify on the official pricing page.*