DEV Community: Deploynix

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.*

Running Artisan Commands Across Tenants: A Guide to tenants:run (stancl/tenancy)

Deploynix — Wed, 17 Jun 2026 15:57:55 +0000

Running Artisan Commands Across Tenants: A Guide to tenants:run (stancl/tenancy)

If you run a multi-tenant Laravel app with stancl/tenancy, sooner or later you need to run an Artisan command for every tenant at once — migrate their databases, clear their caches, or regenerate a nightly report. The problem is that php artisan migrate only touches your central database. Each tenant gets left behind.

Plenty of developers go hunting for a tenants:artisan command to solve this. It doesn't exist. The command you actually want is tenants:run, and it wraps any registered Artisan command in each tenant's context. This guide walks through tenants:run, the dedicated tenant-aware commands, the programmatic API, and the gotchas that bite once you're past a handful of tenants.

Key takeaways- The generic command is tenants:run {commandname} — not tenants:artisan. It runs any registered Artisan command inside each tenant's context. - Scope it with --tenants=ID (repeat the flag for several). Omit it and the command hits every tenant. - Forward arguments and options with --argument="key=value" and --option="key=value". - For migrations, seeds, and rollbacks, prefer the dedicated commands: tenants:migrate, tenants:seed, tenants:rollback. - It runs tenants sequentially. Once you pass a few hundred, queue a job per tenant instead of looping in one process.

What does tenants:run actually do?

The tenants:run command iterates over your tenants and, for each one, initializes tenancy, runs the command you named, then ends tenancy before moving on. Initializing tenancy is what swaps the database connection, cache prefix, and filesystem paths over to that tenant via the package's bootstrappers — so the wrapped command behaves exactly as it would inside a tenant request.

Here's the signature straight from the package source:

php artisan tenants:run {commandname}
    {--tenants=*}
    {--argument=*}
    {--option=*}

The commandname is any Artisan command that's already registered in your app. The simplest case takes no extra arguments at all:

# Clear the cache for every tenant
php artisan tenants:run cache:clear

Behind the scenes this is the same loop you'd write by hand: initialize tenant, call cache:clear, end tenant, repeat. The package just hides the boilerplate and the context switching.

How do I target specific tenants?

Use the --tenants option, repeating it once per tenant ID. Leave it off and the command runs for all tenants — which is convenient for cache clears but genuinely dangerous for anything destructive.

# One tenant
php artisan tenants:run cache:clear --tenants=acme

# Several tenants (repeat the flag)
php artisan tenants:run cache:clear --tenants=acme --tenants=globex

# All tenants (the default when --tenants is omitted)
php artisan tenants:run cache:clear

Get into the habit of scoping with --tenants while testing. A mistyped command name fails loudly for one tenant; a destructive command run against the default "all" can ruin your evening.

How do I pass arguments and options to the command?

This is where tenants:run trips people up. You can't just append flags to the wrapped command, because the parser would assign them to tenants:run itself. Instead, you pass them through with --argument and --option, each as a key=value pair.

php artisan tenants:run email:send \
    --tenants=acme \
    --argument="subject=Welcome" \
    --option="queue=1"

So a command you'd normally invoke as php artisan email:send "Welcome" --queue becomes the form above. Repeat --argument and --option for each value you need to forward. It's verbose, but it keeps the wrapper's flags and the inner command's flags from colliding.

When should I use the dedicated commands instead?

stancl/tenancy ships purpose-built commands for the operations you run most. They handle the right defaults for you — tenant migrations, for example, look in database/migrations/tenant automatically rather than your central migrations folder. Reach for these before tenants:run:

Command

What it does

Key options

tenants:migrate

Runs tenant migrations against each tenant database

--tenants=*, --path, --force

tenants:migrate-fresh

Wipes and re-migrates a tenant database (destructive)

--tenants=*

tenants:rollback

Reverses the last migration batch per tenant

--tenants=*

tenants:seed

Seeds each tenant database

--tenants=*, --force

tenants:list

Lists all tenants with their IDs and domains

—

tenants:run

Runs any other registered Artisan command per tenant

--tenants=*, --argument=*, --option=*

# Migrate every tenant database (use --force in production)
php artisan tenants:migrate --force

# Roll back the last batch for two tenants
php artisan tenants:rollback --tenants=acme --tenants=globex

# Wipe and re-migrate a single tenant (destructive!)
php artisan tenants:migrate-fresh --tenants=acme

# Seed every tenant non-interactively
php artisan tenants:seed --force

One detail worth burning into memory: these commands run non-interactively when invoked from a deploy hook or scheduler, so any command that normally asks "are you sure?" in production needs --force. Without it, tenants:migrate will hang or abort.

Can I run tenant commands from my own code?

Yes, and it's often cleaner than shelling out to Artisan. Every tenant exposes a run() method that initializes its context, executes a closure, then restores the previous context. For batches, tenancy()->runForMultiple() does the same across a collection.

php

Valkey vs Redis: API Protocol, Data Format & Compatibility — The Technical Deep-Dive

Deploynix — Tue, 16 Jun 2026 20:22:15 +0000

When Redis changed its license on March 20, 2024, it triggered one of the fastest open-source forks in recent memory. Eight days later, on March 28, 2024, the Linux Foundation announced Valkey — a community fork built from the last BSD-licensed Redis release, version 7.2.4 (Valkey migration docs). Two years on, the practical question for engineers isn't political. It's technical: how compatible are these two systems really, at the wire, at the disk, and at the command level?

This deep-dive answers that. We'll look at the RESP protocol both projects speak, the RDB and AOF on-disk formats they read and write, the exact point where their command sets and file formats begin to diverge, and what the performance gap actually looks like once you anchor it to real hardware.

Key TakeawaysValkey forked from Redis OSS 7.2.4 and speaks an identical RESP2/RESP3 wire protocol — existing Redis clients connect unchanged (Valkey protocol spec, 2025).RDB and AOF files are fully interchangeable at the Redis 7.2 baseline, but RDB files written by Redis CE 7.4+ will not load into Valkey — the central forward-compatibility risk (Valkey, 2025).Valkey 8.0 reached roughly 1.2M requests/sec on AWS hardware — a ~230% jump over the 7.2 baseline on the same instance (Valkey, Sept 2024).Redis 8 (May 2025) folded the former Stack modules into core under a tri-license; Valkey keeps equivalents as separate BSD modules.

Why did Valkey fork from Redis in the first place?

In March 2024, Redis Ltd. relicensed Redis from the permissive BSD-3-Clause to a dual source-available model — RSALv2 and SSPLv1 — starting with the 7.4 release (Percona, March 20, 2024). Source-available is not open source: the SSPL in particular restricts offering the software as a managed service, which directly affected cloud providers and distributions.

The response was immediate. Within a week, AWS, Google Cloud, Oracle, and others rallied behind a Linux Foundation fork of the last BSD commit. That fork became Valkey, forked from Redis OSS 7.2.4 (Valkey migration docs). Major Linux distributions that ship default packages — Fedora, Debian, Ubuntu — moved toward Valkey because they cannot ship source-available software in their main repositories.

The story didn't end there. In November 2024, Redis creator Salvatore Sanfilippo (antirez) rejoined the company, and on May 1, 2025, Redis added AGPLv3 as a third license option starting with Redis 8 (Redis blog, May 1, 2025). Redis is once again available under a true open-source license — but by then Valkey had its own momentum, governance, and release cadence.

As of mid-2026, both projects are healthy and shipping. Valkey's current line is 9.1.x (9.1.0 landed May 2026) with an 8.1.x maintenance branch, while Redis is on its 8.x line (endoflife.date).

Milestone

Date

What changed

Redis relicense

Mar 20, 2024

BSD-3 → RSALv2 + SSPLv1 (from 7.4)

Valkey fork

Mar 28, 2024

Forked from Redis 7.2.4 under the Linux Foundation

antirez returns

Nov 2024

Redis creator rejoins Redis Ltd.

Redis 8 + AGPLv3

May 1, 2025

Tri-license: RSALv2 / SSPLv1 / AGPLv3

Are Valkey and Redis API-compatible at the protocol level?

Yes — at the wire-protocol level they are identical. Both Valkey and Redis speak the REdis Serialization Protocol (RESP), supporting both RESP2 and the newer RESP3 introduced in Redis 6 (Valkey protocol spec). Because Valkey began as a literal fork of the Redis 7.2.4 source tree, its protocol handler is the same code. A client has no way to tell, at the byte level, whether it is talking to one or the other during a standard handshake and command exchange.

This is the single most important compatibility fact for most teams. Your existing client library — redis-py, ioredis, Jedis, Lettuce, go-redis, StackExchange.Redis — connects to a Valkey server with no code change. The protocol negotiation, pipelining, pub/sub framing, and cluster redirection messages (MOVED, ASK) all behave the same.

Consider a raw RESP exchange. A SET command followed by GET looks like this on the wire, and the framing is byte-for-byte the same on both servers:

C: *3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n
S: +OK\r\n

C: *2\r\n$3\r\nGET\r\n$3\r\nfoo\r\n
S: $3\r\nbar\r\n

RESP3 adds typed replies — maps, sets, doubles, big numbers, and push messages for client-side caching. Both projects negotiate RESP3 through the HELLO 3 command identically. So whether you use HELLO to upgrade the connection or stay on RESP2, the behavior is consistent across both servers.

Because Valkey is a source-level fork of Redis 7.2.4, it inherits the exact RESP2/RESP3 implementation. No client library, proxy, or monitoring agent that speaks the Redis protocol needs modification to work against Valkey — the wire format is unchanged (Valkey, 2025).

Where do the command sets actually diverge?

Divergence is not at the protocol layer — it's at the command-set layer, and it grows with each release past the 7.2.4 fork point. Both projects keep adding commands independently, so command parity is a per-version question, not a yes/no answer. The protocol that carries the commands stays identical; the available verbs do not.

On the Redis side, Redis 7.4 introduced Hash Field Expiration — the HEXPIRE, HPEXPIRE, HEXPIREAT, and HTTL family — which lets you set TTLs on individual hash fields rather than the whole key. Valkey added equivalent functionality later, with hash-field expiration landing in the Valkey 9.0 cycle. The behavior converges, but the timing and edge-case semantics can differ, so test against your target version.

Valkey has shipped its own operational additions too. Valkey 8.1 introduced SET ... IFEQ, a conditional update that only writes if the current value matches an expected one — useful for optimistic concurrency without a full Lua script (Valkey, April 2025). The same release added COMMANDLOG, extending the older slowlog concept to track large requests and replies, not just slow ones.

Capability

Redis

Valkey

RESP2 / RESP3

Yes

Yes (identical)

Hash field expiration (HEXPIRE family)

Since 7.4

Since 9.0

Conditional SET ... IFEQ

Not native

Since 8.1

COMMANDLOG

Since 8.1

Vector sets

Since 8 (antirez)

Via valkey-search module

The practical takeaway: if your application sticks to the core data-type commands that existed at 7.2.4 — strings, hashes, lists, sets, sorted sets, streams, pub/sub, transactions, scripting — you have near-total portability in both directions. The moment you adopt a command added after the fork, verify it exists and behaves the same on the other project at the specific version you target.

Are RDB and AOF data formats compatible between Valkey and Redis?

At the Redis 7.2 baseline, completely. Valkey reads and writes RDB snapshot files and AOF (append-only file) logs that are compatible with Redis OSS 7.2 — the RDB version 11 format (Valkey migration docs). This is what makes migration so painless for teams still on Redis 7.2 or earlier: you stop Redis, point Valkey at the same dump.rdb or AOF directory, and start it. The data loads natively.

The same compatibility underpins replication-based migration. Because Valkey speaks the Redis replication protocol and understands the Redis 7.2 RDB stream, you can configure a Valkey instance as a replica of a Redis 7.2 primary, let it sync, then promote it — a near-zero-downtime cutover.

But there is a hard edge, and it's the most important caveat in this entire comparison. RDB files produced by Redis CE 7.4 and later are not compatible with Valkey (Valkey migration docs). After the 7.2.4 fork, Redis evolved its RDB format to support new in-core data types — and those newer RDB files will not load into a Valkey server. The formats have diverged.

RDB interoperability is anchored to the 7.2 fork point, not to "Redis" in general. Valkey loads RDB and AOF files from Redis OSS 7.2, but Redis CE 7.4+ RDB files will not load into Valkey because both projects extended the format independently after the split (Valkey, 2025).

Two consequences follow. First, if you're on Redis 7.4 or 8, a file-level migration to Valkey is no longer a drop-in copy — you need a logical migration path (replication from a compatible version, or a tool that reads keys over the wire and rewrites them). Second, treat the reverse direction with caution: loading Valkey-written files into Redis is not officially documented as supported, so don't assume bidirectional file interop. Plan migrations as one-directional from a known-compatible baseline.

What this means for your migration plan

If you're on Redis ≤ 7.2: file copy or replica-promotion both work cleanly. If you're on Redis 7.4+ or Redis 8: use live replication where the source version allows it, or a key-by-key migration tool that operates at the command level rather than the file level. Always validate with a representative dataset before cutover, and snapshot both sides so you can roll back.

How does Valkey 8.x performance compare to Redis?

This is where the fork stopped being a copy and started pulling ahead on its own engineering. Valkey 8.0 delivered roughly 1.2M requests per second on AWS hardware — a separate published test measured a jump from about 360K to 1.19M RPS, a ~230% gain, on a c7g.16xlarge instance with 8 I/O threads (Valkey, Sept 2024). That number is real, but it is hardware-specific: it reflects a high-core-count ARM instance with multiple I/O threads and a particular payload. Don't quote it as a universal figure.

Three architectural changes drove the Valkey 8.0 leap (Valkey 8.0 RC1, Aug 2024):

Asynchronous I/O multithreading — offloads socket reads, writes, and command parsing (including epoll_wait handling) to I/O threads, freeing the main thread for command execution.
Per-slot dictionaries — in cluster mode, each hash slot gets its own dictionary instead of one shared linked structure, cutting roughly 16 bytes per key-value pair and improving cache locality.
Dual-channel replication — streams the RDB snapshot and the replication backlog in parallel over two channels, reducing full-sync time by up to 50%.

Valkey 8.1 (April 2, 2025) pushed efficiency further: memory dropped by about 20 bytes per key-value pair without a TTL and 30 bytes with one, TLS connection-accept throughput rose roughly 300%, SET and GET over TLS improved ~10% and ~22%, and BITCOUNT gained an AVX2-accelerated path measured at +514% (Valkey 8.1 GA). Independent benchmarking corroborates the throughput claims — Momento measured Valkey 8.1.1 at roughly 1M SET RPS on a c8g.2xlarge with sub-millisecond p99 latency.

Metric (c7g.16xlarge, 8 I/O threads)

Valkey 7.2 baseline

Valkey 8.0

Throughput (RPS)

~360K

~1.19M (+230%)

Memory per KV (cluster)

baseline

−16 bytes

Full-sync time

baseline

up to −50%

Redis 8 is no slouch — it shipped its own performance work and the bundled query engine — but the multithreaded I/O path and per-slot memory model give Valkey a clear, independently verified edge on high-core-count hardware. For latency-sensitive, high-throughput workloads, that gap is worth benchmarking on your own instance types.

How do the module and ecosystem stories differ?

This is the sharpest architectural divergence. Redis 8 folded the former Redis Stack modules directly into the core server: native JSON, time series, five probabilistic structures (Bloom, Cuckoo, Count-Min Sketch, Top-K, t-digest), vector sets, and the Redis Query Engine (the former RediSearch) — all shipping in-core under the tri-license (Redis, 2025).

Valkey took the opposite path: it keeps the core lean and ships equivalent capabilities as separate, BSD-licensed modules in the Valkey Bundle — valkey-search (vector and secondary indexing), valkey-json, valkey-bloom, and valkey-ldap, with modules reaching GA through the 8.1 and 9.0 cycles. One philosophy bundles everything into a single binary; the other keeps a minimal core you extend deliberately.

For client compatibility, this distinction mostly doesn't matter — standard RESP clients work against both servers because the protocol is shared. Where it matters is module-specific clients and query syntax: if you depend on RediSearch query features or RedisJSON path semantics, validate that the corresponding Valkey module matches the behavior you rely on, since they're now independently maintained codebases.

Which platforms have adopted Valkey?

Adoption moved fast, led by the cloud providers most affected by the license change. AWS added Valkey to both ElastiCache and MemoryDB in October 2024, with a zero-downtime in-place upgrade path from Redis 7.2 — and priced it below the Redis-compatible option (AWS, Oct 2024). Google Cloud added Valkey to Memorystore, and Oracle ships it on OCI.

The community numbers reflect that backing. By its first anniversary, Valkey had passed 100 million+ Docker pulls and drawn 150+ contributors from 50+ organizations including Google, Oracle, AWS, Ericsson, ByteDance, Aiven, and Percona (AWS, 2025). On the distribution side, Fedora, Debian, and Ubuntu moved their default in-memory data store package to Valkey, which means a large share of new Linux deployments now get Valkey by default rather than Redis.

For teams running their own infrastructure, the deployment story for Valkey and Redis is effectively identical — same config file format, same ports, same operational tooling. If you're standing up either on managed servers, a platform that provisions and manages your data store removes most of the day-two operational burden regardless of which engine you pick.

Should you migrate from Redis to Valkey?

The decision usually comes down to three factors: licensing, version, and feature dependency. If you need a permissive open-source license — for distribution, for compliance, or to avoid the source-available restrictions — Valkey (BSD-3) or Redis 8 under AGPLv3 both qualify, where the older RSALv2/SSPLv1-only releases do not.

If you're on Redis 7.2 or earlier and want the performance gains, Valkey 8.x is a low-risk upgrade: the wire protocol is identical, your clients don't change, and the RDB/AOF files load natively. If you depend on the bundled Redis 8 modules with their exact query semantics, weigh whether the Valkey module equivalents cover your use cases before committing. And if you're already on Redis 7.4+, remember that file-level migration to Valkey no longer works — plan a logical or replication-based path.

Frequently Asked Questions

Is Valkey a drop-in replacement for Redis?

For most workloads, yes. Valkey forked from Redis 7.2.4 and uses the identical RESP2/RESP3 protocol, so existing clients connect without code changes and RDB/AOF files from Redis 7.2 load natively (Valkey, 2025). The exceptions are commands added after the fork and the bundled Redis 8 modules, which you should validate per version.

Can Valkey read Redis RDB files?

Valkey reads RDB and AOF files compatible with Redis OSS 7.2 (RDB version 11). However, RDB files written by Redis CE 7.4 and later are not compatible with Valkey, because the on-disk format diverged after the 7.2.4 fork point (Valkey migration docs).

Is Valkey faster than Redis?

On high-core-count hardware, Valkey 8.0 showed roughly a 230% throughput gain over the 7.2 baseline — up to ~1.2M RPS on a c7g.16xlarge with 8 I/O threads (Valkey, Sept 2024). The gains come from async I/O threading and per-slot dictionaries. Always benchmark on your own instance types, since the figures are hardware-specific.

Do I need different client libraries for Valkey?

No. Because the wire protocol is identical to Redis, standard Redis client libraries — redis-py, ioredis, Jedis, go-redis, and others — work against Valkey unchanged. Dedicated Valkey clients exist but are optional; the protocol compatibility is what matters (Valkey protocol spec).

Is Redis still open source in 2026?

Yes, again. Redis added AGPLv3 as a license option starting with Redis 8 in May 2025, making it open source under OSI-approved terms alongside the source-available RSALv2 and SSPLv1 options (Redis, May 2025). Releases between 7.4 and 8 were source-available only.

Conclusion

Valkey and Redis remain remarkably compatible where it counts most — the RESP wire protocol is byte-identical, and your client code, monitoring, and proxies carry over with zero changes. The real divergence lives at two layers: the command set, which grows apart with each release past 7.2.4, and the on-disk RDB format, which is interoperable only at the Redis 7.2 baseline and breaks for Redis 7.4+ files.

For teams on Redis 7.2 or earlier, Valkey 8.x is a fast, low-risk upgrade with a genuine, independently verified performance edge. For teams on Redis 7.4+, migration is still very doable — it just requires a logical or replication-based path rather than a file copy. Either way, benchmark on your own hardware, pin to specific versions when you test command and module behavior, and snapshot both sides before you cut over.

Sources: *Valkey — Migration from Redis · Valkey — Protocol spec · Valkey 8.0 RC1 · Valkey — 1M RPS · Valkey 8.1 GA · Redis — AGPLv3 · Redis — What is Valkey · Percona — Redis license change · AWS — Year One of Valkey. Retrieved 2026-06-16.*

How Much Traffic Can a $5 Server Handle? Load Testing Laravel on Deploynix

Deploynix — Sun, 26 Apr 2026 09:00:06 +0000

Every developer launching a new project asks the same question: how much server do I actually need? The cloud providers offer servers starting at $4-6/month, but their marketing pages show theoretical bandwidth limits and CPU benchmarks that tell you nothing about how your Laravel application will perform under real-world load.

So let's find out. In this post, we'll provision a $5 server on Deploynix, deploy a representative Laravel application, and progressively load test it until it breaks. Along the way, we'll apply optimizations and measure their impact. By the end, you'll know exactly what a budget server can handle — and when it's time to scale up.

The Test Environment

The Server

We're using a typical $5/month cloud server — the kind you'd get from Hetzner, DigitalOcean, or Vultr at this price point:

CPU: 1 shared vCPU
RAM: 1 GB
Disk: 25 GB SSD
Network: 1 Gbps
OS: Ubuntu 24.04

This is the smallest server most providers offer. Deploynix provisions it as an App server — running Nginx, PHP 8.4 with FPM, MySQL, Valkey, and Supervisor all on the same machine.

The Application

Testing against a "Hello World" endpoint is meaningless. Real Laravel applications hit the database, render Blade views, check authentication, and process middleware. Our test application represents a typical content site:

Authentication middleware on all routes
A dashboard page that queries 5 Eloquent models with relationships
A listing page with pagination (20 items per page, eager-loaded relationships)
An API endpoint returning JSON through an Eloquent Resource
Active sessions stored in Valkey
Config, route, and view caches enabled

This gives us a realistic baseline that reflects what most Laravel applications actually do.

The Load Testing Tool

We'll use k6, a modern load testing tool that's developer-friendly and doesn't consume excessive resources on the machine running the tests. A basic k6 script looks like this:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
    stages: [
        { duration: '1m', target: 10 },   // Ramp to 10 users
        { duration: '3m', target: 10 },   // Stay at 10
        { duration: '1m', target: 50 },   // Ramp to 50
        { duration: '3m', target: 50 },   // Stay at 50
        { duration: '1m', target: 100 },  // Ramp to 100
        { duration: '3m', target: 100 },  // Stay at 100
        { duration: '1m', target: 0 },    // Ramp down
    ],
};

export default function () {
    const res = http.get('https://your-app.deploynix.cloud/dashboard');
    check(res, {
        'status is 200': (r) => r.status === 200,
        'response time < 500ms': (r) => r.timings.duration < 500,
    });
    sleep(1);
}

Run tests from a separate machine — never from the server you're testing. Loading testing from the same server contaminates results because the test tool competes with the application for resources.

Phase 1: Baseline Test (No Optimization)

First, let's deploy the application with default settings — no caching commands, no optimization. This represents what happens when a developer pushes code and forgets to run the optimization commands.

10 Concurrent Users

At 10 concurrent users with a 1-second think time (each user makes a request, waits 1 second, repeats):

Requests/second: ~9.5
Median response time: 95ms
P95 response time: 180ms
P99 response time: 310ms
Error rate: 0%
CPU usage: ~25%
Memory usage: ~680MB (of 1GB)

At this level, the server handles everything comfortably. Response times are good, and there's plenty of headroom.

50 Concurrent Users

Ramping to 50 concurrent users:

Requests/second: ~42
Median response time: 320ms
P95 response time: 890ms
P99 response time: 1,400ms
Error rate: 0%
CPU usage: ~78%
Memory usage: ~720MB

Things are getting warm. The P95 response time approaching 1 second means one in twenty requests feels sluggish. CPU is climbing. Memory is tight — MySQL and Valkey are competing with PHP workers for that 1GB.

100 Concurrent Users

Pushing to 100:

Requests/second: ~48 (barely increased from 50 users)
Median response time: 1,800ms
P95 response time: 4,200ms
P99 response time: 8,500ms
Error rate: 3.2% (timeouts and 502 errors)
CPU usage: 98%
Memory usage: ~950MB (OOM killer territory)

The server hit its wall. Request throughput plateaued at ~48 req/s while response times exploded. Some requests are timing out entirely. The CPU is saturated, and memory is dangerously close to triggering the OOM killer.

Baseline breaking point: ~50 concurrent users, ~42 requests/second.

Phase 2: Apply Laravel Optimizations

Now let's apply the standard production optimizations and retest.

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

Also ensure APP_DEBUG=false and the OPcache extension is enabled (Deploynix enables this by default).

Results at 50 Concurrent Users (Optimized)

Requests/second: ~48
Median response time: 210ms
P95 response time: 450ms
P99 response time: 680ms
Error rate: 0%
CPU usage: ~60%
Memory usage: ~650MB

A significant improvement. Caching configuration and routes eliminated the overhead of parsing those files on every request. Response times nearly halved, and CPU dropped from 78% to 60%.

Results at 100 Concurrent Users (Optimized)

Requests/second: ~82
Median response time: 480ms
P95 response time: 1,100ms
P99 response time: 1,800ms
Error rate: 0.5%
CPU usage: 92%
Memory usage: ~780MB

We nearly doubled the throughput before hitting the wall. The server can now handle 100 concurrent users with acceptable (though not great) response times. The few errors are sporadic timeouts during CPU spikes.

Optimized breaking point: ~100 concurrent users, ~82 requests/second.

Phase 3: Switch to FrankenPHP (Octane)

FrankenPHP keeps the Laravel application bootstrapped in memory between requests. Instead of loading the framework, service providers, and configuration on every request, the application boots once and handles subsequent requests from memory.

Deploy with FrankenPHP through Deploynix's Octane driver selection, then retest.

Results at 100 Concurrent Users (FrankenPHP)

Requests/second: ~145
Median response time: 180ms
P95 response time: 420ms
P99 response time: 690ms
Error rate: 0%
CPU usage: ~70%
Memory usage: ~520MB

This is a dramatic improvement. FrankenPHP eliminated the per-request framework bootstrap overhead, nearly doubling throughput again. Memory usage actually dropped because the application is loaded once instead of per-request.

Results at 200 Concurrent Users (FrankenPHP)

Requests/second: ~180
Median response time: 450ms
P95 response time: 1,100ms
P99 response time: 1,900ms
Error rate: 0.8%
CPU usage: 94%
Memory usage: ~600MB

At 200 concurrent users, the single vCPU is the bottleneck. The application is still responsive but the CPU can't keep up. Throughput has started to plateau.

FrankenPHP breaking point: ~200 concurrent users, ~180 requests/second.

Phase 4: Database Query Optimization

Our test application had a few unoptimized queries — missing eager loading on the listing page and no indexes on commonly filtered columns. After fixing:

// Before: N+1 problem
$posts = Post::paginate(20);
// In view: $post->author->name (triggers N+1)

// After: Eager loaded
$posts = Post::with('author')->paginate(20);

And adding a composite index:

Schema::table('posts', function (Blueprint $table) {
    $table->index(['status', 'published_at']);
});

Results at 200 Concurrent Users (FrankenPHP + Query Optimization)

Requests/second: ~210
Median response time: 380ms
P95 response time: 820ms
P99 response time: 1,300ms
Error rate: 0%
CPU usage: 88%
Memory usage: ~550MB

Query optimization reduced database CPU time, which freed up CPU cycles for handling more requests. The errors at 200 users disappeared entirely.

Pushing to 300 Concurrent Users

Requests/second: ~225
Median response time: 850ms
P95 response time: 2,100ms
P99 response time: 3,400ms
Error rate: 1.5%
CPU usage: 98%
Memory usage: ~620MB

The CPU is fully saturated. We've found the ceiling for this $5 server.

Fully optimized breaking point: ~250 concurrent users, ~220 requests/second.

What Does This Mean in Real Traffic?

Concurrent users is a load testing metric, not a real-world traffic metric. Real users don't send a request every second — they read pages, fill out forms, and navigate at human speed. The ratio depends on your application, but a common rule of thumb:

1 concurrent user in load testing ≈ 10-30 real active users.

So our fully optimized $5 server handling 250 concurrent users translates to roughly:

2,500 - 7,500 active users browsing simultaneously
~220 requests/second sustained throughput
~19 million requests/day at sustained peak
~570 million requests/month at sustained peak

Most applications don't sustain peak traffic 24/7. If your peak is 4 hours/day, a $5 server can handle an application with 50,000-100,000 daily active users comfortably.

That's a $5/month server.

Optimization Impact Summary

Configuration

Max RPS

P95 at 50 Users

Breaking Point

Default (no caching)

~42

890ms

~50 concurrent

Laravel cache commands

~82

450ms

~100 concurrent

FrankenPHP (Octane)

~180

420ms

~200 concurrent

Query optimization

~220

320ms

~250 concurrent

Each optimization roughly doubled throughput. Combined, we went from 42 to 220 requests/second — a 5x improvement without spending an extra dollar on infrastructure.

When to Scale Up

Watch these signals on your Deploynix monitoring dashboard:

Scale up the server (vertical scaling) when:

CPU consistently above 80% during normal traffic (not just spikes)
Memory usage leaves less than 100MB free
P95 response times exceed your acceptable threshold (usually 1-2 seconds)
The OOM killer has been triggered (check dmesg for killed processes)

Scale out to multiple servers (horizontal scaling) when:

You've maxed out the largest single server your budget allows
You need redundancy — a single server is a single point of failure
Queue processing competes with web requests for CPU time
Database operations need dedicated resources

The typical scaling path on Deploynix:

Start with a single App server ($5-12/month)
Upgrade to a larger server when CPU/memory is consistently tight ($24-48/month)
Separate the database to its own server when query performance suffers
Add a dedicated worker server when queues can't keep up
Add a load balancer with multiple web servers when a single web server can't handle peak traffic

Cost-Effective Optimization Checklist

Before spending money on bigger servers, make sure you've applied these free optimizations:

[ ] APP_DEBUG=false
[ ] Run config:cache, route:cache, view:cache, event:cache
[ ] OPcache enabled with appropriate settings
[ ] FrankenPHP, Swoole, or RoadRunner via Octane
[ ] Eager loading on all relationship accesses (no N+1 queries)
[ ] Database indexes on filtered and sorted columns
[ ] Response caching for pages that don't change per-user
[ ] Asset optimization (npm run build, not npm run dev)
[ ] Queue heavy operations instead of processing inline
[ ] Valkey for sessions, cache, and queues (not file/database drivers)

Each of these is free and most take minutes to implement. Collectively, they can improve performance by 5-10x.

Conclusion

A $5 server can handle far more traffic than most developers expect. With Laravel's built-in optimization commands and an Octane driver like FrankenPHP, a single shared vCPU server sustains over 200 requests per second — enough for thousands of concurrent users.

The key insight is that optimization should come before scaling. A $5 server with FrankenPHP and proper caching outperforms a $48 server running unoptimized PHP-FPM. Only when you've exhausted the free optimizations should you reach for the scaling lever.

Deploynix makes both paths easy. Optimize your application and deploy it to a small server. Monitor the metrics. When the dashboard tells you it's time, scale up with a click. No premature infrastructure spending, no guessing — just data-driven decisions about when your application needs more resources.

Start small. Optimize first. Scale when the numbers tell you to.

The Definitive Guide to Laravel Deployment in 2026

Deploynix — Sat, 25 Apr 2026 21:00:06 +0000

Deploying a Laravel application in 2026 looks nothing like it did five years ago. PHP-FPM is no longer the only game in town — FrankenPHP, Swoole, and RoadRunner have changed what's possible for performance. Server management platforms have matured to the point where a solo developer can run production infrastructure that would have required a DevOps team. And the Laravel ecosystem itself has introduced tools for monitoring, testing, and scaling that make the deployment story more complete than ever.

This guide covers the full journey: from your local development environment to a production deployment that's monitored, backed up, and ready to scale. Whether you're deploying your first Laravel application or rearchitecting an existing one, this is your comprehensive reference.

Part 1: Preparing Your Application for Production

Before you touch a server, your application needs to be production-ready. This means more than "it works on my machine."

Environment Configuration

Laravel uses .env files to separate configuration from code. Your production environment needs different values from development:

APP_ENV=production
APP_DEBUG=false
APP_URL=https://your-domain.com

LOG_CHANNEL=stack
LOG_LEVEL=warning

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=your_app
DB_USERNAME=your_user
DB_PASSWORD=strong_random_password

CACHE_STORE=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis

Critical settings:

APP_DEBUG=false prevents stack traces from leaking to users. Leaving this true in production is a security vulnerability.
LOG_LEVEL=warning prevents your log files from filling the disk with debug information.
Use Redis (or Valkey, which is Redis-compatible) for cache, sessions, and queues in production. The file and database drivers don't scale.

Optimizing for Production

Laravel provides several Artisan commands that optimize performance by caching configuration, routes, and views:

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

These commands serialize your configuration, routes, views, and events into cached files that load faster than parsing the original sources on every request. Run them as part of your deployment process — never manually.

Asset Compilation

Build your frontend assets for production:

npm run build

This runs Vite in production mode, which minifies JavaScript and CSS, tree-shakes unused code, and generates versioned filenames for cache busting. Never run npm run dev on a production server — development mode includes source maps and unminified code.

Part 2: Choosing Your Server Infrastructure

Your infrastructure choices depend on your application's needs, traffic expectations, and budget.

Cloud Providers

Deploynix supports provisioning servers on DigitalOcean, Vultr, Hetzner, Linode, AWS, and custom providers. Each has trade-offs:

Hetzner offers the best price-to-performance ratio for CPU and RAM. Ideal for budget-conscious deployments.
DigitalOcean provides a polished experience with predictable pricing. Strong ecosystem of add-ons.
Vultr offers competitive pricing with good global coverage.
Linode (now Akamai) provides solid performance with straightforward pricing.
AWS gives maximum flexibility and the broadest service catalog, but with higher complexity and cost.

For most Laravel applications starting out, a $5-12/month server on Hetzner or DigitalOcean is more than sufficient. You can always scale up later.

Server Types

A single App server handles everything for most applications: web serving, application processing, database, cache, and queue workers. As you grow, you split these responsibilities across specialized servers.

App Server: Runs your Laravel application with Nginx, PHP, and queue workers. This is the all-in-one starting point.

Web Server: Handles HTTP requests and serves static files. In a scaled architecture, multiple web servers sit behind a load balancer.

Database Server: Dedicated MySQL, MariaDB, or PostgreSQL instance. Isolating the database gives it dedicated CPU and RAM, improving query performance.

Cache Server: Dedicated Valkey (Redis-compatible) instance for caching, sessions, and queues. Separating cache from the application server prevents cache eviction during memory pressure.

Worker Server: Runs queue workers without competing with web requests for resources. Essential when you process heavy background jobs.

Load Balancer: Distributes traffic across multiple web servers. Deploynix supports round robin, least connections, and IP hash load balancing methods.

Choosing a PHP Runtime

Traditional PHP-FPM remains reliable and well-understood, but modern runtimes offer significant performance improvements:

FrankenPHP is a modern PHP application server built on Caddy. It supports worker mode (keeping your application in memory between requests), HTTP/3, and Early Hints. It's becoming the default recommendation for new Laravel deployments.

Swoole keeps your application bootstrapped in memory, eliminating the per-request overhead of loading the framework. It provides dramatic performance improvements but requires careful attention to memory leaks and static state.

RoadRunner is a Go-based application server that communicates with PHP workers over a binary protocol. It offers performance between FPM and Swoole with simpler debugging.

Deploynix supports deploying with any of these Octane drivers. For most applications, FrankenPHP provides the best balance of performance and developer experience.

Part 3: Provisioning and Configuration

Provisioning with Deploynix

Deploynix provisions servers by connecting to your cloud provider's API. You select a provider, region, server size, and type — Deploynix handles the rest: installing the OS, configuring the web server, setting up PHP, installing the database, configuring the firewall, and setting up SSL.

The provisioning process installs everything your Laravel application needs:

Nginx (configured for your chosen Octane driver or PHP-FPM)
PHP 8.4 with essential extensions
MySQL, MariaDB, or PostgreSQL
Valkey for caching and queues
Composer
Node.js and npm for asset compilation
Supervisor for queue workers and daemons
UFW firewall with sensible defaults

Connecting Your Git Repository

Deploynix integrates with GitHub, GitLab, Bitbucket, and custom Git providers. Connect your repository, select a branch, and Deploynix configures the deployment pipeline.

Your deployment workflow becomes: push to your branch, trigger a deploy (manually or automatically), and Deploynix handles the rest.

SSL Certificates

Every production application needs HTTPS. Deploynix provisions SSL certificates automatically through Let's Encrypt when you add a domain to your site. For wildcard certificates, Deploynix supports DNS validation through Cloudflare, DigitalOcean, AWS Route 53, and Vultr DNS.

Deploynix also provides vanity domains (*.deploynix.cloud) with pre-configured wildcard SSL certificates — useful for staging environments and quick deployments before your custom domain is configured.

Certificate renewal is handled automatically. Deploynix monitors certificate expiration and renews before they expire.

Part 4: The Deployment Process

Zero-Downtime Deployments

Deploynix uses a release-based deployment strategy that eliminates downtime:

A new release directory is created
Your repository is cloned or updated
Composer dependencies are installed
npm dependencies are installed and assets are built
Your deploy script runs (migrations, cache clearing, etc.)
The symlink switches from the old release to the new one
PHP-FPM/Octane workers are reloaded

The symlink switch is atomic — your application serves the old version until the exact moment it switches to the new one. There's no period where the application is partially deployed.

Deploy Script

Deploynix lets you define a custom deploy script that runs as part of the deployment process, inside the new release directory before the symlink swap:

composer install --no-dev --optimize-autoloader
npm ci && npm run build
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache
php artisan queue:restart

All steps complete before the new release goes live, ensuring users never see a partially prepared release.

Scheduled Deployments

Deploynix supports scheduling deployments for a future time. This is useful for coordinating releases with marketing launches or deploying during low-traffic windows. Scheduled deployments can be cancelled before their execution time.

Rollback

When a deployment introduces a bug, Deploynix can roll back to any previous release instantly. The rollback switches the symlink back to a previous release directory — the same atomic operation as a forward deployment.

Keep enough release directories to allow meaningful rollbacks. Deploynix retains configurable number of releases, automatically pruning older ones.

Part 5: Database Management

Running Migrations

Run migrations as part of your deploy script:

php artisan migrate --force

The --force flag is required in production. Without it, Artisan prompts for confirmation — which hangs in an automated deployment.

Database Backups

Deploynix supports automated database backups to AWS S3, DigitalOcean Spaces, Wasabi, and any S3-compatible storage. Configure backup frequency, retention period, and storage destination.

Backup strategy recommendations:

Hourly backups for applications with high write volume
Daily backups for most applications
Store backups in a different region than your primary server
Test restoring from backups periodically — an untested backup is not a backup

Database Optimization

For production MySQL databases:

Enable the slow query log to identify performance problems
Set innodb_buffer_pool_size to 60-80% of available RAM on a dedicated database server
Use connection pooling if your application creates many short-lived connections
Monitor query performance through Deploynix's server metrics and Laravel Pulse

Part 6: Queue Workers and Background Processing

Configuring Queue Workers

Deploynix manages Supervisor configuration for your queue workers. Configure the number of worker processes, the queues they process, and restart policies.

For most applications, start with 2-3 workers processing all queues:

Queue: default,notifications,emails
Processes: 3

As your application grows, dedicate workers to specific queues based on priority:

Worker 1: payments (1 process, high priority)
Worker 2: default,notifications (3 processes)
Worker 3: exports,reports (2 processes, can be slow)

Daemon Processes

Beyond queue workers, you might need long-running processes: WebSocket servers (Laravel Reverb), schedule runners, or custom daemons. Deploynix manages these through its daemon feature, which configures Supervisor to keep them running and restart them on failure.

Part 7: Monitoring and Alerting

Server Monitoring

Deploynix provides real-time monitoring for every managed server:

CPU usage: Sustained high CPU indicates resource contention or runaway processes
Memory usage: Track consumption trends to predict when you need to scale
Disk usage: Running out of disk space causes cascading failures
Network I/O: Unusual spikes might indicate a DDoS attack or a deployment pulling large dependencies

Health Alerts

Configure health alerts to notify you when metrics cross thresholds:

CPU above 90% for more than 10 minutes
Memory above 85%
Disk usage above 80%

Deploynix sends alerts through your configured notification channels, giving you time to investigate before users are affected.

Application-Level Monitoring

Complement Deploynix's infrastructure monitoring with application-level tools:

Laravel Pulse for production performance trends, slow queries, and queue throughput
Laravel Telescope (filtered) for capturing exceptions and failed jobs in production
Custom health check endpoints that verify database, cache, queue, and external API connectivity

Part 8: Security

Firewall Configuration

Deploynix configures UFW (Uncomplicated Firewall) with sensible defaults: SSH (port 22), HTTP (port 80), and HTTPS (port 443) are open. Everything else is closed.

Add custom rules for:

Database access from specific IP addresses (if you connect remotely)
Application-specific ports (WebSockets on port 6001, etc.)
Blocking known bad IP ranges

SSH Security

Deploynix provisions servers with key-based SSH authentication. Password authentication is disabled by default. Never re-enable it.

Application Security Essentials

Keep PHP, Nginx, MySQL, and all system packages updated
Run composer audit regularly to check for vulnerable dependencies
Use Sanctum for API authentication with granular token scopes
Implement rate limiting on authentication and API endpoints
Store sensitive values in environment variables, never in code

Part 9: Scaling

Vertical Scaling (Scaling Up)

The simplest scaling approach: give your server more resources. Deploynix makes this easy — resize your server through your cloud provider, and your application continues running with more CPU, RAM, and disk.

Vertical scaling works until you hit the cloud provider's largest instance size or until cost becomes unreasonable. Most Laravel applications can serve thousands of concurrent users on a single well-configured server.

Horizontal Scaling (Scaling Out)

When a single server isn't enough, distribute the load across multiple servers:

Separate your database onto a dedicated server. This is usually the first scaling step and provides the biggest impact.
Separate your cache (Valkey) onto a dedicated server. This prevents cache eviction during application memory pressure.
Add worker servers for queue processing. This keeps background jobs from competing with web requests for CPU.
Add web servers behind a load balancer. Deploynix's load balancer supports round robin, least connections, and IP hash methods.

Scaling Checklist

Before scaling horizontally, ensure your application is stateless:

Sessions stored in Redis/Valkey (not file)
Cache in Redis/Valkey (not file)
File uploads on external storage (S3, not local disk)
Queues using Redis/Valkey (not the database or sync driver)
No local file writes that other servers need to access

If your application writes anything to the local filesystem that other servers need to read, you'll have inconsistency across servers. Move shared state to external services before adding servers.

Part 10: The Deployment Checklist

Use this checklist for every new Laravel production deployment:

Before First Deploy

[ ] APP_DEBUG=false and APP_ENV=production are set
[ ] Database credentials use a strong, unique password
[ ] Session, cache, and queue drivers are set to Redis/Valkey
[ ] SSL certificate is provisioned
[ ] Firewall rules are configured
[ ] Backup schedule is configured and tested
[ ] Health monitoring is enabled
[ ] Queue workers are configured and running

Every Deploy

[ ] Tests pass before deployment
[ ] Migrations are tested against a copy of production data
[ ] Assets are compiled for production
[ ] Config, route, view, and event caches are refreshed
[ ] Queue workers are restarted to pick up new code
[ ] Deployment is verified by checking the application's health endpoint

Post-Deploy Verification

[ ] Application responds correctly to key user flows
[ ] Queue workers are processing jobs
[ ] No new errors appearing in logs
[ ] Server metrics (CPU, memory, disk) are within normal ranges
[ ] Scheduled tasks are running as expected

Conclusion

Laravel deployment in 2026 is more powerful and more accessible than ever. Modern PHP runtimes like FrankenPHP deliver performance that would have been unthinkable a few years ago. Platforms like Deploynix eliminate the ops burden of server management, letting you focus on building your application.

The key principles haven't changed: automate everything, monitor proactively, back up regularly, and scale intentionally. What has changed is the tooling — you no longer need a dedicated DevOps engineer to run production infrastructure. A solo developer with Deploynix can provision, deploy, monitor, and scale a Laravel application that serves millions of requests.

Start simple. A single App server with zero-downtime deployments, automated backups, and health monitoring handles more traffic than most applications will ever see. Scale when the metrics tell you to, not when your anxiety does. And always, always test your backups.

Your deployment pipeline is not a one-time setup — it's a living system that evolves with your application. Review it regularly, keep your dependencies updated, and invest in monitoring. The best deployment is the one you don't have to think about because everything is automated and every failure triggers an alert before your users notice.

Finding and Fixing Slow Queries in Laravel Before They Hit Production

Deploynix — Sat, 25 Apr 2026 15:58:15 +0000

Every Laravel application has slow queries. The question is whether you find them before your users do.

A query that takes 50ms on your local machine with 100 rows might take 5 seconds in production with 500,000 rows. A polymorphic relationship that works fine in development becomes a full table scan when the morphables table hits a million records. An Eloquent scope that chains three whereHas calls generates a nested subquery monster that brings your database server to its knees during peak traffic.

The good news: Laravel gives you excellent tools to find these queries before they cause outages. The better news: once you find them, the fixes are usually straightforward. This post walks through a complete workflow — from local detection with Debugbar and Telescope, through query analysis with EXPLAIN, to production monitoring with Deploynix.

Step 1: Detect Slow Queries in Development

The first line of defense is catching slow queries during development. Two tools make this effortless.

Laravel Debugbar

Debugbar is the fastest way to spot query problems. Install it as a dev dependency:

composer require barryvdh/laravel-debugbar --dev

Every page load shows a toolbar at the bottom of your browser with the number of queries executed and their total time. Click the queries tab to see each individual query with its execution time and the file/line that triggered it.

The critical metric here isn't the total query time — it's the query count. If loading a dashboard page executes 47 queries, you have an N+1 problem regardless of how fast each individual query runs. Those 47 queries will become 4,700 queries when your data grows.

Look for these red flags in Debugbar:

More than 10-15 queries per page load
Duplicate queries (the same query executed multiple times with different IDs)
Queries without a WHERE clause on large tables
Queries that don't appear in your controller or view code (often caused by lazy-loaded relationships in Blade templates)

Laravel Telescope

Telescope records every query your application executes and flags slow ones automatically. After installation, visit /telescope/queries to see queries sorted by duration.

Telescope is particularly useful for catching slow queries in API endpoints and queued jobs — places where Debugbar can't reach.

Configure the slow query threshold in your Telescope service provider:

Telescope::tag(function (IncomingEntry $entry) {
    if ($entry->type === EntryType::QUERY && $entry->content['slow']) {
        return ['slow-query'];
    }

    return [];
});

The default slow query threshold is 100ms, which is reasonable for most applications. Any query that takes longer than that deserves investigation.

Step 2: Analyze with EXPLAIN

Once you've identified a slow query, the next step is understanding why it's slow. MySQL's EXPLAIN command tells you exactly how the database plans to execute a query.

Take the raw SQL from Debugbar or Telescope and run it with EXPLAIN:

EXPLAIN SELECT * FROM orders
WHERE user_id = 42
AND status = 'pending'
AND created_at > '2026-01-01'
ORDER BY created_at DESC;

The output shows you the query execution plan. Here's what to look for:

type column: This is the most important indicator.

ALL means a full table scan. On a large table, this is almost always the problem.
index means a full index scan — better than ALL, but still reads every row in the index.
range means the query uses an index to select a range of rows. This is usually acceptable.
ref means the query uses an index to look up matching rows. This is good.
eq_ref means a unique index lookup. This is optimal.
const means the query matches at most one row. This is the fastest possible lookup.

rows column: The estimated number of rows MySQL will examine. If this number is close to the total row count of the table, you're doing a full scan even if the type column says otherwise.

Extra column: Watch for "Using filesort" (MySQL has to sort results without an index) and "Using temporary" (MySQL creates a temporary table). Both indicate potential performance problems on large datasets.

Running EXPLAIN from Laravel

You can use Eloquent's toSql() method to get the raw SQL, then run EXPLAIN through a database client. Or use the query builder's explain() method directly:

$results = Order::query()
    ->where('user_id', 42)
    ->where('status', 'pending')
    ->where('created_at', '>', '2026-01-01')
    ->orderByDesc('created_at')
    ->explain()
    ->get();

This returns the EXPLAIN output as a collection you can inspect or log.

Step 3: Common Slow Query Patterns and Fixes

Pattern 1: Missing Index on WHERE Columns

The problem:

Order::where('status', 'pending')->get();

Without an index on status, MySQL scans every row in the orders table.

The fix:

// Create a migration
Schema::table('orders', function (Blueprint $table) {
    $table->index('status');
});

Pattern 2: Composite WHERE Without a Composite Index

The problem:

Order::where('user_id', $userId)
    ->where('status', 'pending')
    ->orderByDesc('created_at')
    ->get();

Even with individual indexes on user_id, status, and created_at, MySQL can only use one index per table in a simple query. It picks the most selective one and scans the rest.

The fix:

Create a composite index that covers all three columns in the correct order:

Schema::table('orders', function (Blueprint $table) {
    $table->index(['user_id', 'status', 'created_at']);
});

Column order matters. Put equality conditions (user_id, status) before range conditions (created_at) and sort columns.

Pattern 3: Using `whereHas` with Complex Conditions

The problem:

Product::whereHas('reviews', function ($query) {
    $query->where('rating', '>=', 4);
})->get();

whereHas generates a correlated subquery that MySQL executes once per row in the outer table. On large tables, this is devastating.

The fix:

Use a JOIN instead:

Product::select('products.*')
    ->join('reviews', 'products.id', '=', 'reviews.product_id')
    ->where('reviews.rating', '>=', 4)
    ->distinct()
    ->get();

Or denormalize the data by adding a reviews_avg_rating column to the products table and updating it through an observer or event listener.

Pattern 4: Sorting Without an Index

The problem:

Post::where('published', true)
    ->orderByDesc('views_count')
    ->paginate(20);

If there's no index covering both the WHERE and ORDER BY columns, MySQL fetches all matching rows, then sorts them in memory. The "Using filesort" flag in EXPLAIN confirms this.

The fix:

Schema::table('posts', function (Blueprint $table) {
    $table->index(['published', 'views_count']);
});

Pattern 5: Selecting All Columns When You Need Few

The problem:

$users = User::all();
// Then in a Blade view:
@foreach($users as $user)
    {{ $user->name }}
@endforeach

You're loading every column (including potentially large text fields, JSON columns, and binary data) when you only need the name.

The fix:

$users = User::select(['id', 'name'])->get();

This reduces memory usage and network transfer between the database and application server. On tables with large text or json columns, the difference can be dramatic.

Pattern 6: Unbounded Queries

The problem:

$logs = ActivityLog::where('user_id', $userId)->get();

If a user has 50,000 activity log entries, this loads all 50,000 into memory at once.

The fix:

Use pagination or chunking:

// For display
$logs = ActivityLog::where('user_id', $userId)
    ->latest()
    ->paginate(25);

// For processing
ActivityLog::where('user_id', $userId)
    ->chunkById(500, function ($logs) {
        // Process 500 at a time
    });

Step 4: Prevent Regressions with Automated Detection

Laravel 12 lets you prevent lazy loading application-wide, turning N+1 problems into exceptions during development:

// bootstrap/app.php or a service provider
Model::preventLazyLoading(! app()->isProduction());

In production, you don't want exceptions crashing pages. Instead, log lazy loading violations:

Model::preventLazyLoading();

Model::handleLazyLoadingViolationUsing(function ($model, $relation) {
    $class = get_class($model);
    logger()->warning("Lazy loading [{$relation}] on model [{$class}].");
});

This gives you a log trail of N+1 problems to fix without disrupting users.

Step 5: Monitor Queries in Production with Deploynix

Development testing only goes so far. Your local database has a fraction of the data, the server has different resources, and traffic patterns create contention you can't simulate easily.

Deploynix's server monitoring tracks your MySQL process's CPU and memory usage in real-time. When a slow query starts consuming resources, you'll see it reflected in the database server's metrics before it causes user-facing issues.

Set up health alerts on your database server to notify you when MySQL CPU usage exceeds 80% for more than 5 minutes. This gives you a window to investigate before the query brings the server down.

Combine Deploynix's infrastructure monitoring with Laravel Pulse's slow query tracking in production. Pulse tells you which queries are slow. Deploynix tells you whether those slow queries are actually impacting server resources. A query that takes 500ms but runs twice a day is a low priority fix. A query that takes 200ms but runs 10,000 times per hour is an emergency — and Deploynix's CPU graphs will make that obvious.

Step 6: Establish a Query Performance Budget

Set concrete thresholds for your team:

Page load queries: Maximum 15 queries per page load
API endpoint queries: Maximum 10 queries per request
Individual query time: No single query over 100ms in development
Total query time per request: Under 50ms for 95% of requests

Enforce these through automated testing:

it('loads the dashboard in under 15 queries', function () {
    $user = User::factory()->create();

    $queryCount = 0;
    DB::listen(function () use (&$queryCount) {
        $queryCount++;
    });

    $this->actingAs($user)
        ->get('/dashboard')
        ->assertOk();

    expect($queryCount)->toBeLessThan(15);
});

This test fails when someone introduces an N+1 problem on the dashboard, catching it before code review.

Conclusion

Slow queries are inevitable as your application grows. What's not inevitable is letting them reach production undetected.

Use Debugbar and Telescope to catch problems during development. Analyze suspicious queries with EXPLAIN to understand exactly why they're slow. Apply the common fixes — proper indexing, eager loading, query restructuring. Prevent regressions with preventLazyLoading and query count tests. And monitor production with Deploynix to catch the queries that only become problems at scale.

The developers who deploy confidently aren't the ones who write perfect queries. They're the ones who have systems in place to find and fix imperfect queries before users feel the pain.

N+1 Query Detection and Prevention in Laravel Production Apps

Deploynix — Sat, 25 Apr 2026 09:00:06 +0000

The N+1 query problem is the most common performance issue in Laravel applications, and it's the easiest to introduce accidentally. A developer adds $post->author->name in a Blade template, and suddenly a page that loaded 10 posts now executes 11 database queries instead of 2. Scale that to 100 posts and you have 101 queries. Scale to a thousand and your database server is on fire.

What makes N+1 problems particularly insidious is that they're invisible during development. Your local database with 20 records responds instantly whether you execute 1 query or 100. The problem only becomes apparent in production where tables have millions of rows, query latency is higher, and database connections are shared across hundreds of concurrent requests.

This post covers everything you need to detect N+1 queries, prevent them from being introduced, and monitor for them in production Laravel applications.

Understanding the N+1 Problem

An N+1 query occurs when you load a collection of N models and then access a relationship on each model individually, triggering a separate query for each one.

Here's the classic example:

// Controller
$posts = Post::all(); // 1 query: SELECT * FROM posts

// Blade template
@foreach($posts as $post)
    {{ $post->author->name }} // N queries: SELECT * FROM users WHERE id = ?
@endforeach

The first query loads all posts. Then, for each post, Laravel lazy-loads the author relationship with a separate query. With 50 posts, that's 51 queries total.

The fix is eager loading — tell Laravel to load all authors in a single query upfront:

$posts = Post::with('author')->get(); // 2 queries total
// Query 1: SELECT * FROM posts
// Query 2: SELECT * FROM users WHERE id IN (1, 2, 3, ...)

Two queries instead of 51. The concept is simple. The challenge is applying it consistently across a growing codebase where relationships are accessed in controllers, views, components, API resources, and queued jobs.

Prevention: Laravel's preventLazyLoading

Laravel provides a built-in mechanism to catch N+1 problems during development. When enabled, any lazy-loaded relationship throws an exception:

// In a service provider's boot method
use Illuminate\Database\Eloquent\Model;

Model::preventLazyLoading(! app()->isProduction());

Now the $post->author->name call without eager loading throws a LazyLoadingViolationException instead of silently executing an extra query. This forces developers to explicitly eager-load every relationship they access.

Handling Violations in Production

You don't want exceptions crashing pages in production. Instead, log violations so you can fix them without disrupting users:

Model::preventLazyLoading();

Model::handleLazyLoadingViolationUsing(function ($model, $relation) {
    logger()->warning("N+1 detected: lazy loading [{$relation}] on [" . get_class($model) . "]");
});

This approach gives you the best of both worlds: hard failures in development that force immediate fixes, and silent logging in production that reveals problems you missed.

When preventLazyLoading Gets in the Way

There are legitimate cases where lazy loading is acceptable:

Artisan commands that process a single model and access one relationship
Queue jobs that operate on a known small dataset
Tinker sessions during debugging

You can selectively allow lazy loading on specific models:

// On a specific model
class Setting extends Model
{
    // Settings table is tiny; lazy loading is fine
    public $preventLazyLoading = false;
}

Or disable it temporarily in specific contexts:

Model::withoutPreventing(function () {
    // Lazy loading is allowed in this closure
    $user->profile->bio;
});

Eager Loading Patterns

Basic Eager Loading

The with() method accepts a single relationship or an array:

$posts = Post::with(['author', 'tags', 'comments'])->get();

Nested Eager Loading

Load relationships of relationships using dot notation:

$posts = Post::with(['comments.author', 'author.profile'])->get();
// Loads: posts, comments, comment authors, post authors, author profiles

Constrained Eager Loading

Filter or limit the eager-loaded relationship:

$posts = Post::with(['comments' => function ($query) {
    $query->where('approved', true)
          ->latest()
          ->limit(5);
}])->get();

Laravel 12 supports limit() on eager loads natively — no external packages needed.

Conditional Eager Loading

Load relationships only when certain conditions are met:

$posts = Post::query()
    ->when($includeComments, fn ($query) => $query->with('comments'))
    ->when($includeAuthor, fn ($query) => $query->with('author'))
    ->get();

Eager Loading on Existing Collections

If you already have a collection and need to load a relationship after the fact:

$posts = Post::all();

// Later, you realize you need authors
$posts->load('author');

// Or load only if not already loaded
$posts->loadMissing('author');

loadMissing() is particularly useful in deep call stacks where you're not sure if a relationship was already eager-loaded upstream.

Default Eager Loading on Models

If a relationship is always needed when a model is loaded, define it as a default:

class Post extends Model
{
    protected $with = ['author'];
}

Use this sparingly. It means every Post::all(), Post::find(), and Post::where(...) call loads the author relationship, even when it's not needed. This can turn a simple count query into a heavy join operation.

A better approach is to define scopes for common access patterns:

class Post extends Model
{
    public function scopeWithFeedRelations(Builder $query): Builder
    {
        return $query->with(['author', 'tags', 'comments' => function ($query) {
            $query->latest()->limit(3);
        }]);
    }
}

// Usage
$posts = Post::withFeedRelations()->latest()->paginate(20);

Detecting N+1 in Existing Code

Query Counting in Tests

Write tests that enforce query budgets:

it('loads the post index without N+1 queries', function () {
    $author = User::factory()->create();
    Post::factory()->count(20)->for($author, 'author')->create();

    $queryCount = 0;
    DB::listen(function () use (&$queryCount) {
        $queryCount++;
    });

    $this->actingAs($author)
        ->get('/posts')
        ->assertOk();

    expect($queryCount)->toBeLessThan(10);
});

If loading 20 posts requires more than 10 queries, something is lazy loading when it shouldn't be. This test catches regressions when someone adds a new relationship access in the view without updating the controller's eager loading.

Using Laravel Debugbar

Debugbar shows duplicate queries in its queries tab. If you see SELECT * FROM users WHERE id = ? repeated 20 times with different IDs, that's an N+1 problem on the author relationship.

Debugbar also shows the file and line where each query was triggered. This makes it trivial to trace the lazy load back to the specific Blade template line or component that caused it.

Using Telescope's Query Tab

Telescope groups queries by request. Look for requests with high query counts — anything above 20-30 queries per request warrants investigation. Sort by query count to find the worst offenders first.

Common N+1 Traps

Trap 1: Blade Components That Access Relationships

// app/View/Components/PostCard.php
public function render(): View
{
    return view('components.post-card');
}

// components/post-card.blade.php



## {{ $post->title }}

    by {{ $post->author->name }}  {{-- N+1 if author not eager-loaded --}}

The component looks harmless. The N+1 is hidden because the relationship access happens in the view, far from the controller that loaded the posts.

Fix: Ensure the parent view or controller eager-loads the relationship:

$posts = Post::with('author')->paginate(20);

Trap 2: API Resources with Nested Relationships

class PostResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id' => $this->id,
            'title' => $this->title,
            'author' => new UserResource($this->author), // N+1
            'comments_count' => $this->comments->count(), // N+1 AND loads all comments
        ];
    }
}

Fix: Eager-load in the controller and use withCount for counts:

$posts = Post::with('author')->withCount('comments')->paginate(20);

// In the resource:
'comments_count' => $this->comments_count, // Uses the aggregate, no extra query

Trap 3: Accessors That Touch Relationships

class Order extends Model
{
    protected function totalWithTax(): Attribute
    {
        return Attribute::get(fn () => $this->total * (1 + $this->taxRate->rate));
        // Accessing $this->taxRate triggers a lazy load
    }
}

Accessors are called during serialization, in Blade templates, and in API resources. Each call triggers the relationship query.

Fix: Eager-load taxRate wherever you use this accessor, or cache the relationship:

protected function totalWithTax(): Attribute
{
    return Attribute::get(function () {
        $rate = $this->relationLoaded('taxRate')
            ? $this->taxRate
            : $this->taxRate()->first();

        return $this->total * (1 + $rate->rate);
    });
}

Trap 4: Queued Jobs Processing Collections

class SendWeeklyDigest implements ShouldQueue
{
    public function handle(): void
    {
        User::where('digest_enabled', true)->chunk(100, function ($users) {
            foreach ($users as $user) {
                // Each of these triggers a query
                $recentPosts = $user->subscriptions->flatMap->posts;
                Mail::to($user)->send(new WeeklyDigest($recentPosts));
            }
        });
    }
}

Fix:

User::where('digest_enabled', true)
    ->with(['subscriptions.posts' => function ($query) {
        $query->where('created_at', '>', now()->subWeek());
    }])
    ->chunk(100, function ($users) {
        foreach ($users as $user) {
            $recentPosts = $user->subscriptions->flatMap->posts;
            Mail::to($user)->send(new WeeklyDigest($recentPosts));
        }
    });

Monitoring in Production

Even with preventLazyLoading and test coverage, N+1 problems can slip through. Monitor query counts in production using multiple layers.

Laravel Pulse

Pulse tracks slow queries and high-frequency queries in production. A query that appears hundreds of times per minute with slight parameter variations is likely an N+1 problem. Check Pulse's slow queries dashboard regularly.

Deploynix Server Monitoring

On Deploynix, monitor your database server's CPU and connection count. A sudden increase in active connections often correlates with N+1 queries — each lazy-loaded query opens and closes a connection (or holds one from the pool). If your connection count spikes during peak traffic, investigate the most active endpoints for N+1 issues.

Deploynix's real-time monitoring dashboard shows MySQL process CPU usage alongside your application server's metrics. When the database CPU spikes but the application CPU stays flat, the cause is almost always excessive queries — and N+1 is the most likely culprit.

Custom Middleware for Query Counting

Add middleware that logs requests exceeding a query threshold:

class QueryCountMiddleware
{
    public function handle(Request $request, Closure $next): Response
    {
        $queryCount = 0;
        DB::listen(function () use (&$queryCount) {
            $queryCount++;
        });

        $response = $next($request);

        if ($queryCount > 30) {
            logger()->warning("High query count: {$queryCount} queries", [
                'url' => $request->fullUrl(),
                'method' => $request->method(),
            ]);
        }

        return $response;
    }
}

Conclusion

N+1 queries are the single most impactful performance problem in Laravel applications, and they're entirely preventable. Enable preventLazyLoading to catch them during development. Write query-count tests to prevent regressions. Use with(), loadMissing(), and withCount() consistently.

In production, monitor query patterns through Pulse and watch for database CPU spikes on your Deploynix dashboard. The combination of prevention at the code level and detection at the infrastructure level means N+1 problems get caught before they become outages.

The goal isn't zero lazy loading — it's intentional lazy loading. Every relationship access should be a deliberate choice, not an accidental database round trip hiding in a Blade component three levels deep.

Laravel Telescope vs. Pulse vs. Deploynix Monitoring: Which Do You Need?

Deploynix — Sat, 25 Apr 2026 00:32:04 +0000

Laravel developers in 2026 have three mature monitoring options, each built for a different layer of the stack. Telescope gives you a microscope into individual requests. Pulse gives you a dashboard for application-level trends. Deploynix monitoring gives you infrastructure-level visibility with health alerting.

The question isn't which one is best. The question is which combination you need — because they're not competitors. They're complementary tools that, when used together, give you complete observability from the server hardware up through individual Eloquent queries.

This post breaks down what each tool does, where they overlap, how they differ in performance overhead, and which setup makes sense based on your application's size and stage.

What Each Tool Actually Does

Before comparing features, it helps to understand the fundamental design philosophy behind each tool.

Laravel Telescope: The Development Debugger

Telescope is a debugging assistant. It records every request, exception, database query, queued job, mail, notification, cache operation, and scheduled task that your application processes. You browse this data through a web dashboard that lets you inspect individual entries in detail.

Telescope answers questions like: What exact SQL queries did this request execute? What was the payload of this queued job that failed? Why did this notification take 3 seconds to send?

It shines during development and staging. In production, its recording overhead and storage requirements make it impractical for high-traffic applications unless heavily filtered.

Laravel Pulse: The Application Dashboard

Pulse is an application performance monitoring tool. Instead of recording every individual event, it aggregates data into trends and surfaces the metrics that matter: slowest requests, most frequent queries, queue throughput, cache hit rates, and active user counts.

Pulse answers questions like: Which endpoints are consistently slow this week? Are my queue workers keeping up with job volume? What's my cache hit ratio trending toward?

It's designed for production use. Its aggregation approach keeps storage requirements manageable, and its sampling capabilities let you control the performance overhead.

Deploynix Monitoring: The Infrastructure Layer

Deploynix monitoring operates at the server and site level. It tracks CPU usage, memory consumption, disk I/O, network throughput, and disk space across all your managed servers. It provides real-time alerts when metrics cross thresholds you define.

Deploynix answers questions like: Is the server running out of memory? Has CPU usage been sustained above 90% for the last hour? Is the application responding to HTTP requests? When did disk usage cross the warning threshold?

It doesn't know about your Laravel application's internals — it doesn't see individual queries or jobs. But it sees everything happening at the operating system level, which is exactly the layer you need visibility into when your application monitoring tools report that "everything looks fine" but users are experiencing slowness.

Feature Comparison

Here's a direct comparison of what each tool monitors:

Capability

Telescope

Pulse

Deploynix

Individual request inspection

Yes

Request performance trends

Yes

Database query logging

Yes (all)

Yes (slow)

Exception tracking

Yes

Queue job inspection

Yes

Cache operations

Yes

CPU/Memory monitoring

Yes

Disk space alerts

Yes

Server health monitoring

Yes

Real-time server metrics

Yes

Mail/notification logging

Yes

Model event tracking

Yes

Gate/policy inspection

Yes

Health check alerting

Yes

User activity tracking

Yes

Performance percentiles

Yes

The overlap is minimal. Telescope and Pulse both track queries and exceptions, but in fundamentally different ways. Telescope records every single query for later inspection. Pulse aggregates query performance into trends and highlights outliers. Deploynix doesn't touch queries at all — it watches the MySQL process's resource consumption from the OS level.

Performance Overhead

This is where the differences matter most in production.

Telescope's Overhead

Telescope's default configuration records everything. Every request generates multiple database inserts for the request entry, query entries, model entries, and any other watchers you have enabled. On a high-traffic application, this creates significant database load.

You can mitigate this with selective recording:

// app/Providers/TelescopeServiceProvider.php
public function register(): void
{
    Telescope::filter(function (IncomingEntry $entry) {
        if ($this->app->environment('local')) {
            return true;
        }

        return $entry->isReportableException() ||
               $entry->isFailedRequest() ||
               $entry->isFailedJob() ||
               $entry->isSlowQuery() ||
               $entry->isScheduledTask();
    });
}

Even with filtering, Telescope adds measurable overhead per request because the filtering logic itself runs on every request. For applications handling hundreds of requests per second, this matters.

Recommendation: Enable Telescope fully in local and staging environments. In production, either disable it entirely or filter aggressively to only capture failures.

Pulse's Overhead

Pulse was designed for production from day one. It uses an aggregation pipeline that batches metrics before writing them to the database, reducing write frequency dramatically compared to Telescope.

Pulse also supports sampling — you can tell it to only record every Nth request:

// config/pulse.php
'sample_rate' => 0.1, // Record 10% of requests

At a 10% sample rate, Pulse gives you statistically meaningful trend data with a fraction of the overhead. The aggregated storage is also much smaller — Pulse automatically prunes old data based on configurable retention periods.

Recommendation: Run Pulse in production with sampling enabled. A 10-25% sample rate provides excellent trend data for most applications.

Deploynix's Overhead

Deploynix monitoring runs at the OS level, completely outside your Laravel application. It uses lightweight system agents that collect metrics from /proc, sysstat, and similar system interfaces. Your application doesn't execute a single extra line of PHP.

The HTTP health check adds one request every 30-60 seconds (configurable), which is negligible on any application.

Recommendation: Always enable Deploynix monitoring. There's no meaningful overhead to your application.

Recommended Setups by Application Size

Solo Developer / Side Project

Use: Deploynix monitoring only.

When you're launching an MVP or running a small project, you don't need application-level monitoring yet. Deploynix's built-in server monitoring and health alerts will tell you if something goes catastrophically wrong. Use Telescope locally during development to debug issues, but don't bother installing it in production.

At this stage, your time is better spent building features than configuring monitoring dashboards. Deploynix handles the infrastructure concerns so you don't have to SSH into servers to check disk space or CPU usage.

Growing Application (1,000+ Daily Users)

Use: Deploynix monitoring + Pulse.

Once your application serves real traffic consistently, you need trend data. Pulse shows you which endpoints are slowing down, whether your cache strategy is working, and if queue processing is keeping pace with demand.

Install Pulse with a 25% sample rate:

'sample_rate' => 0.25,

This gives you solid performance data without measurable overhead. Combined with Deploynix's server metrics, you can correlate application slowness (Pulse) with infrastructure bottlenecks (Deploynix).

For example, Pulse might show that your /api/reports endpoint's P95 response time jumped from 200ms to 1,200ms. Deploynix's server monitoring might simultaneously show that MySQL's CPU usage spiked to 95%. Now you know the problem is a database query issue on that endpoint, not a code regression or memory leak.

Production Application (10,000+ Daily Users)

Use: Deploynix monitoring + Pulse + Telescope (filtered).

At this scale, you need all three layers. Pulse gives you the trends. Deploynix gives you infrastructure alerting. And Telescope — heavily filtered to only capture failures and slow queries — gives you the detailed forensics you need when something goes wrong.

Configure Telescope to only record problems:

Telescope::filter(function (IncomingEntry $entry) {
    return $entry->isReportableException() ||
           $entry->isFailedRequest() ||
           $entry->isFailedJob() ||
           $entry->type === EntryType::SLOW_QUERY;
});

When Pulse's dashboard shows a spike in slow requests, switch to Telescope to inspect the individual queries and request payloads that caused it. When Deploynix alerts you to high memory usage, check Pulse to see if a particular endpoint is processing larger payloads than usual.

High-Traffic Application (100,000+ Daily Users)

Use: Deploynix monitoring + Pulse (low sample rate) + dedicated APM.

At very high traffic volumes, consider adding a dedicated APM service (New Relic, Datadog, or similar) alongside Pulse and Deploynix. Telescope's database storage model doesn't scale well at this level even with aggressive filtering.

Run Pulse at a 5-10% sample rate for trend data. Use Deploynix for infrastructure monitoring and alerting. Let your APM handle the detailed request tracing that Telescope would otherwise provide.

Making Them Work Together

The real power emerges when you use these tools as a unified observability stack rather than isolated dashboards.

Triage workflow:

Deploynix alerts you that a server's CPU has been above 90% for 10 minutes.
Open Pulse to check which endpoints or queues are consuming the most resources.
If Pulse points to a specific endpoint, open Telescope to inspect recent requests to that endpoint and find the problematic query or operation.
Fix the issue, deploy through Deploynix, and watch all three dashboards confirm the resolution.

Performance investigation workflow:

Pulse shows P95 response time increasing over the past week.
Drill into Pulse's slow queries tab to identify which queries are degrading.
Check Deploynix's server metrics to see if the database server's disk I/O is saturated.
If disk I/O is the bottleneck, use Deploynix to scale up the database server or add read replicas.

Configuration Tips

Don't Run Telescope and Pulse on the Same Database

Both tools write monitoring data to your database. In production, configure them to use a separate database connection to avoid their writes competing with your application's queries:

// config/pulse.php
'storage' => [
    'driver' => 'database',
    'connection' => 'pulse',
],

// config/database.php
'pulse' => [
    'driver' => 'mysql',
    'host' => env('PULSE_DB_HOST', '127.0.0.1'),
    'database' => env('PULSE_DB_DATABASE', 'pulse'),
    // ...
],

Set Retention Policies

Both Telescope and Pulse accumulate data. Configure pruning to prevent storage from growing unbounded:

// Telescope: prune entries older than 48 hours
$schedule->command('telescope:prune --hours=48')->daily();

// Pulse: configure in config/pulse.php
'retain' => [
    'entries' => 7 * 24 * 60, // 7 days in minutes
    'aggregates' => 90 * 24 * 60, // 90 days in minutes
],

Use Deploynix's Monitoring for Alerting

Neither Telescope nor Pulse has built-in alerting. They're dashboards you check, not systems that notify you. Deploynix fills this gap with health alerts that trigger notifications when your servers or sites enter unhealthy states.

Pair Deploynix's server-level health alerts with an external uptime monitoring service that polls your custom health check endpoint, and you get alerts that combine infrastructure metrics with application health data.

Conclusion

Telescope, Pulse, and Deploynix monitoring aren't competing solutions — they're complementary layers of a complete observability stack. Telescope gives you the microscope for debugging individual issues. Pulse gives you the dashboard for tracking application performance trends. Deploynix gives you the infrastructure monitoring and alerting foundation that the other two are built on top of.

Start with Deploynix monitoring on every server. Add Pulse when you need application-level trend data. Layer in Telescope when you need forensic debugging capabilities in production. Together, they give you visibility from the CPU cores up through individual database queries — and the confidence that you'll know about problems before your users do.

Custom Health Check Endpoints for Laravel: Beyond 200 OK

Deploynix — Thu, 23 Apr 2026 10:00:06 +0000

Every Laravel application ships with a default route that returns a 200 OK response. It tells you the web server is running. It tells you PHP is alive. And it tells you absolutely nothing about whether your application is actually healthy.

A returning customer can't complete checkout if your Redis connection dropped. Your API consumers get cryptic 500 errors when the database connection pool is exhausted. Your queue workers silently stopped processing jobs three hours ago, and nobody noticed because your uptime monitor keeps reporting "all clear."

Sound familiar? The problem is that most health checks are superficial. They verify the application process is running without confirming the application is actually working. In this post, we'll build a comprehensive health check endpoint that validates every critical dependency your Laravel application relies on — and integrate it with Deploynix's monitoring to get alerts before your users notice problems.

Why a Simple 200 OK Isn't Enough

A basic health check route like this is dangerously misleading:

Route::get('/health', fn () => response('OK', 200));

This route will return 200 even when your database is down, your cache server is unreachable, your queue workers have crashed, your disk is 99% full, and your payment gateway API is timing out.

A proper health check should verify the entire dependency chain your application needs to function correctly. When any critical component fails, your monitoring system should know about it immediately — not when a customer opens a support ticket.

Designing Your Health Check Architecture

Before writing code, think about what "healthy" means for your specific application. Most Laravel applications depend on some combination of database connectivity, cache availability, queue processing, filesystem access, and external API reachability.

We'll build a health check system with two tiers: a lightweight liveness probe that confirms the application process is running, and a comprehensive readiness probe that validates all dependencies.

// routes/api.php

Route::get('/health/live', [HealthCheckController::class, 'liveness']);
Route::get('/health/ready', [HealthCheckController::class, 'readiness']);

The liveness endpoint stays simple and fast. Load balancers and container orchestrators use it to determine if the process should be restarted. The readiness endpoint does the heavy lifting.

Building the Health Check Controller

Start by generating a controller dedicated to health checks:

php

Laravel Deployment for Beginners: What Actually Happens When You Click Deploy

Deploynix — Wed, 22 Apr 2026 22:00:08 +0000

You have been building your Laravel application on your laptop for weeks. Everything works perfectly on localhost. The features are done, the pages look great, and your tests pass. Now you want to put it on the internet so real people can use it. You click "Deploy" in Deploynix, a progress bar fills up, and 60 seconds later your application is live.

But what actually happened during those 60 seconds? What did Deploynix do to take your code from a GitHub repository and turn it into a working website? Understanding the deployment process demystifies one of the most intimidating parts of web development. Once you know what is happening under the hood, deployments stop being scary and start being routine.

This guide walks through every step of a Laravel deployment in plain language. No jargon, no assumptions about your experience level. If you can build a Laravel app, you can understand how it gets deployed.

Before Deployment: What Your Server Looks Like

Before you ever deploy your application, Deploynix has already set up your server with everything Laravel needs to run. Think of your server as a computer in a data center that is always on, always connected to the internet, and always waiting to serve your website.

When Deploynix provisions a server, it installs and configures:

The operating system: Ubuntu Linux, which is the most common operating system for web servers.
PHP: The programming language that Laravel is written in. Deploynix installs the exact version your application needs.
A web server (Nginx): Software that listens for incoming web requests and routes them to your Laravel application. When someone types your domain name into their browser, Nginx is the first piece of software that responds.
A database (MySQL, MariaDB, or PostgreSQL): Where your application stores its data, such as user accounts, posts, orders, and anything else you save to the database.
Composer: The tool that manages your PHP dependencies, which are the packages and libraries your Laravel application uses.
Node.js and npm: Tools for compiling your frontend assets, things like CSS and JavaScript that your browser needs to display your pages.

All of this setup happens once, when you first provision the server. After that, deploying your application is about getting your code onto this server and configuring it to run.

Step 1: Getting Your Code from GitHub

The first thing that happens when you click Deploy is that Deploynix copies your application's code from your Git repository (GitHub, GitLab, or Bitbucket) to your server.

You have been pushing code to your repository every time you commit changes. Your repository contains everything that makes up your application: the PHP files, the Blade templates, the JavaScript, the configuration files, and the migration files. It is the single source of truth for what your application looks like at any given moment.

Deploynix connects to your repository and downloads the latest version of your code to the server. This is similar to what happens when you run git clone on your laptop, except Deploynix is doing it on your server.

But here is an important detail: Deploynix does not just dump the code into the same folder every time. It creates a brand new folder for each deployment. If today is your fifth deployment, there are five separate folders on your server, one for each version of your code. We will explain why this matters in a later step.

Step 2: Installing PHP Dependencies

Your Laravel application depends on dozens of packages written by other developers. Things like the Laravel framework itself, the database driver, the authentication system, and any other packages you have added with composer require. These dependencies are listed in your composer.json file but are not stored in your Git repository (the vendor folder is in your .gitignore).

After downloading your code, Deploynix runs composer install on the server. This reads your composer.json and composer.lock files, downloads every package your application needs, and puts them in the vendor folder.

This step uses the composer.lock file, not just composer.json. The lock file records the exact version of every package that was installed on your development machine. This ensures that the server installs the same versions you tested with, not newer versions that might behave differently. Consistency between your development environment and production is critical.

In production, Deploynix passes the --no-dev flag to Composer, which tells it to skip development-only dependencies. Things like Pest (your testing framework) and Laravel Pint (your code formatter) are not needed on a production server, so skipping them makes the installation faster and the application lighter.

Step 3: Installing and Building Frontend Assets

If your application uses Tailwind CSS, Alpine.js, or any other frontend tools managed through npm, the next step is installing those JavaScript dependencies and compiling your assets.

Deploynix runs npm install (or npm ci) to download the JavaScript packages listed in your package.json file. Then it runs npm run build to compile everything into the final CSS and JavaScript files that browsers can understand.

During development, you might have been running npm run dev, which watches for file changes and recompiles on the fly. In production, npm run build creates optimized, minified versions of your assets. Minification removes whitespace, shortens variable names, and compresses the files so they are as small as possible. Smaller files mean faster page loads for your users.

The compiled files typically end up in your public/build folder. These are the files that Nginx will serve directly to browsers when they request your CSS and JavaScript.

Step 4: Setting Up the Environment File

Your Laravel application uses a .env file to store configuration that varies between environments. On your laptop, the .env file points to your local database, uses the local app environment, and shows detailed error messages. In production, the configuration is different.

Deploynix manages your production environment variables through its dashboard. You set values like your database credentials, your application key, your mail server settings, and any API keys your application needs. Deploynix stores these securely and makes them available to your application through the .env file on the server.

Some important differences between your local .env and your production .env:

APP_ENV is set to production instead of local.
APP_DEBUG is set to false so that error details are not shown to users. In development, seeing a full stack trace is helpful. In production, it would expose sensitive information.
APP_URL points to your actual domain name instead of localhost.
Database credentials point to your production database server.
APP_KEY is a unique encryption key that Laravel uses to encrypt cookies, sessions, and other sensitive data.

The .env file is never stored in your Git repository (it is in .gitignore). This is intentional. You do not want production database passwords in your code repository.

Step 5: Running Database Migrations

Your application's database starts empty. The structure of your database (the tables, the columns, the indexes) is defined in migration files. Migrations are PHP files in your database/migrations folder that describe each change to your database schema.

When Deploynix deploys your application, it runs php artisan migrate to apply any new migrations. This command looks at which migrations have already been run (Laravel tracks this in a special migrations table in your database) and runs only the new ones.

For example, if your previous deployment had 15 migrations and you have since added a 16th migration that adds a phone_number column to the users table, the migrate command will only run that 16th migration. The other 15 are already reflected in the database.

Migrations are run in order, based on the timestamp in their filename. This ensures that the database structure evolves predictably and consistently, whether you are deploying for the first time or the hundredth time.

This step is one of the few parts of deployment that can cause problems if something goes wrong. A migration that fails halfway through can leave your database in an inconsistent state. This is why it is important to test your migrations thoroughly before deploying.

Step 6: Caching Configuration, Routes, and Views

Laravel is a feature-rich framework, and loading all of its configuration, routes, and views from scratch on every request takes time. To make your application faster in production, Deploynix runs several caching commands:

php artisan config:cache compiles all of your configuration files into a single cached file. Instead of reading dozens of configuration files on every request, Laravel reads one file.
php artisan route:cache compiles your route definitions into a format that Laravel can load faster. If you have dozens or hundreds of routes, this makes a noticeable difference.
php artisan view:cache pre-compiles your Blade templates into plain PHP. Normally, Laravel compiles Blade templates the first time they are requested. Caching them ahead of time means the first visitor to any page gets the same fast response as the thousandth visitor.

These caches are rebuilt on every deployment so they always reflect your latest code.

Step 7: The Symlink Swap (Zero-Downtime Magic)

Remember how we said that Deploynix creates a new folder for each deployment? Here is why.

Your web server (Nginx) is configured to serve your application from a specific path, something like /home/deploynix/yoursite.com/current. But current is not a regular folder. It is a symlink (short for symbolic link), which is essentially a shortcut that points to another folder.

Right now, current points to the folder containing your previous deployment's code. All of the steps we have discussed so far (downloading code, installing dependencies, running migrations) happened in a new folder. Your previous version of the application has been running the entire time, serving requests to your users without interruption.

Once everything in the new folder is ready, Deploynix updates the current symlink to point to the new folder. This change is atomic, meaning it happens in a single instant. One moment, Nginx is serving the old code. The next moment, it is serving the new code. There is no gap, no moment where the application is unavailable, no half-old-half-new state.

This is what "zero-downtime deployment" means. Your users never see an error page or a loading spinner during deployment. They just seamlessly start seeing the new version of your application.

The old deployment folders are kept around for a while in case you need to roll back. If something goes wrong with the new deployment, Deploynix can switch the symlink back to the previous folder in seconds, instantly reverting to the last working version.

Step 8: Restarting Workers and Services

Some parts of your Laravel application run continuously in the background, not just when a user visits a page.

Queue workers process jobs that you have queued for background execution. Things like sending emails, processing uploaded images, or generating reports. These workers load your application code into memory when they start and keep running until they are told to stop.

After a deployment, the queue workers are still running the old version of your code. Deploynix restarts them so they pick up the new code. This restart is done gracefully: the worker finishes processing its current job, then restarts with the new code. No jobs are lost or interrupted.

Cron jobs (scheduled tasks) are managed by Laravel's task scheduler. If you have scheduled commands defined in your application, they continue running on the server's schedule. The next time a scheduled task runs, it automatically uses the new code because it runs fresh through the current symlink.

Step 9: Your Application Is Live

After all of these steps complete, your application is live and serving the latest version of your code. The entire process typically takes between 30 and 90 seconds, depending on the size of your application and the number of dependencies.

Here is a summary of what happened:

Your code was downloaded from GitHub to a new folder on the server.
PHP dependencies were installed with Composer.
Frontend assets were compiled with npm.
The environment configuration was applied.
New database migrations were run.
Configuration, routes, and views were cached.
The symlink was swapped to point to the new code.
Background workers were restarted.

Every subsequent deployment follows the same steps. The process is the same whether it is your second deployment or your two hundredth.

What Happens When Something Goes Wrong

Deployments can fail. A migration might have a bug. A Composer dependency might not install correctly. The build step might encounter an error. When this happens, Deploynix stops the deployment before the symlink swap.

This is the beauty of the release-folder approach. If something fails during steps 1 through 6, the symlink never changes. Your previous deployment is still running, still serving users, completely unaffected. The failed deployment folder sits there harmlessly, and you can investigate what went wrong without any pressure because your application is still live.

If a problem is discovered after the symlink swap (maybe a page throws an error that was not caught during testing), you can use Deploynix's rollback feature. Rolling back switches the symlink back to the previous deployment folder. It takes a few seconds, and your application is back to the last known good version.

Deploying Updates

After your first deployment, every subsequent deployment is the same process. You make changes to your code on your laptop, commit them to Git, push them to GitHub, and deploy through Deploynix. You can deploy manually by clicking the Deploy button in the dashboard, or you can set up automatic deployments that trigger whenever you push to a specific branch.

Most teams set up automatic deployments for their main branch. The workflow becomes: write code, open a pull request, get it reviewed, merge it, and the deployment happens automatically. You can also schedule deployments for specific times using Deploynix's scheduled deployment feature, which is useful for changes that should go live during low-traffic hours.

The Big Picture

Deployment is the bridge between building your application and sharing it with the world. Understanding what happens during deployment makes you a more confident developer. When you know that the symlink swap is what prevents downtime, you can explain it to your team. When you know that migrations run in order, you can write them with confidence. When you know that the .env file is separate from your code, you understand why it is safe to push your code to a public repository.

Deploynix automates all of these steps so you can focus on building your application rather than managing servers. But automation works best when you understand what is being automated. Now you do. Go deploy something.

WebSockets 101 for Laravel Developers: From Concept to Production on Deploynix

Deploynix — Wed, 22 Apr 2026 10:00:05 +0000

Most web applications are built on a simple model: the browser sends a request, the server processes it, the server sends a response, and the connection closes. This request-response cycle has powered the web for decades, and it works perfectly for the vast majority of interactions. But there are moments when it falls short.

Imagine a project management app where multiple team members are viewing the same task board. Alice moves a task from "In Progress" to "Done." Bob, who is looking at the same board, does not see the change until he refreshes the page. In a traditional HTTP application, Bob's browser has no way to know that something changed on the server. It would have to poll repeatedly, asking the server "did anything change?" every few seconds, which is wasteful and introduces latency.

WebSockets solve this problem elegantly. Instead of closing the connection after each request-response cycle, a WebSocket connection stays open. The server can push data to the browser the instant something happens, without the browser asking. Alice moves the task, the server broadcasts the change, and Bob's browser updates in real time.

This guide takes you from zero WebSocket knowledge to a working real-time feature in your Laravel application, deployed and running on Deploynix.

How WebSockets Work

A WebSocket connection starts as a regular HTTP request. The browser sends an HTTP request with a special Upgrade header that says "I would like to switch to the WebSocket protocol." If the server supports WebSockets, it responds with a 101 status code (Switching Protocols), and the connection transitions from HTTP to WebSocket.

Once the connection is upgraded, it becomes a full-duplex communication channel. Both the browser and the server can send messages at any time, independently of each other. The connection remains open until either side explicitly closes it, or a network interruption occurs.

The key differences from regular HTTP:

Persistent: The connection stays open for the duration of the session. No repeated handshakes, no connection overhead for each message.
Bidirectional: The server can push data to the client without the client requesting it. The client can also send data to the server at any time.
Low latency: Messages are delivered in milliseconds because there is no connection setup for each message.
Low overhead: WebSocket frames have minimal headers compared to HTTP requests, so the per-message overhead is tiny.

WebSockets are ideal for features like live notifications, real-time dashboards, chat applications, collaborative editing, live activity feeds, and any situation where users need to see changes as they happen.

Laravel Broadcasting: The Framework Layer

Laravel does not ask you to work with raw WebSocket connections. Instead, it provides a Broadcasting system that abstracts the complexity into a clean, event-driven API. You define events in PHP, broadcast them, and listen for them in JavaScript. Laravel handles the plumbing.

The broadcasting system has three components:

Events: Standard Laravel events that implement the ShouldBroadcast or ShouldBroadcastNow interface. When these events are dispatched, Laravel serializes their public properties and sends them to the broadcasting driver.

Channels: Named channels that organize broadcasts. Laravel supports three types:

Public channels that anyone can listen to.
Private channels that require authentication. The server verifies that the user is authorized to listen on the channel before allowing the connection.
Presence channels that are private channels with the additional ability to see who else is listening. These are perfect for showing "who's online" indicators.

Laravel Echo: A JavaScript library that connects to the WebSocket server and provides a clean API for subscribing to channels and listening for events.

Reverb vs. Third-Party Services

Before Reverb, Laravel developers had two main options for WebSocket infrastructure: Pusher (a paid, hosted service) and laravel-websockets (a community package that ran a WebSocket server alongside your Laravel app). Each had trade-offs.

Pusher is easy to set up but introduces a third-party dependency, ongoing costs, and the latency of routing messages through an external service. The laravel-websockets package kept everything in-house but was a community project with varying maintenance and could be tricky to run reliably in production.

Laravel Reverb changed the equation. Reverb is a first-party Laravel package, maintained by the Laravel team, that provides a high-performance WebSocket server designed specifically for Laravel Broadcasting. It runs on your own servers, so there is no third-party dependency, no per-message pricing, and no added latency from routing through an external service.

Reverb is built on ReactPHP and handles thousands of concurrent connections efficiently. It integrates seamlessly with Laravel's authentication system for private and presence channels, and it works out of the box with Laravel Echo.

For most Laravel applications deploying on Deploynix, Reverb is the clear choice. You get full control over your WebSocket infrastructure, zero external dependencies, and first-party support from the Laravel team.

Setting Up Reverb in Your Laravel Application

Let's walk through adding Reverb to an existing Laravel application.

Step 1: Install Reverb

Install Reverb using the Artisan installer:

php artisan install:broadcasting

This command installs the Reverb package, publishes the configuration file, adds the necessary environment variables to your .env file, and installs the JavaScript dependencies (Laravel Echo and the Pusher JS client, which Echo uses as its WebSocket client library).

Step 2: Configure Environment Variables

After installation, your .env file will have new Reverb-related variables:

BROADCAST_CONNECTION=reverb

REVERB_APP_ID=your-app-id
REVERB_APP_KEY=your-app-key
REVERB_APP_SECRET=your-app-secret
REVERB_HOST="localhost"
REVERB_PORT=8080
REVERB_SCHEME=https

In development, localhost is fine. For production on Deploynix, you will configure these differently (we will cover that in the deployment section).

Step 3: Create a Broadcastable Event

Create an event that implements ShouldBroadcastNow:

php