DEV Community: Deploynix

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

Why Your Laravel App's Emails Land in Spam (and How to Fix It on Deploynix)

Deploynix — Tue, 21 Apr 2026 22:00:06 +0000

You spent an hour crafting the perfect welcome email. The copy is warm, the design is clean, and the call-to-action is compelling. A new user signs up for your Laravel application, your Mailable fires, the queue job processes successfully, and your logs confirm the email was sent. But the user never sees it. It is sitting in their spam folder, sandwiched between a Nigerian prince and a dubious pharmaceutical offer.

Email deliverability is one of those problems that is invisible until it is catastrophic. Your Laravel application can send emails perfectly from a technical standpoint, the SMTP transaction completes, the mail server accepts the message, and everything looks green in your logs. But email providers like Gmail, Outlook, and Yahoo make the final decision about where your message lands, and they are ruthlessly aggressive about filtering anything that looks remotely suspicious.

This guide explains why your emails are landing in spam and gives you concrete steps to fix it, with specific guidance for Laravel applications running on Deploynix-managed servers.

The Three Pillars of Email Authentication

Modern email deliverability rests on three authentication protocols that work together to prove you are who you say you are. If any of these are missing or misconfigured, email providers will treat your messages with suspicion. All three are DNS records, which means you need access to your domain's DNS management.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which servers are authorized to send email on behalf of your domain. When Gmail receives an email claiming to be from notifications@yourapp.com, it checks the SPF record for yourapp.com to see if the sending server's IP address is authorized.

An SPF record is a TXT record on your domain that lists authorized senders. Here is what it looks like for common email providers:

# If using Postmark
v=spf1 include:spf.mtasv.net ~all

# If using Mailgun
v=spf1 include:mailgun.org ~all

# If using Amazon SES
v=spf1 include:amazonses.com ~all

# If using multiple providers
v=spf1 include:spf.mtasv.net include:mailgun.org ~all

The ~all at the end means "soft fail for anything not listed," which tells receivers to be suspicious of unauthorized senders but not outright reject them. Some guides recommend -all (hard fail), but ~all is generally safer while you are setting things up to avoid accidentally blocking legitimate mail.

Common mistake: If you are sending email directly from your Deploynix server using sendmail or a local SMTP server, your server's IP address needs to be in the SPF record. This is one of the many reasons we recommend using a dedicated email delivery service instead.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to your outgoing emails that proves the message was actually sent by an authorized sender and was not modified in transit. The sending server signs the email with a private key, and the receiving server verifies the signature using a public key published in your DNS records.

Your email delivery provider generates the DKIM keys and gives you the DNS record to publish. The record looks something like this:

# DKIM record (type: TXT)
# Host: default._domainkey.yourapp.com
# Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB...

In Laravel, you do not interact with DKIM directly in your application code. It is handled at the mail server level. When you configure your Laravel application to send through Postmark, Mailgun, SES, or another provider, that provider handles DKIM signing automatically. Your responsibility is publishing the correct DKIM DNS record that the provider gives you.

Common mistake: DKIM records are often long and can get truncated if your DNS provider has character limits on TXT records. Some providers require you to split the record across multiple strings. Verify the full record is published correctly using a tool like dig TXT default._domainkey.yourapp.com.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also provides a reporting mechanism so you can see who is sending email using your domain, whether legitimately or not.

A basic DMARC record looks like this:

# DMARC record (type: TXT)
# Host: _dmarc.yourapp.com
# Value: v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com

The p=none policy means "monitor only." This is the right starting point. It tells receivers to deliver all messages regardless of authentication results but send you reports so you can see what is happening.

Once you have verified that your legitimate emails all pass SPF and DKIM, tighten the policy:

p=quarantine tells receivers to send failing messages to spam.
p=reject tells receivers to outright reject failing messages.

Moving from none to quarantine to reject should be a gradual process. Start with none, analyze the reports for a few weeks, fix any authentication issues, then move to quarantine, and eventually reject.

Common mistake: Setting p=reject immediately without monitoring first. If there is a service you forgot about that sends email using your domain (a CRM, a helpdesk, a marketing automation tool), p=reject will cause all of its emails to bounce.

Reverse DNS (PTR Records)

Reverse DNS maps an IP address back to a hostname. When a mail server receives a connection, it performs a reverse DNS lookup on the connecting IP to verify that the IP address resolves back to a legitimate hostname. If reverse DNS is not configured or resolves to a generic hostname like 123.456.789.0.generic.provider.com, that is a spam signal.

For emails sent through a dedicated email delivery service (Postmark, Mailgun, SES), the provider handles reverse DNS for their own servers. You do not need to configure anything.

However, if you are sending email directly from your Deploynix-managed server, reverse DNS matters. Deploynix provisions servers on cloud providers like DigitalOcean, Vultr, Hetzner, Linode, and AWS. Each provider has a different process for setting PTR records:

DigitalOcean: PTR is automatically set to the Droplet's name. Name your server with your domain (e.g., mail.yourapp.com).
Vultr: Configure PTR through the Vultr control panel under the server's settings.
Hetzner: Configure PTR through the Hetzner Cloud Console or API.
Linode: PTR is set through the Linode Manager's networking section.
AWS: Request a PTR record through AWS support for EC2 instances.

But here is the real advice: do not send email directly from your application server. Use a dedicated email delivery service. The rest of this guide assumes you will follow that advice.

Why You Should Not Send Email from Your Server

It is technically possible to configure Postfix or another MTA on your Deploynix-managed server and send email directly. Laravel supports this through the sendmail mail driver. Do not do this unless you have a very specific reason and understand the implications.

Sending email from a cloud server IP address is fighting an uphill battle. Cloud provider IP ranges are well-known to email providers, and many of those IPs have been used to send spam at some point. Even if your specific IP is clean, it may share a reputation with neighboring IPs in the same subnet.

Dedicated email delivery services solve this problem by:

Maintaining IP pools with carefully managed reputations.
Handling SPF, DKIM, and DMARC configuration for you.
Providing deliverability analytics so you can monitor inbox placement.
Managing bounce handling, complaint processing, and suppression lists.
Offering dedicated IP addresses if your volume justifies it.

For Laravel applications, the best options are Postmark (excellent for transactional email, the highest deliverability rates in the industry), Mailgun (good for both transactional and bulk email), and Amazon SES (lowest cost at scale, more setup required).

Configuring Laravel for Email Delivery

In your Laravel application, email configuration lives in config/mail.php. Set your default mailer to your chosen email provider and configure the credentials in your environment variables. Here is an example using Postmark:

// .env on your Deploynix server
MAIL_MAILER=postmark
POSTMARK_TOKEN=your-postmark-server-token
MAIL_FROM_ADDRESS=notifications@yourapp.com
MAIL_FROM_NAME="Your App Name"

The MAIL_FROM_ADDRESS should use your own domain, not a freemail address like Gmail. Sending application emails from a Gmail address is a strong spam signal and also means you cannot properly configure SPF, DKIM, and DMARC.

On your Deploynix server, set these environment variables through the Deploynix dashboard. Environment variables are stored securely and injected into your application's .env file during deployment.

Queue Your Emails

Always send emails through a queue in production. Sending email synchronously blocks the HTTP request while waiting for the SMTP transaction to complete, which can take several seconds. More importantly, if the email provider is temporarily unavailable, the request fails entirely.

Laravel makes this trivial:

// In your controller or service
Mail::to($user)->queue(new WelcomeEmail($user));

// Or implement ShouldQueue on the Mailable itself
class WelcomeEmail extends Mailable implements ShouldQueue
{
    // ...
}

On Deploynix, your queued emails are processed by your dedicated worker servers. This means email sending does not consume resources on your app servers, and if the email provider has a momentary hiccup, the queue automatically retries the job.

Content and Sending Practices

Authentication is necessary but not sufficient. The content and patterns of your emails also affect deliverability.

Avoid Spam Triggers

Email providers use content analysis alongside authentication checks. Avoid these common triggers:

ALL CAPS in subject lines. It looks like shouting.
Excessive exclamation marks. One is fine. Three is spam.
Spammy phrases. "Act now," "limited time," "free money." These are weighted negatively by spam filters.
Image-only emails. Emails that are just one large image with no text are a classic spam pattern. Always include meaningful text content.
Misleading subject lines. The subject should accurately describe the email content. "Re:" on a non-reply email is deceptive.

Send Consistently

Email providers track your sending patterns. If you normally send 100 emails per day and suddenly send 10,000, that spike looks suspicious. When launching a new feature that generates emails, ramp up gradually.

Honor Unsubscribes Immediately

When a user unsubscribes, stop sending them emails immediately. Do not wait for the next batch processing cycle. Do not send a "we are sorry to see you go" email. Just stop. Laravel's notification system supports checking notification preferences, so implement an unsubscribed check in your notification classes.

Monitor Bounce Rates

A high bounce rate (sending to invalid email addresses) damages your sender reputation rapidly. Implement email verification during registration, handle hard bounces by disabling the email address, and periodically clean your user list.

Most email delivery services provide webhook callbacks for bounce events. Configure a webhook endpoint in your Laravel application that listens for bounce notifications and automatically marks the email address as invalid.

Testing Email Deliverability

Before declaring victory, test your email setup thoroughly.

Mail Tester (mail-tester.com): Send an email from your application to the unique address provided by Mail Tester. It will analyze your message and give you a score out of 10, with specific feedback on what to fix. Aim for a score of 9 or above.

MXToolbox: Check your domain's DNS records including SPF, DKIM, and DMARC. It identifies common misconfigurations and provides actionable recommendations.

Google Postmaster Tools: If a significant portion of your users are on Gmail, register your domain with Google Postmaster Tools. It provides data on your domain's reputation, spam rate, authentication success rate, and delivery errors.

Send to Multiple Providers: Test by sending emails to Gmail, Outlook, Yahoo, and iCloud accounts. Deliverability can vary between providers, so passing spam filters on one does not guarantee passing on another.

The Complete DNS Checklist

Here is a summary of every DNS record you need for reliable email deliverability:

SPF Record: TXT record on your root domain listing all authorized senders.
DKIM Record: TXT record (usually on a subdomain like default._domainkey) containing your public key.
DMARC Record: TXT record on _dmarc.yourdomain.com specifying your policy and report address.
MX Records: If you also receive email on your domain, proper MX records are essential.
PTR Record: Only relevant if sending directly from your server (which you should not be doing).

Verify all records are published correctly, then test using the tools mentioned above. DNS changes can take up to 48 hours to propagate, but usually take effect within an hour.

Moving Forward

Email deliverability is not a set-it-and-forget-it task. Monitor your delivery rates, watch for reputation drops, respond to bounces and complaints promptly, and review your DMARC reports periodically.

On Deploynix, your server infrastructure handles the operational side: environment variables for mail credentials, queue workers for reliable delivery, and the overall server performance that ensures emails are sent promptly. But the email authentication records and content practices are your responsibility.

Get SPF, DKIM, and DMARC configured correctly. Use a dedicated email delivery service. Queue your emails. Monitor your metrics. Your carefully crafted welcome email deserves to land in the inbox, not the spam folder.

GDPR for Laravel Developers: Data Storage, Deletion, and Server Location on Deploynix

Deploynix — Tue, 21 Apr 2026 10:00:04 +0000

GDPR compliance is not a server configuration toggle or a Laravel package you install. It is a set of obligations that touch every layer of your application, from the database schema to the server infrastructure to the user interface. As a Laravel developer, you are in a unique position: you control both the application code and, through Deploynix, the infrastructure it runs on.

This guide takes a practical, code-aware approach to GDPR compliance. We will cover the rights your users have, how to implement them in Laravel, where your servers should live, and how Deploynix's infrastructure features support your compliance posture. No legal abstractions. Just concrete steps you can take this week.

Understanding Your Obligations

GDPR grants individuals specific rights over their personal data. As the developer building the application that processes that data, these rights translate directly into features you need to build and infrastructure you need to configure.

The rights most relevant to Laravel developers are:

Right to Access (Article 15): Users can request a copy of all personal data you hold about them. You need a mechanism to gather data from across your application and provide it in a structured format.

Right to Erasure (Article 17): Also called the "right to be forgotten." Users can request that you delete all their personal data, with some exceptions for legal obligations. You need a mechanism to find and delete every trace of a user's data.

Right to Data Portability (Article 20): Users can request their data in a commonly used, machine-readable format. JSON is the standard choice for API-driven applications.

Right to Rectification (Article 16): Users can request corrections to inaccurate personal data. In most Laravel applications, this is satisfied by providing edit functionality for user profiles and related data.

Right to Restriction of Processing (Article 18): Users can request that you stop processing their data while a complaint or correction request is being handled.

Let's implement each of these practically in Laravel.

Implementing the Right to Data Export

Data export is the foundation for both the right to access and the right to data portability. Your implementation needs to gather all personal data associated with a user, from every table where their data appears, and return it as a downloadable file.

Start by auditing your database. Every table that contains a user_id foreign key or stores personally identifiable information needs to be included in the export. In a typical Laravel application, this might include the users table, orders, addresses, support tickets, activity logs, uploaded files metadata, and notification preferences.

Create a dedicated service class for data export. The service should query each relevant table for data belonging to the user and compile it into a structured JSON file. Consider the following approach:

class UserDataExportService
{
    public function export(User $user): array
    {
        return [
            'personal_information' => $this->getPersonalInfo($user),
            'orders' => $this->getOrders($user),
            'addresses' => $this->getAddresses($user),
            'support_tickets' => $this->getSupportTickets($user),
            'activity_log' => $this->getActivityLog($user),
            'preferences' => $this->getPreferences($user),
            'exported_at' => now()->toIso8601String(),
        ];
    }
}

Each method should return an array of the user's data from that domain. Strip out internal identifiers, foreign keys, and system metadata that are not personal data. The user does not need to know their stripe_customer_id or the internal order_status_id. They need to see their name, email, order history, and the content they created.

For large datasets, generate the export as a background job using Laravel's queue system. On Deploynix, queue jobs run on your dedicated worker servers, so the export process does not impact your application's responsiveness. Once the export is ready, notify the user via email with a temporary download link.

Verify the user's identity before providing the export. GDPR requires that you confirm the identity of the person making the request. For authenticated users, requiring them to re-enter their password before initiating an export is usually sufficient.

Implementing the Right to Erasure

The right to erasure is more complex than it appears. You cannot simply call $user->delete() and consider it done. You need to find and remove personal data from every location where it exists, including soft-deleted records, related models, uploaded files, cache entries, session data, log files, and backups.

Here is a systematic approach:

Step 1: Identify all personal data locations. Walk through every model in your application that has a relationship to the User model or stores personal data. Create a checklist. Common locations include:

Users table (the obvious one)
Related models (orders, posts, comments, tickets)
Media and file uploads (avatar images, documents)
Activity logs and audit trails
Cache entries keyed by user ID
Session data
Email notification history
Third-party service records (Stripe customers, email marketing lists)

Step 2: Decide what to delete versus anonymize. GDPR does not require you to delete data that you have a legal obligation to retain. Financial records that you must keep for tax purposes can be anonymized instead of deleted: replace the user's name and email with placeholder values while retaining the transaction data.

class UserDeletionService
{
    public function delete(User $user): void
    {
        // Anonymize records we must retain for legal reasons
        $user->orders()->update([
            'customer_name' => 'Deleted User',
            'customer_email' => 'deleted@example.com',
        ]);

        // Delete records we do not need to retain
        $user->supportTickets()->forceDelete();
        $user->activityLogs()->delete();
        $user->addresses()->delete();

        // Remove uploaded files from storage
        Storage::delete($user->avatar_path);
        $user->documents()->each(function ($document) {
            Storage::delete($document->path);
            $document->delete();
        });

        // Clear cache entries
        Cache::forget("user:{$user->id}:preferences");
        Cache::forget("user:{$user->id}:permissions");

        // Remove from third-party services
        // Stripe::customers()->delete($user->stripe_id);

        // Finally, delete the user
        $user->forceDelete();
    }
}

Step 3: Handle soft-deleted records. If you use Laravel's soft deletes, remember that soft-deleted records still contain personal data. Your deletion service should use forceDelete() for GDPR erasure requests. Alternatively, anonymize the personal data fields and then soft delete, so the record exists for referential integrity but contains no personal information.

Step 4: Address backups. This is the hardest part. Your database backups on Deploynix contain personal data, and you cannot selectively remove one user's data from a backup. The accepted approach under GDPR is to document that backups are retained for a defined period (for example, 30 days) and that deleted data will naturally expire from the backup cycle. If a backup is ever restored, you must re-apply any deletion requests that occurred after the backup was taken.

Maintain a log of deletion requests with timestamps. If you ever restore from backup, query this log and re-execute deletions for any user who requested erasure after the backup date.

Cookie Consent and Tracking

GDPR (and the ePrivacy Directive) require informed consent before setting non-essential cookies. In a Laravel application, this means you need a cookie consent mechanism that:

Blocks analytics scripts, advertising pixels, and non-essential cookies until the user consents.
Provides granular options so users can consent to some cookie categories but not others.
Records the consent with a timestamp for your records.
Allows users to withdraw consent at any time.

Implement consent storage in your database rather than relying solely on a cookie. A database record provides an auditable consent trail. Store the user's consent preferences, the timestamp, the version of your privacy policy they consented to, and their IP address.

For your Laravel application's middleware, check consent status before setting cookies or including tracking scripts. A middleware that reads the consent cookie (or database record for authenticated users) and sets a view variable that your Blade templates check before rendering analytics scripts is a clean approach.

// In your Blade layout
@if(request()->cookie('analytics_consent') === 'granted')

@endif

Server Location and Data Residency

Where your servers are physically located matters under GDPR. Deploynix supports provisioning servers on multiple cloud providers, and for EU data residency, Hetzner is the strongest choice.

Hetzner's data centers are exclusively in the EU (Germany and Finland). When you provision servers through Deploynix on Hetzner, you know with certainty that your data resides in the EU. There is no ambiguity about data replication to other regions or hidden cross-border transfers.

For a GDPR-compliant Laravel setup on Deploynix, provision all of your servers in the same EU region:

App server on Hetzner (Nuremberg, Falkenstein, or Helsinki)
Database server on Hetzner (same region for lowest latency)
Cache server on Hetzner (same region)
Worker server on Hetzner (same region)

Configure your database backups to store in an EU-only location. If using AWS S3 for backup storage, select the eu-central-1 (Frankfurt) region and do not enable cross-region replication. If using Wasabi, select their Amsterdam or Frankfurt location.

Data Processing Documentation

GDPR Article 30 requires that you maintain records of your processing activities. For a Laravel application deployed on Deploynix, this documentation should include:

What personal data you collect: List every field in your database that contains personal data. Name, email, IP address, physical address, payment information, and any other data that can identify a natural person.

Why you collect it: Each data point needs a lawful basis. User email for account authentication (contractual necessity), IP address for security logging (legitimate interest), marketing preferences (consent). Be specific.

Where it is stored: Document your server locations (Hetzner Nuremberg, for example), your backup storage location, and any third-party services that receive personal data.

How long you retain it: Define retention periods for each data category. Active account data is retained for the life of the account. Deleted account data is purged within 30 days. Financial records are retained for 7 years for tax compliance. Log files are retained for 90 days.

Who has access: Document which team roles can access personal data. On Deploynix, this maps to your organization roles: which team members have database access, which can view logs, and which can access the server directly.

What security measures protect it: Document your encryption (SSL in transit, encryption at rest for backups), firewall rules (configured through Deploynix), access controls (Deploynix organization roles), and any application-level security measures (password hashing, two-factor authentication).

Handling Data Subject Requests

Build a system for receiving and tracking data subject requests. GDPR gives you 30 days to respond to a request (extendable by two months for complex cases). You need to:

Verify the requestor's identity.
Log the request with a timestamp.
Process the request (export, deletion, rectification).
Confirm completion to the user.

A simple Laravel implementation uses a model and controller dedicated to data subject requests. The model tracks the request type, status, and timeline. A queued job processes the request, and an email notification confirms completion.

For applications with significant user bases, consider adding a self-service privacy dashboard where authenticated users can download their data, delete their account, and manage their consent preferences without submitting a manual request. This reduces your operational burden and improves the user experience.

Third-Party Services Audit

Your Laravel application likely communicates with services outside your Deploynix infrastructure. Each of these services needs to be evaluated for GDPR compliance:

Email delivery (Mailgun, SES, Postmark): Do they process email addresses and content in the EU? Many offer EU-region processing.

Payment processing (Stripe, Paddle): Payment processors typically act as independent data controllers or joint controllers. Ensure you have appropriate agreements in place. Deploynix uses Paddle for its own billing, which is EU-based.

Analytics (Google Analytics, Plausible, Fathom): Google Analytics has been found non-compliant in several EU jurisdictions. Consider EU-based alternatives like Plausible or Fathom.

Error tracking (Sentry, Bugsnag): Error reports often contain user data (IP addresses, request parameters). Choose a provider with EU hosting options or configure data scrubbing.

Search (Algolia, Meilisearch): If you index personal data for search, the search service processes that data. Meilisearch can be self-hosted on your Deploynix servers, keeping search data within your EU infrastructure.

Practical Checklist

Here is a condensed checklist for Laravel developers deploying on Deploynix:

Provision all servers on Hetzner (EU data centers) through Deploynix
Configure firewall rules to restrict database and cache access
Set up EU-only backup storage
Implement user data export functionality
Implement user data deletion with anonymization for legally required records
Add cookie consent with granular controls
Document all processing activities (Article 30 records)
Audit all third-party services for EU data processing
Set up a data subject request tracking system
Configure appropriate retention periods and automated cleanup
Establish a breach notification process with 72-hour timeline
Sign DPAs with all sub-processors (Deploynix, Hetzner, email provider, etc.)

GDPR compliance is not a destination. It is a continuous practice. The combination of Laravel's expressive framework and Deploynix's EU-friendly infrastructure gives you the tools to build applications that respect your users' privacy rights while running on infrastructure that keeps their data where it belongs.

Hosting Laravel in the EU: GDPR Compliance with Hetzner and Deploynix

Deploynix — Mon, 20 Apr 2026 22:00:05 +0000

If you serve European customers, GDPR is not optional. It is not a suggestion, a best practice, or something you can worry about later. Since May 2018, the General Data Protection Regulation has been the law across the European Economic Area, and the fines for non-compliance are not theoretical. Companies of every size have been penalized, and regulators are getting more aggressive, not less.

For Laravel developers, GDPR compliance starts with a fundamental question: where does your data physically live? The regulation does not prohibit transferring personal data outside the EU, but it imposes strict conditions on such transfers. The simplest path to compliance is keeping EU user data on EU soil, and that is exactly what Deploynix and Hetzner make possible.

This guide walks you through setting up a fully EU-resident Laravel infrastructure using Deploynix with Hetzner as your cloud provider, covering everything from server provisioning to backups to the operational practices that keep you compliant.

Why Data Residency Matters Under GDPR

GDPR's data transfer rules (Articles 44-49) restrict transferring personal data to countries outside the EEA unless specific safeguards are in place. For years, many companies relied on the EU-US Privacy Shield framework to justify transatlantic data transfers, but the Court of Justice of the European Union invalidated that framework in the Schrems II decision. While the EU-US Data Privacy Framework has since been established as a replacement, relying on adequacy decisions introduces regulatory risk. Frameworks can be challenged and invalidated.

Keeping data within the EU eliminates this entire category of risk. If personal data never leaves EU-based servers, you do not need to worry about transfer mechanisms, adequacy decisions, or supplementary measures. Your data residency story is simple and defensible.

This is especially important for applications in sensitive sectors like healthcare, fintech, legal services, and education, where data protection authorities scrutinize data handling practices more closely.

Why Hetzner for EU Hosting

Hetzner is a German cloud provider with data centers exclusively in the EU and Finland. Unlike hyperscale providers that operate globally and require you to carefully select regions and verify that your data does not replicate elsewhere, Hetzner's entire infrastructure is European by design.

Hetzner's data centers are located in:

Nuremberg, Germany (multiple facilities)
Falkenstein, Germany (multiple facilities)
Helsinki, Finland

All of these locations are within the EEA, which means any server you provision on Hetzner through Deploynix is automatically EU-resident. There is no risk of your data being routed through a US data center for caching, failover, or load balancing because Hetzner does not have US data centers.

Beyond data residency, Hetzner offers practical advantages for GDPR compliance. As a German company, Hetzner is directly subject to EU data protection law and German federal data protection regulations, which are among the strictest in the world. They provide a Data Processing Agreement (Auftragsverarbeitungsvertrag) that meets GDPR Article 28 requirements, and their technical and organizational measures are documented and auditable.

From a performance and cost perspective, Hetzner is also exceptionally competitive. Their dedicated vCPU servers deliver excellent performance for Laravel applications at price points significantly below comparable offerings from US-based cloud providers. You do not have to pay a premium for EU compliance.

Setting Up EU-Only Infrastructure on Deploynix

Deploynix makes it straightforward to build a fully EU-resident infrastructure. Here is how to set up a complete Laravel production environment using only Hetzner servers.

Step 1: Connect Hetzner as Your Cloud Provider

In your Deploynix organization settings, add Hetzner as a cloud provider by providing your Hetzner API token. Deploynix will use this token to provision and manage servers on your behalf within your Hetzner account.

You retain full ownership and control of your Hetzner account. Deploynix manages the servers through the API, but the servers, the data on them, and the Hetzner account itself belong to you. If you ever stop using Deploynix, your servers continue running exactly as they are.

Step 2: Provision Your Server Infrastructure

For a GDPR-compliant Laravel production environment, we recommend the following server setup, all provisioned on Hetzner through Deploynix:

App Server: Your primary application server running your Laravel application. Choose FrankenPHP, Swoole, or RoadRunner as your Octane driver for optimal performance. Deploynix configures Nginx, PHP, and your Octane driver automatically.

Database Server: A dedicated server running MySQL, MariaDB, or PostgreSQL. Running your database on a separate server is both a performance best practice and a compliance advantage: it isolates personal data on a server that you can apply additional access controls to.

Cache Server: A dedicated Valkey server for caching, sessions, and queue management. If you store any personal data in your cache or sessions, this server is also within your EU-resident infrastructure.

Worker Server: A dedicated server for processing queue jobs. Jobs that handle personal data, such as sending emails, generating reports, or processing user exports, execute on EU-resident infrastructure.

When provisioning each server, select a Hetzner datacenter location. Whether you choose Nuremberg, Falkenstein, or Helsinki depends on your latency requirements and preferences, but all options are EU-resident.

Step 3: Configure Firewall Rules

GDPR requires appropriate technical measures to protect personal data (Article 32). Deploynix's firewall management lets you configure strict access rules for each server.

At minimum, configure the following:

Your database server should only accept connections from your app server and worker server IP addresses. Block all other inbound traffic on the database port.
Your cache server should similarly restrict connections to only your app and worker servers.
SSH access should be limited to your team's IP addresses or accessed exclusively through the Deploynix web terminal.
Your app server should only expose ports 80 and 443 to the public internet.

These firewall rules are configured directly in the Deploynix dashboard and applied at the server level. Document these measures as part of your GDPR Article 32 technical safeguards.

Step 4: Configure EU-Only Backups

Database backups must also remain within the EU to maintain your data residency posture. Deploynix supports several backup storage providers, and for EU compliance, you have several options:

Hetzner Storage Boxes: Hetzner offers storage boxes that are physically located in their EU data centers. These are ideal for keeping backups within the same provider and the same jurisdiction as your servers.

AWS S3 with EU Region: If you prefer S3, create your backup bucket in an EU region such as eu-central-1 (Frankfurt) or eu-west-1 (Ireland). Configure the bucket with no cross-region replication to ensure data stays in the selected region.

Wasabi EU: Wasabi offers EU storage locations including Amsterdam and Frankfurt. Their S3-compatible API works seamlessly with Deploynix's backup system.

Configure your backup schedule in Deploynix to run daily database backups. We recommend retaining daily backups for at least 30 days and weekly backups for a year, but adjust based on your data retention policy and legal requirements.

Enable encryption for backups. Deploynix encrypts backup data, and you should also enable server-side encryption on your storage bucket so that backups are encrypted at rest.

Step 5: SSL Certificate Configuration

SSL encryption for data in transit is a baseline GDPR requirement. Deploynix automatically provisions Let's Encrypt SSL certificates for your sites with zero configuration needed.

For DNS validation, which is required for wildcard certificates, Deploynix integrates with Cloudflare, DigitalOcean DNS, AWS Route 53, and Vultr DNS. If you are using Cloudflare for DNS management (common even when hosting on Hetzner), the DNS management layer does not affect data residency because DNS records are metadata about where to route traffic, not personal data.

Your application traffic flows directly from the user's browser to your Hetzner server over HTTPS. It does not pass through Cloudflare unless you have enabled Cloudflare's proxy mode. If you want to ensure traffic does not pass through non-EU infrastructure, use Cloudflare in DNS-only mode (grey cloud) rather than proxied mode (orange cloud).

Operational Practices for GDPR Compliance

Infrastructure is only one piece of the GDPR puzzle. Your operational practices matter equally.

Access Control

Deploynix's organization roles (Owner, Admin, Manager, Developer, Viewer) let you implement the principle of least privilege for server access. Not everyone on your team needs access to the database server or the ability to trigger deployments.

Developers can view server details and deployment logs but cannot modify server configurations or access the production database.
Managers can trigger deployments and view more detailed server information.
Admins have broader access but can be restricted from billing and organization-level settings.
Owners have full access to everything.

Map these roles to your team structure so that only team members who need access to personal data for their job function actually have it.

Logging and Audit Trails

GDPR requires that you can demonstrate compliance (the accountability principle, Article 5(2)). Deploynix maintains logs of all server management actions: who deployed what, when servers were provisioned or modified, when firewall rules were changed, and when backups were created or restored.

These audit logs serve double duty. They help you maintain operational awareness and provide evidence of your security practices if a data protection authority ever asks.

Incident Response

Article 33 of GDPR requires notifying the relevant supervisory authority within 72 hours of becoming aware of a personal data breach. Deploynix's health alerts and monitoring give you early warning of potential security incidents, including unauthorized access attempts, unusual server behavior, and service disruptions.

Configure your health alerts to notify your team immediately via the fastest channel available. When an alert fires, you need to assess quickly whether personal data may have been compromised and start your 72-hour breach notification clock if necessary.

Data Processing Agreement

As a tool that manages your servers, Deploynix acts as a data processor in certain contexts. We provide a Data Processing Agreement that meets GDPR Article 28 requirements. Make sure you also have a DPA in place with Hetzner and any other sub-processors in your stack (email providers, payment processors, analytics services).

Maintain a list of all sub-processors that handle personal data from your application. GDPR requires that you can identify every entity involved in processing personal data on your behalf.

Common Pitfalls to Avoid

Do not assume EU servers mean full compliance. Data residency is necessary but not sufficient. You still need lawful bases for processing, privacy notices, data subject rights mechanisms, and proper consent management in your application code.

Do not forget about logs. Application logs, error tracking services, and monitoring tools often capture personal data (IP addresses, email addresses, user IDs). If you send logs to a service hosted outside the EU, you have a data transfer. Either choose EU-hosted logging services or anonymize personal data before shipping logs.

Do not overlook third-party services. Your servers may be in the EU, but if your application calls APIs hosted in the US (analytics, email delivery, payment processing), personal data may still leave the EU during those API calls. Audit every external service your application communicates with.

Do not ignore email delivery. If your Laravel application sends emails containing personal data, the email delivery service is processing that data. Choose an email provider that offers EU-based infrastructure or has appropriate data transfer safeguards in place.

The Deploynix Advantage

Building a GDPR-compliant infrastructure manually is possible but tedious and error-prone. Deploynix streamlines the process by letting you provision, configure, and manage EU-only infrastructure through a single dashboard. Hetzner integration is first-class, firewall rules are straightforward to configure, backups can be directed to EU-only storage, and SSL is automatic.

More importantly, Deploynix gives you the operational tools, such as monitoring, health alerts, access controls, and audit logs, that support ongoing compliance. GDPR is not a one-time checkbox. It is a continuous obligation, and having the right tooling makes that obligation manageable.

Your European users trust you with their data. Deploynix and Hetzner make it possible to honor that trust with infrastructure that is European from the ground up.

The Deploynix Roadmap: What We're Building Next and Why

Deploynix — Mon, 20 Apr 2026 10:00:05 +0000

Building a server management platform is a never-ending exercise in prioritization. Every week, we receive feature requests from customers, identify improvements through our own dogfooding, and spot opportunities in the evolving Laravel ecosystem. The challenge is never "what should we build?" It is "what should we build next?"

We believe in building in public. Deploynix exists because Laravel developers deserve a deployment platform built specifically for them, and that means the community should have a voice in where the platform goes. This post lays out our roadmap transparently: what we are actively working on, what is planned for the near future, what is on our radar for later, and how we decide what to prioritize.

How We Prioritize

Before diving into specific features, it helps to understand how we decide what gets built. We evaluate every potential feature against four criteria:

Impact: How many customers will benefit, and how significantly? A feature that saves every customer five minutes per deployment ranks higher than a feature that solves a niche problem for a handful of users.

Alignment: Does this feature strengthen our core value proposition as a Laravel-first deployment platform? We intentionally avoid becoming a generic cloud management tool. Every feature should make deploying and managing Laravel applications specifically better.

Effort: How long will it take to build, and what is the ongoing maintenance burden? A feature that takes a week to build but requires constant attention is less attractive than one that takes two weeks but runs reliably with minimal maintenance.

Urgency: Is there a time-sensitive reason to build this now? Security features, ecosystem compatibility updates, and breaking-change responses get priority regardless of other criteria.

We also weight customer feedback heavily. When multiple customers independently request the same feature, that signal is hard to ignore. Our support conversations, community discussions, and direct feedback all feed into a prioritization scorecard that we review weekly.

Currently in Development

These features are actively being built and will ship in the coming weeks.

Container Support

This is the most requested feature we have ever received, and we are deep into development. Container support will allow Deploynix to manage Docker-based deployments alongside our traditional server-based approach.

The implementation focuses on what Laravel developers actually need from containers rather than exposing the full complexity of container orchestration. You will be able to define your application's container configuration through a simple Dockerfile or a Deploynix-managed template, and Deploynix will handle building, pushing, and deploying containers to your servers.

We are not building Kubernetes. We are building container deployment that feels as straightforward as our current git-based deployments. You push code, Deploynix builds the container, and deploys it with zero downtime. The same deploy scripts, rollback capabilities, and monitoring you already use will work with containerized applications.

Server Transfer Between Organizations

Currently, if you need to move a server from one organization to another, it requires a manual process through our support team. We are building a self-service transfer system that lets organization owners transfer servers cleanly, including all associated sites, databases, SSL certificates, and configurations.

This matters particularly for agencies that build projects for clients and then hand off the infrastructure. The transfer will preserve all server history and configurations while changing ownership and billing responsibility.

Enhanced Deployment Metrics

We are adding detailed deployment analytics to help teams understand their deployment patterns. This includes deployment frequency tracking, average deployment duration, success and failure rates over time, and rollback frequency. These metrics will be available both in the dashboard and through the API.

The goal is not just vanity metrics. Understanding that your deployments have gotten 30% slower over the past month, or that a particular deploy script step fails 5% of the time, gives you actionable information to improve your pipeline.

Planned for the Near Term

These features have been scoped and designed and will enter active development once current work ships.

Multi-Region Deployment

For applications that serve a global audience, deploying to a single region means some users experience high latency. Multi-region deployment will allow you to define a deployment that rolls out across servers in multiple regions, with configurable ordering and health checks between stages.

This builds on our existing load balancer infrastructure. You will be able to set up geographic load balancing so that European users hit your Hetzner servers while North American users hit your Vultr or DigitalOcean servers, all deployed and managed as a single application through Deploynix.

Database Read Replicas

Managing MySQL, MariaDB, or PostgreSQL read replicas is a common scaling pattern for Laravel applications, but setting up replication correctly is error-prone. Deploynix will automate the provisioning and configuration of read replicas, including the initial data sync, replication monitoring, and automatic failover.

On the Laravel side, we will provide configuration guidance for setting up your database.php config to use read and write connections effectively, so your application can distribute query load across replicas without code changes beyond configuration.

Team Notifications and Webhooks

Currently, Deploynix sends notifications about deployments, health alerts, and other events through the dashboard. We are expanding this with configurable notification channels: Slack, Discord, Microsoft Teams, email digests, and custom webhooks.

Custom webhooks in particular will enable powerful integrations. You will be able to trigger external CI/CD pipelines, update status pages, notify project management tools, or feed deployment data into your own analytics systems.

Staging Environments

One-click staging environment provisioning is something we have wanted to build since day one. The feature will let you clone your production server configuration into a staging environment that mirrors production as closely as possible, including database schema, server configuration, and environment variables with sensitive values masked.

Staging environments will support automatic deployment from a staging branch, so your team can test changes in a production-like environment before merging to your deployment branch.

On the Radar

These features are things we are thinking about seriously but have not committed to specific timelines. They may move into active development based on community feedback and strategic priorities.

GitOps Configuration

Instead of configuring servers and deployments through the Deploynix dashboard, GitOps configuration would let you define your infrastructure in a YAML or JSON file committed to your repository. Changes to that configuration file would trigger Deploynix to reconcile the actual infrastructure with the desired state.

This appeals strongly to teams that want infrastructure changes to go through the same code review process as application changes. It also enables reproducibility: you could spin up an identical infrastructure stack by pointing Deploynix at a configuration file.

Built-In CI/CD

Several customers have asked for basic CI/CD capabilities directly in Deploynix, specifically running tests before deployment. Currently, most teams use GitHub Actions, GitLab CI, or Bitbucket Pipelines for their test suite and then deploy through Deploynix once tests pass.

We are evaluating whether building lightweight test running into Deploynix would be valuable enough to justify the complexity, or whether deeper integration with existing CI/CD providers would serve customers better. The honest answer is we are not sure yet, and we want to hear more from the community before committing to an approach.

Managed Redis and Managed Database Services

Some customers have asked about managed database and cache offerings where Deploynix handles high availability, automated failover, and point-in-time recovery at the infrastructure level rather than the application level. This would be a significant expansion of our service scope, moving from server management into managed service territory.

We are cautious about this one. Managed databases done well require deep operational expertise and 24/7 on-call support. Done poorly, they create more problems than they solve. We would rather not offer this feature than offer a mediocre version of it.

Mobile Application

A Deploynix mobile app for monitoring servers and triggering deployments on the go comes up regularly in feedback. The core use case is clear: you get a health alert on your phone, and you want to check the dashboard, view logs, or trigger a rollback without opening a laptop.

We are leaning toward a progressive web app approach rather than native iOS and Android apps. A well-built PWA would give us the push notifications and offline capabilities that matter most while letting us maintain a single codebase.

Community-Driven Features

Some of our best features have come directly from community feedback. Scheduled deployments, for example, started as a feature request from a customer who needed to deploy database migrations during off-peak hours. Vanity domains on deploynix.cloud came from indie developers who wanted to share staging sites without configuring custom domains.

We actively track every feature request and tag them by theme. When we see clusters of requests around the same problem, that signals real demand. Here are the themes generating the most community interest right now:

Better log management: Customers want centralized log aggregation across all servers in a project, with search, filtering, and alerting. This is firmly on our radar and will likely move into active development soon.

Deployment approval workflows: Teams with compliance requirements want the ability to require approval from specific team members before a deployment proceeds. This ties into our existing organization roles (Owner, Admin, Manager, Developer, Viewer) and would add a configurable approval gate to the deployment pipeline.

Import existing servers: Several customers have servers already running Laravel applications on other platforms or manually configured servers that they want to bring under Deploynix management without reprovisioning. This is technically complex because existing servers have unpredictable configurations, but we are exploring approaches that could work for common setups.

Terraform provider: DevOps-oriented teams want to manage Deploynix resources through Terraform. Since we already have a comprehensive API with Sanctum token authentication and granular scopes, building a Terraform provider is mostly a matter of wrapping our API in the Terraform provider framework. This is something we may open-source and accept community contributions for.

What We Will Not Build

Being transparent about our roadmap also means being honest about what falls outside our scope. Deploynix is a Laravel-first server management platform, and we are intentional about maintaining that focus.

We will not become a generic cloud provider. We provision servers on DigitalOcean, Vultr, Hetzner, Linode, AWS, and custom providers, but we are not competing with those providers. We are a management layer that makes them easier to use for Laravel deployments.

We will not build a CMS or application framework. Deploynix deploys and manages Laravel applications. We do not generate application code, scaffold projects, or provide application-level services beyond what is needed for deployment and server management.

We will not chase every DevOps trend. Service mesh, serverless edge functions, AI-powered auto-scaling: these are interesting technologies, but we will only adopt them when they genuinely improve the experience of deploying Laravel applications. We are not going to add complexity for the sake of a marketing checkbox.

How to Influence the Roadmap

Your voice matters more than you might think. Here is how to make sure your feedback reaches us:

Feature requests: Submit them through the Deploynix dashboard or email our support team directly. Specific, detailed requests with real use cases are the most helpful. "I want container support" is useful. "I need container support because I run a Laravel app with a Python ML service sidecar and managing them as separate deployments is painful" is extremely useful.

Upvoting: When we share roadmap updates, engage with the features that matter most to you. Seeing concentrated interest helps us prioritize.

Beta testing: For major features, we run beta programs with interested customers. Beta testers get early access and direct influence over how the feature ships. If you want to be part of the container support beta, let us know.

Our Commitment

Roadmaps are promises, and we take promises seriously. We would rather under-promise and over-deliver than announce flashy features that slip indefinitely. Every feature listed in the "Currently in Development" section will ship. Features in "Planned" have high confidence of happening. "On the Radar" items are genuine considerations, not marketing fluff.

We will continue to publish roadmap updates regularly so you can track our progress and hold us accountable. Building Deploynix is a partnership with our community, and the best deployment platform for Laravel developers is one that Laravel developers help shape.

DEV Community: Deploynix

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

The Test Environment

The Server

The Application

The Load Testing Tool

Phase 1: Baseline Test (No Optimization)

10 Concurrent Users

50 Concurrent Users

100 Concurrent Users

Phase 2: Apply Laravel Optimizations

Results at 50 Concurrent Users (Optimized)

Results at 100 Concurrent Users (Optimized)

Phase 3: Switch to FrankenPHP (Octane)

Results at 100 Concurrent Users (FrankenPHP)

Results at 200 Concurrent Users (FrankenPHP)

Phase 4: Database Query Optimization

Results at 200 Concurrent Users (FrankenPHP + Query Optimization)

Pushing to 300 Concurrent Users

What Does This Mean in Real Traffic?

Optimization Impact Summary

When to Scale Up

Cost-Effective Optimization Checklist

Conclusion

The Definitive Guide to Laravel Deployment in 2026

Part 1: Preparing Your Application for Production

Environment Configuration

Optimizing for Production

Asset Compilation

Part 2: Choosing Your Server Infrastructure

Cloud Providers

Server Types

Choosing a PHP Runtime

Part 3: Provisioning and Configuration

Provisioning with Deploynix

Connecting Your Git Repository

SSL Certificates

Part 4: The Deployment Process

Zero-Downtime Deployments

Deploy Script

Scheduled Deployments

Rollback

Part 5: Database Management

Running Migrations

Database Backups

Database Optimization

Part 6: Queue Workers and Background Processing

Configuring Queue Workers

Daemon Processes

Part 7: Monitoring and Alerting

Server Monitoring

Health Alerts

Application-Level Monitoring

Part 8: Security

Firewall Configuration

SSH Security

Application Security Essentials

Part 9: Scaling

Vertical Scaling (Scaling Up)

Horizontal Scaling (Scaling Out)

Scaling Checklist

Part 10: The Deployment Checklist

Before First Deploy

Every Deploy

Post-Deploy Verification

Conclusion

Finding and Fixing Slow Queries in Laravel Before They Hit Production

Step 1: Detect Slow Queries in Development

Laravel Debugbar

Laravel Telescope

Step 2: Analyze with EXPLAIN

Running EXPLAIN from Laravel

Step 3: Common Slow Query Patterns and Fixes

Pattern 1: Missing Index on WHERE Columns

Pattern 2: Composite WHERE Without a Composite Index

Pattern 3: Using whereHas with Complex Conditions

Pattern 4: Sorting Without an Index

Pattern 5: Selecting All Columns When You Need Few

Pattern 6: Unbounded Queries

Step 4: Prevent Regressions with Automated Detection

Pattern 3: Using `whereHas` with Complex Conditions