DEV Community: devTalk

Secure a Laravel App Before Production: Tested Checklist

devTalk — Fri, 13 Nov 2026 03:38:46 +0000

Last updated: 8 November 2026. See theupdate logat the end.

Laravel gives you safe defaults for a lot of things: Blade escapes output, the query builder uses bound parameters, forms need a CSRF token, and session IDs change on login. But a handful of protections only exist if you set them up, and the dangerous ones fail silently. Nothing breaks when debug mode is on, when the web server points at the wrong folder, or when a user can open someone else's record by changing a number in the URL. The app just works, until someone finds it.

This article is a pre-launch checklist where every item was reproduced against a real Laravel 13.40.0 app over HTTP, so you see the actual requests, responses and numbers, including the defaults that are not safe. For each item you get the problem, the evidence, the fix, and how to check it afterwards.

What Laravel handles for you, and what it does not

Risk	Out of the box	Your job
XSS in Blade	`{{ }}` escapes	Never use `{!! !!}` on user input
SQL injection	Bound parameters in the query builder and Eloquent	Never interpolate variables into raw SQL
CSRF	Web routes reject a missing token with 419	Be careful with exclusions
Session fixation	Session ID regenerated on login	Nothing
Debug output	Enabled in the default `.env` file	Turn it off in production
Mass assignment	The skeleton's `User` model whitelists fields	Your own models and request handling
Authorization	Nothing automatic	Every route that loads a record
Brute-force protection	Throttle middleware is available but not applied to your routes	Add it
Security headers	None sent	Add a middleware or set them at the web server
Proxy and host trust	Forwarded headers ignored by default	Configure it correctly for your setup

1. Turn off debug mode and set the environment

A fresh Laravel app's .env has APP_ENV=local and APP_DEBUG=true. In production:

APP_ENV=production
APP_DEBUG=false

I made a route that throws an exception and requested it both ways:

APP_DEBUG=true:   status 500, 842,814 bytes, 110 references to absolute server paths,
                  stack trace with source code
APP_DEBUG=false:  status 500, 6,592 bytes, a generic "Server Error" page

The debug page told an attacker my directory layout, the framework internals and application code around the failure. I did not find APP_KEY or database passwords in that page's text in this test, but file paths and code are already more than anyone should get from an error. Debug mode on staging servers that are reachable from the internet counts too. More on this in 5 Laravel production mistakes that pass every local test.

2. Point the web server at public/, never the project root

Only the public folder should be reachable from the web. I served the project root instead of public and requested /.env:

document root = project root:  GET /.env  ->  status 200, file contents returned (APP_KEY included)
document root = public/:       GET /.env  ->  status 404

A web server pointed at the wrong folder serves your secrets to the world. In Nginx, set the root to public and refuse dotfiles as a second line of defense. This follows the structure of the standard Laravel Nginx config; I did not run Nginx for this article:

server {
    root /var/www/app/current/public;
    index index.php;

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

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

Check it from outside after every infrastructure change:

curl -s -o /dev/null -w "%{http_code}\n" https://your-site.example/.env
# expect 404 or 403, never 200

3. Protect APP_KEY and plan for rotating it

The APP_KEY encrypts cookies, sessions (if you encrypt them) and anything you pass through Crypt. The skeleton's .gitignore already ignores .env, .env.backup and .env.production; keep it that way, and keep keys out of build logs and chat messages. The skeleton's session config sets 'serialization' => 'json', and its comment explains that this guards against "gadget chain" attacks if the key leaks.

If a key does leak, you need to replace it without logging everyone out or breaking stored encrypted data. Laravel reads old keys from APP_PREVIOUS_KEYS (comma separated) in config/app.php. I tested the mechanism with the framework's encrypter:

new key only:                  DecryptException: The MAC is invalid.
new key + previousKeys([old]): session-data

php artisan key:generate --show      # prints a new key without writing it
# then in .env:
APP_KEY=base64:NEW_KEY...
APP_PREVIOUS_KEYS=base64:OLD_KEY...

The --show option is listed in the command's help ("Display a new key instead of modifying files"). Remove old keys once the data encrypted with them has expired or been re-encrypted. For storing the file itself, php artisan env:encrypt and env:decrypt exist in 13.40 (I listed them but did not run them), which lets you commit an encrypted environment file and keep the decryption key elsewhere.

4. Cache config in production, and stop calling env() outside config files

This is partly a performance item and partly a security one, because it changes where your settings really come from. With the config cached, env() outside config/*.php no longer reads .env:

before config:cache:  {"env":"Laravel","config":"Laravel"}
after config:cache:   {"env":null,"config":"Laravel"}

Code like if (env('APP_DEBUG')) in a controller then silently gets null. Read settings with config(), and put every env() call in a config file. On deploy:

php artisan optimize
php artisan about | grep -E "Environment|Debug Mode|Config|Routes"

Environment ..................................................... production
Debug Mode ............................................................. OFF
Config .............................................................. CACHED
Routes .............................................................. CACHED

That output is from my test app with production settings. about is a fast way to confirm what a server is actually running.

5. Force HTTPS and secure cookies

The default session cookie is HttpOnly with SameSite=Lax, but it has no Secure flag, so a browser will send it over plain HTTP too. This is what the default response sends (values removed):

Set-Cookie: XSRF-TOKEN=...; path=/; samesite=lax
Set-Cookie: laravel-session=...; path=/; httponly; samesite=lax

With SESSION_SECURE_COOKIE=true in .env:

Set-Cookie: XSRF-TOKEN=...; path=/; secure; samesite=lax
Set-Cookie: laravel-session=...; path=/; secure; httponly; samesite=lax

The XSRF-TOKEN cookie is not HttpOnly by design, so JavaScript can read it for AJAX requests. Redirect HTTP to HTTPS at the load balancer or web server, and send an HSTS header (see item 8). Setting the secure flag before your site is fully on HTTPS locks out your own sessions on HTTP, so do the two together.

6. Trust proxies precisely, never blindly

Behind a load balancer, the app must read the real client IP and scheme from X-Forwarded-* headers, but only from your proxy. By default Laravel ignores them, which is safe but means isSecure() is false and every request appears to come from the proxy's IP. The tempting fix is trustProxies(at: '*'). I tested all three configurations, sending forged X-Forwarded-Proto and X-Forwarded-For headers, then eight wrong logins (each with a different forged IP) against a route limited to five attempts per minute:

Configuration	Forged headers accepted?	8 login attempts with different forged IPs
Default (none)	No: `isSecure=false, ip=127.0.0.1`	422 422 422 422 422 429 429 429
`at: '*'`	Yes: `isSecure=true, ip=1.2.3.4`	422 422 422 422 422 422 422 422 (throttle bypassed)
`at: '10.0.0.0/8'` (not the sender)	No	422 422 422 422 422 429 429 429

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware): void {
    $middleware->trustProxies(at: '10.0.0.0/8');   // your load balancer's address range
})

With at: '*' any client could pretend to be any IP, which defeats IP-based throttling and corrupts your logs. Using '*' is only reasonable when the app can be reached exclusively through the proxy, for example inside a private network where the proxy is the only way in. Otherwise list your proxy's IP or CIDR range. The method also takes an array, which I did not test.

7. Trust your own hostnames

Laravel builds URLs from the request's Host header unless told otherwise. A password-reset email that uses url() or route() can then link to an attacker's domain if they send a forged Host. I requested a route that returns url('/reset-password/abc123'):

curl -s -H "Host: evil.example" http://127.0.0.1:8300/host

{"host":"evil.example","url":"http://evil.example/reset-password/abc123", ...}

The fix is trustHosts:

$middleware->trustHosts(at: ['^app\.example\.com$']);

APP_ENV=production, Host: evil.example     -> status 400
APP_ENV=production, Host: 127.0.0.1:8300   -> status 200 (an allowed host)

One trap I hit: the middleware does nothing when APP_ENV=local. The framework's shouldSpecifyTrustedHosts() returns false in the local environment and in unit tests, so in my first attempt the forged host still got a 200. Test it with production settings, or you will believe it works when it does not.

8. Send security headers

Laravel sends none. A small middleware covers the common ones:

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class SecurityHeaders
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);

        $response->headers->set('X-Content-Type-Options', 'nosniff');
        $response->headers->set('X-Frame-Options', 'DENY');
        $response->headers->set('Referrer-Policy', 'strict-origin-when-cross-origin');
        $response->headers->set('Permissions-Policy', 'camera=(), microphone=(), geolocation=()');

        if ($request->isSecure()) {
            $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
        }

        return $response;
    }
}

// bootstrap/app.php
$middleware->append(\App\Http\Middleware\SecurityHeaders::class);

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

HSTS only appears when the request is seen as secure, so it depends on item 6: behind an HTTPS-terminating proxy that you have not trusted, isSecure() is false and the header is never sent (I confirmed both outcomes in the table above, with HSTS present only under at: '*'). Start with a short max-age while you test, because browsers remember HSTS. A Content-Security-Policy is the strongest header against XSS, but it needs tuning to your scripts and styles, so I left it out of this generic example.

The test server also sent X-Powered-By: PHP/8.3.6. Set expose_php = Off in php.ini to stop advertising the version (standard PHP setting, not tested here).

9. Keep CSRF protection on

In Laravel 13.40 the web middleware group includes PreventRequestForgery, and the older VerifyCsrfToken class is a deprecated subclass of it. A POST without a token:

curl -s -o /dev/null -w "%{http_code}\n" -X POST http://127.0.0.1:8300/ping
# 419

If you must exclude a route, such as a payment provider's webhook, do it narrowly, and verify the sender some other way (a signature check), because an excluded route has no CSRF protection at all:

$middleware->preventRequestForgery(except: ['webhooks/stripe']);

The method also has originOnly and allowSameSite options in the 13.40 source; read their docs before changing them. If real users hit 419 errors, see Laravel 419 Page Expired: causes and fixes rather than turning the protection off.

10. Harden login: hashing, throttling, sessions

Hashing. The skeleton sets BCRYPT_ROUNDS=12. Cost doubles with each extra round, so measure on your hardware. On this machine:

bcrypt rounds=10:   51 ms
bcrypt rounds=12:  198 ms
bcrypt rounds=14:  796 ms

Those are single runs; the pattern (about 4 times slower per two rounds) is what matters. Pick the highest cost your login endpoint can afford under load, and use Hash::needsRehash() at login to upgrade old hashes as users sign in. PHP here also offered argon2i and argon2id.

Throttling. Login routes need a rate limit. The built-in middleware worked as expected on a route with throttle:5,1:

attempt 1-5 -> 422  X-RateLimit-Limit: 5  X-RateLimit-Remaining: 4 ... 0
attempt 6   -> 429  Retry-After: 59

For guests that limit is keyed by IP address, which is why item 6 matters. A more targeted limiter keys on the account as well. This is the standard form from the Laravel documentation, not something I ran:

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('login', function (Request $request) {
    return Limit::perMinute(5)->by(strtolower($request->input('email')).'|'.$request->ip());
});

// Route::post('/login', ...)->middleware('throttle:login');

For API limits and algorithms in depth, see API rate limiting strategies.

Sessions. Auth::attempt() regenerates the session ID, which blocks session fixation. I checked it in the sessions table: before login the newest row had a null user_id; after login the ID was different and user_id was set. In the source this is $this->session->regenerate(true) in SessionGuard::updateSession(). If you write your own login code, call $request->session()->regenerate() yourself.

11. Authorize every record access (the IDOR check)

Authentication tells you who the user is. Authorization decides what they may touch. Route model binding fetches any record, for anyone, unless you check. I logged in as alice and requested bob's record on two routes:

// No check: any logged-in user can read any user's email
Route::get('/users/{user}/email-unsafe', fn (User $user) => $user->email)
    ->middleware('auth');

// With an ownership check
Route::get('/users/{user}/email-safe', function (User $user) {
    Gate::allowIf(fn ($auth) => $auth->is($user));
    return $user->email;
})->middleware('auth');

alice reads bob, no check:      bob@example.test
alice reads bob, ownership check: status 403
alice reads herself:             alice@example.test

For real apps, use policies ($this->authorize('view', $invoice) or Gate::authorize()) and write a test per resource that logs in as a second user and expects a 403. This is the bug most likely to survive review, because no error ever appears.

12. Block mass assignment

Passing $request->all() into create() lets a client set any column, including ones your form never showed. Laravel 13's skeleton User model whitelists fields with an attribute:

#[Fillable(['name', 'email', 'password'])]
#[Hidden(['password', 'remember_token'])]
class User extends Authenticatable { /* ... */ }

I compared that with an unguarded model on the same table (protected $guarded = [];), posting is_admin=1 to both:

// Vulnerable
$u = LooseUser::create($request->all());

// Safer: validate, and use only validated data on a model that whitelists fields
$data = $request->validate([
    'name' => 'required|string|max:100',
    'email' => 'required|email|unique:users',
    'password' => 'required|min:12',
]);
$u = User::create($data);

unguarded model + $request->all():       {"is_admin":1}
validated data + whitelisted model:      {"is_admin":0}

Treat $guarded = [] as a bug unless the data is never from a request. In development, Model::shouldBeStrict() turns silently discarded attributes into exceptions (see the performance article for how it behaves).

13. Never interpolate into SQL, never print raw HTML

SQL. Bound parameters are the defense. Here are two raw queries, one with the input pasted into the string and one with a placeholder, given the classic payload ' OR '1'='1:

// Vulnerable
DB::select("select id, name from users where name = '{$request->query('name')}'");

// Safe
DB::select('select id, name from users where name = ?', [$request->query('name')]);

interpolated: [{"id":1,"name":"alice"},{"id":2,"name":"bob"}]   (every row returned)
bound:        []

The same rule applies to whereRaw(), selectRaw() and orderByRaw(). Bindings protect values, not column names: if a user chooses the sort column, check it against an allow-list. See Eloquent vs Query Builder for when each fits.

XSS. I rendered <script>alert(1)</script> both ways:

{{ $q }}     -> <p>escaped: &lt;script&gt;alert(1)&lt;/script&gt;</p>
{!! $q !!}   -> <p>raw: <script>alert(1)</script></p>

Use {!! !!} only for HTML you generated yourself. If users may submit HTML, run it through a sanitizer first (I did not test one) and add a Content-Security-Policy.

14. Treat uploads as hostile

Never trust the file extension or the client's content type. I uploaded a real PNG, a PHP script renamed evil.jpg (sent with Content-Type: image/jpeg) and a file named evil.php, against this validation:

$request->validate([
    'avatar' => ['required', 'image', 'mimes:jpg,jpeg,png', 'max:2048'],
]);
$path = $request->file('avatar')->store('avatars');

real.png  -> {"stored":"avatars/JNQgygKEpFyrUOQkyojulvOi4gEUyGBJvg1fq290.png"}
evil.jpg  -> "The avatar field must be an image." / "must be a file of type: jpg, jpeg, png."
evil.php  -> the same two errors

Laravel checks the file's real content, so renaming does not pass. Two more details from the result: the stored name is random (store() generates it, so never use the client's filename), and the file landed in storage/app/private/avatars/, outside the web root. Keep uploads on a private disk and serve them through a controller or signed URLs unless they must be public. Also set a request size limit at the web server and in PHP (upload_max_filesize, post_max_size), which I did not test.

15. Audit dependencies and keep patching

composer install --no-dev --optimize-autoloader   # no dev tools on the server
composer audit                                      # check installed packages against known advisories

The composer audit command is present in Composer 2.8.12 here. I could not run it, because it fetches advisories from Packagist, which this environment cannot reach. Run it in CI on every build and on a schedule, since new advisories appear for code you have not changed. Keep the framework current within your major version (this article's tests used 13.40.0), and read the release notes of security releases. If you are on Laravel 12, see the 12 to 13 upgrade guide.

Infrastructure items I did not test

These matter just as much and live outside the Laravel app, so verify them in your own environment:

The database, Redis and any queue backend should not be reachable from the internet. Bind to private addresses and use a firewall or security group.
Use separate database users for the app and for migrations, with the least privileges that work.
Only storage and bootstrap/cache need to be writable by the web server user.
Keep backups, and test restoring one.
Do not log passwords, tokens or full request bodies.

Pre-launch checklist

#	Check	How to verify
1	`APP_ENV=production`, `APP_DEBUG=false`	`php artisan about`
2	Document root is `public/`	`curl -I https://site/.env` returns 404 or 403
3	Key not in git, rotation plan exists	Check `.gitignore`, note `APP_PREVIOUS_KEYS`
4	Config cached, no `env()` outside config	`php artisan optimize`, search for `env(` in `app/`
5	HTTPS redirect and secure cookies	`SESSION_SECURE_COOKIE=true`, inspect `Set-Cookie`
6	Trusted proxies set to your proxy only	Forged `X-Forwarded-For` does not change `$request->ip()`
7	Trusted hosts set	Forged `Host` gets a 400 in production mode
8	Security headers present	`curl -sI https://site \
9	CSRF on, exclusions justified	POST without a token returns 419
10	Login throttled	Sixth bad attempt returns 429
11	Policies on every record route	A second-user test expects 403
12	No {% raw %}`$guarded = []` with request data	Search for `guarded` and `$request->all()`
13	No interpolated raw SQL, no raw Blade output	Search for `Raw(`, `DB::select("` and `{!!`
14	Uploads validated and stored privately	Upload a renamed script and expect a validation error
15	`composer audit` clean in CI	CI job output

Common mistakes

Checking security only in the local environment. Trusted hosts does nothing in local, and debug is on by default there.
UsingtrustProxies(at: '*')because it makes HTTPS detection work. It also makes IP addresses forgeable.
Authenticating but not authorizing. middleware('auth') only proves someone is logged in.
Disabling CSRF globally to fix a 419. Find the cause instead.
Validating by file extension. Use content-based rules and a private disk.
Relying on a WAF or CDN instead of fixing the app. They reduce noise; they do not repair an IDOR.
Committing.env.production. The skeleton ignores it for a reason.

Frequently asked questions

Is Laravel secure by default?

For the common injection and CSRF cases, yes, as the tests above show. It is not secure by default in the areas that depend on your configuration and your code: debug mode, web server layout, proxy and host trust, throttling, headers and authorization.

What is the difference between APP_ENV and APP_DEBUG?

APP_DEBUG controls whether detailed errors are shown. APP_ENV names the environment, and some framework behavior depends on it, such as trusted hosts, which is skipped in local. Set both.

Do I need all of these if I'm behind Cloudflare or a load balancer?

Yes. A proxy does not know your business rules, so it cannot fix a missing authorization check, mass assignment or unsafe SQL. It also makes the proxy-trust settings more important, not less.

Should staging have debug mode off too?

If it is reachable from the internet, yes, and it should not contain real customer data.

How often should I run composer audit?

On every CI build, plus a scheduled run (daily or weekly), because advisories are published for code you did not change.

Originally published on DEV Talk.

PostgreSQL vs MySQL Performance: Real Benchmarks Compared

devTalk — Thu, 12 Nov 2026 13:42:07 +0000

Last updated: 7 November 2026. See theupdate logat the end.

"Which is faster, PostgreSQL or MySQL?" has no single answer, because speed depends on the query, the data, the settings and the version. Most comparisons you will find change several of those at once. So I ran both on the same machine, loaded identical data, used matching memory settings, and measured typical web-application workloads: simple reads, mixed reads and writes, reporting queries, indexes, and what happens to a table under heavy updates. The results are below, along with the places where the numbers do not mean what they seem to.

The short answer

Workload	What I measured	Result in this test
Simple point reads	sysbench, 8 connections	PostgreSQL about 1.7 to 2.2 times the throughput
Mixed read/write transactions	sysbench, 8 connections	PostgreSQL about 2.1 to 2.5 times the throughput
Aggregates and joins over 2M rows	GROUP BY, JOIN	PostgreSQL 5 to 6 times faster
Table size after heavy updates	5 full-table updates	PostgreSQL grew 30 to 113 MB; MySQL stayed at 24.5 MB
Single primary-key lookup from PHP	one connection, sequential	MySQL about 2 times faster (0.06 vs 0.12 ms)
Cost of opening a connection	PDO connect, localhost	MySQL 0.16 ms, PostgreSQL 1.62 ms

That is one small machine, one workload generator and two specific versions. Read the caveats before you quote any of it.

How I tested

Item	Setting
Hardware	2 vCPU, 8 GB RAM Linux container, client and servers on the same machine
PostgreSQL	16.15 (Ubuntu package), `shared_buffers=1GB`, `fsync=on`, `synchronous_commit=on`, autovacuum on
MySQL	8.0.46 (Ubuntu package), `innodb_buffer_pool_size=1G`, `innodb_flush_log_at_trx_commit=1`, binary log off (PostgreSQL has no equivalent second log, so I switched it off for parity)
Load generator	sysbench 1.0.20, 4 tables of 100,000 rows, 20 second runs
Other tests	PHP 8.3.6 PDO, a 2,000,000-row table loaded identically into both (the `sum(amount)` checksums matched)

Both are close to default settings apart from memory. I did not tune either server for its workload. Versions matter here: MySQL 8.0 reached end of life on 30 April 2026, and the supported LTS lines are 8.4 and 9.7. PostgreSQL 16 is still supported (until November 2028), and 18 is the newest release I could confirm. Results on those newer versions may differ, so treat these as a snapshot of what Ubuntu 24.04 ships.

Result 1: OLTP throughput with sysbench

sysbench's standard transactional workloads. TPS is transactions per second, so higher is better. The 8-thread figures are the first run; I repeated some workloads and give the range.

Workload	Threads	PostgreSQL TPS	MySQL TPS	95th percentile latency (PG / MySQL)
point_select	1	23,557	17,646	0.06 / 0.08 ms
point_select	8	142,737 (range 120,940 to 142,737)	85,080 (range 55,926 to 85,080)	0.09 / 0.19 ms
read_only	1	1,146	831	1.03 / 1.39 ms
read_only	8	5,250	2,761	1.86 / 4.65 ms
read_write	1	710	464	1.70 / 2.91 ms
read_write	8	1,963 (range 1,694 to 1,963)	780 (range 762 to 789)	6.43 / 18.61 ms
write_only	1	1,959	1,280	0.67 / 1.25 ms
write_only	8	6,246	2,278	2.03 / 7.98 ms

PostgreSQL was ahead in every row. Three things to know about the numbers:

Run-to-run noise is real. The point-select results varied by 20 to 30 percent between runs, because the load generator shares two CPUs with the database. The ratio stayed between 1.7 and 2.2, but do not quote the absolute figures.
MySQL'sperformance_schemawas not the reason. It is on by default and costs some throughput, so I restarted MySQL with it off and reran two workloads: 78,803 TPS for point_select and 789 for read_write, in line with the earlier runs.
PostgreSQL reported a few ignored errors under write load: 13 in the 8-thread read_write run and 99 in write_only, out of roughly 39,000 and 125,000 transactions. The server log showed duplicate-key errors from concurrent delete-and-reinsert of the same row, which sysbench ignores by default. MySQL reported none. They are a tiny fraction of transactions and do not change the picture, but a real application would have to retry them.

Result 2: reporting queries over 2 million rows

Same table and same data in both (events: id, user_id, kind, amount, created_at; plus a 50,000-row users table). I timed each query nine times inside one persistent PHP PDO connection and took the median. No secondary indexes on events.

Query	PostgreSQL	MySQL
`count(*)`	37 ms	40 ms
`GROUP BY kind` with count, sum, avg	120 ms	616 ms
`JOIN users GROUP BY region`	213 ms	1,321 ms
`ORDER BY id LIMIT 20 OFFSET 1900000`	84 ms	200 ms
Keyset: `WHERE id > 1900000 ... LIMIT 20`	0.14 ms	0.72 ms
Primary key lookup	0.12 ms	0.06 ms

Part of PostgreSQL's lead on the heavy queries is parallel query. With set max_parallel_workers_per_gather=0 its GROUP BY went from 120 to 211 ms and the join from 213 to 378 ms, which is still well ahead of MySQL's single-threaded run. Two lessons from the pagination rows: a deep OFFSET is slow on both (so use keyset pagination, as in the Laravel pagination article), and MySQL is faster at the single primary-key lookup, though both are far below a millisecond.

Result 3: adding an index made MySQL's join slower

This one surprised me, and it is why you should check plans instead of assuming. I created an index on events(user_id) in both databases, ran ANALYZE, and repeated the join:

JOIN + GROUP BY region	Before index	After index on user_id
PostgreSQL	213 ms	203 ms (same plan: hash join)
MySQL 8.0.46	1,321 ms	2,094 ms

MySQL's plan flipped. Before the index it scanned events and looked up each row's user by primary key. After it, the optimizer chose to scan users and do one index lookup into events per user (50,000 lookups returning about 40 rows each), which its cost estimate rated cheaper and which was slower in practice. This is MySQL 8.0.46 only; I did not test 8.4 or 9.7. The index helped exactly the query it was made for: WHERE user_id = 123 took 0.08 ms in MySQL and 0.13 ms in PostgreSQL. Also in my measurements, MySQL's count(*) went from 40 to 124 ms after the index was added, and I did not investigate why.

Building the index took 421 ms in PostgreSQL and 1,922 ms in MySQL (single runs, wall time from the command-line clients).

Result 4: what repeated updates do to the table

PostgreSQL's design keeps old row versions in the table until VACUUM removes them. I took a 100,000-row table, disabled autovacuum for it to make the test deterministic, and ran update sbtest1 set k = k + 1 five times in both databases.

                          PostgreSQL                         MySQL (InnoDB)
before:                   30 MB table, 4.7 MB indexes        24.5 MB table, 1.5 MB indexes
after 5 full updates:     113 MB table, 11 MB indexes        24.5 MB table, 5.0 MB indexes
                          dead_tuples = 500000
after plain VACUUM:       113 MB table, dead_tuples = 0
5 more updates:           114 MB table (space reused)

The table in PostgreSQL grew to nearly four times its size, and a plain VACUUM made the space reusable but did not shrink the file (VACUUM FULL does, with a lock). In production autovacuum is on by default and normally keeps up, since I disabled it here to show the mechanism, but tables with heavy updates still need monitoring. In MySQL the table stayed the same size; the secondary index did grow, from 1.5 to 5.0 MB. The "before" sizes include some leftovers from the earlier benchmark runs.

Result 5: connections

new PDO connection (localhost, TCP):   PostgreSQL 1.62 ms    MySQL 0.16 ms
"select 1" on an open connection:      PostgreSQL 0.10 ms    MySQL 0.04 ms

Opening a PostgreSQL connection was about ten times more expensive than a MySQL one, which matters if your application opens a connection per request without pooling. Under heavy traffic, put a pooler such as PgBouncer in front of PostgreSQL. I did not test PgBouncer. The "select 1" gap is mostly a driver and protocol effect: sysbench uses prepared statements, where PostgreSQL was faster per query, while PHP's plain query() was faster on MySQL. Differences this small say more about the client than the database.

How to run this comparison on your own data

Benchmark your own queries on your own schema. The commands I used, with the connection details changed to yours:

# load the test tables (PostgreSQL shown; use --db-driver=mysql and --mysql-* options for MySQL)
sysbench oltp_read_write --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 \
  --pgsql-user=postgres --pgsql-db=sbtest --tables=4 --table-size=100000 prepare

# run it
sysbench oltp_read_write --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 \
  --pgsql-user=postgres --pgsql-db=sbtest --tables=4 --table-size=100000 \
  --threads=8 --time=20 run

Run each workload more than once, at more than one thread count, and read the "ignored errors" line. For your real queries, time them inside one open connection and read the plan:

-- PostgreSQL
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;

-- MySQL 8.0.18 and later
EXPLAIN ANALYZE SELECT ...;

-- watch for dead rows in PostgreSQL
SELECT relname, n_live_tup, n_dead_tup FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10;

Common mistakes when comparing databases

Comparing different settings. Match buffer memory and durability, or you are comparing configurations, not databases.
Mixing connection methods. My first timings used a unix socket for one and TCP for the other, and the results were wrong. Use the same transport and a persistent connection.
Timing the client startup. A new psql or mysql process per query measures process start, not the query.
ForgettingANALYZE. Planners need fresh statistics after a bulk load.
Trusting one run. Repeat, and look at the spread.
Adding an index and not re-checking the plan. As Result 3 shows, an index can change a plan for the worse.
Benchmarking an end-of-life version. MySQL 8.0 is past end of life; test the version you would actually deploy.

Choosing: what the numbers do and do not say

For reporting, aggregates and joins over millions of rows, PostgreSQL was clearly faster here, partly through parallel query.
For many small, simple queries, both were fast, and MySQL was quicker on a single primary-key lookup and at opening connections.
For tables with heavy updates, PostgreSQL needs vacuum monitoring and MySQL does not have that particular concern.
Application fit usually matters more than these gaps: the team's experience, the tooling, the hosting options, and how close you already are to one of them. Laravel works with both. If you are already on MySQL 8.0, moving to 8.4 is the more urgent job (see the MySQL 8.0 to 8.4 upgrade guide), and most slow pages come from queries and indexes before they come from the database engine (see Laravel 13 performance optimization).

Frequently asked questions

Is PostgreSQL faster than MySQL?

In this test, with near-default settings on a small machine, PostgreSQL 16 was faster on every sysbench workload and on aggregate and join queries. That is not a law. It depends on version, settings, hardware and workload, so test with your own queries.

Should I migrate from MySQL to PostgreSQL for speed?

Not on these numbers alone. Fix slow queries and missing indexes first, and weigh migration cost, tooling and team experience. If you are on MySQL 8.0, upgrading to a supported version is the priority.

Does Laravel work with both?

Yes, the framework supports both databases. Check the Laravel documentation for any feature that is specific to one of them.

What about MariaDB?

I did not test it, so I have no numbers for it.

Would you get the same results on bigger hardware?

I do not know. I ran on 2 vCPUs with the load generator on the same machine; multi-core servers, faster disks and separate client machines could change the ratios.

Originally published on DEV Talk.

How to Detect and Fix PHP Memory Leaks

devTalk — Thu, 12 Nov 2026 03:24:24 +0000

Last updated: 5 November 2026. See theupdate logat the end.

In a normal PHP-FPM request, a memory leak mostly does not exist: PHP frees everything when the request ends. The leaks people actually hit happen in processes that stay alive: queue workers, daemons, long import scripts, and application servers like Laravel Octane. The symptom is always the same. Memory climbs a little with every job or request, then something dies with Allowed memory size exhausted, or the operating system kills the process, hours after the code that caused it ran. This article shows how to confirm that you have a leak, the four causes I would check first (each reproduced and measured), how to find the guilty objects, and how to contain a leak you cannot fix immediately.

If your problem is one request using too much memory in a single go, that is not a leak. See PHP "Allowed memory size exhausted" instead.

How I tested

PHP 8.3.6 CLI, and the Laravel 13.35 database and events code (the real classes, run outside a full application) on SQLite. All memory figures come from memory_get_usage() unless stated. Each result is one run; the growth patterns are what matter, not the exact megabytes.

Step 1: Confirm it is a leak, not just a big job

A leak is memory that keeps growing as you repeat the same work. Process the same unit of work many times and print memory every so often. If it plateaus, you do not have a leak. If it rises in a straight line, you do.

<?php
function report(string $label): void
{
    printf("%s: %.1f MB (peak %.1f MB)\n",
        $label, memory_get_usage() / 1048576, memory_get_peak_usage() / 1048576);
}

for ($round = 1; $round <= 5; $round++) {
    for ($i = 0; $i < 10000; $i++) {
        handleOneJob();            // your code here
    }
    gc_collect_cycles();           // so cycles don't hide the real result
    report("after round $round");
}

The gc_collect_cycles() call matters. It frees unreachable circular references, so whatever growth remains afterwards is memory that your code is still holding on to. Three PHP functions worth knowing while you measure:

memory_get_usage() is what your script has allocated. memory_get_usage(true) is what PHP has reserved from the system, in larger chunks. In my test with one 5 MB string they reported 5.4 MB and 7.0 MB. Laravel's queue worker checks the true value.
memory_get_peak_usage() is the high-water mark. Since PHP 8.2, memory_reset_peak_usage() resets it so you can measure one phase at a time. My test: a freed 50 MB string left the peak at 50.4 MB, and after the reset the peak read 0.4 MB.

Cause 1: a static array, singleton or global that only grows

The classic leak. Something stores data "for later" and nothing ever removes it. I simulated 50,000 units of work, each storing a 1 KB payload:

class Cache { public static array $items = []; }

Cache::$items[$id] = $payload;     // grows forever

unbounded static cache:      after 10000: 12.9 MB ... after 50000: 62.5 MB
bounded cache (max 1000):    after 10000:  1.7 MB ... after 50000:  1.7 MB

Fixes, in order of preference: do not cache at all if the data is cheap to reload; bound the cache (a maximum size that evicts the oldest entry); or tie the lifetime of cached data to the object it belongs to with WeakMap, which drops an entry when its key object is freed:

$map = new WeakMap();
$user = new stdClass();
$map[$user] = ['expensive' => 'data'];
echo count($map);   // 1
unset($user);
echo count($map);   // 0

In Laravel the same trap hides in singletons registered in the container, static properties on services, and traits with static state. They are harmless under PHP-FPM and dangerous under Octane or queue:work. The Octane documentation (the 9.x docs page; check the current one) gives exactly this example: adding data to a static array on each request is a memory leak, because Octane keeps the application in memory between requests.

Cause 2: circular references, and why PHP's garbage collector does not always save you

PHP frees most values the moment nothing references them. Objects that reference each other never reach zero, so PHP has a separate cycle collector. It works, and that is why cycles are less often the culprit than people expect. I created 100,000 pairs of objects pointing at each other and threw them away:

GC enabled:  after 100000: 2.5 MB   gc runs=19  collected=285000
GC disabled: after 100000: 42.1 MB  gc runs=0   roots=200000
             manual gc_collect_cycles() freed 300000; memory back to 2.4 MB

So with the collector on, those cycles cost nothing lasting. The catch is when it runs. The collector triggers when the number of possible cycle roots reaches a threshold (gc_status()['threshold'] was 10001 in my test), not when memory gets high. Large objects in cycles can therefore exhaust memory before the collector ever wakes up. I created objects that referenced themselves and each held 200 KB, with a 128 MB limit:

GC enabled, large self-referencing objects:
iteration 500: 96.2 MB
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

same loop with gc_collect_cycles() every 100 iterations:
iteration 3000: 0.4 MB   finished

In a loop that creates big cyclic structures (parsed documents, large object graphs), call gc_collect_cycles() every few hundred iterations, or break the cycle. Do not call it on every iteration and do not turn the collector off: it has a cost, and disabling it just made the first test above 17 times worse.

The sneaky cycle: a closure that captures $this

An arrow function or closure created inside a method captures $this automatically. If you store that closure on the same object, you have built a cycle. I tested with WeakReference to see when the object was really freed, with the collector disabled:

class Report {
    public $cb; public $data;
    public function __construct(bool $static) {
        $this->data = str_repeat('x', 100000);
        $this->cb = $static ? static fn () => 1 : fn () => $this->data;
    }
}

capturing closure: freed right after unset? NO (waits for GC)
static closure:    freed right after unset? yes

If a callback does not use $this, declare it static. It cannot create the cycle, and the object is released at once.

Cause 3: listeners and callbacks registered over and over

Registering an event listener inside code that runs per job or per request adds a new listener every time. Each one holds a closure and everything that closure captured. I registered one listener per "job" on Laravel's event dispatcher:

registered once:    after 20000 jobs: 0.9 MB   listeners=1
registered per job: after 20000 jobs: 16.2 MB  listeners=20000

Memory grew in a straight line, and every event dispatch also gets slower because it now calls 20,000 listeners. In Laravel, register listeners once, in a service provider's boot() method or the event-to-listener mapping, never inside a job's handle(), a controller, or a loop. The same applies to Model::observe(), macros, and any on()/listen() call on a long-lived object.

Cause 4: the query log in a long-running process

Laravel can record every query. It is off by default, which is why this shows up only when someone turns it on for debugging and forgets, or a package does. In a worker or a long command it grows without limit. I ran 20,000 trivial queries through the database connection:

query log off: after 20000 queries: 4.8 MB  log entries=0
query log on:  after 20000 queries: 18.2 MB  log entries=20000
after DB::connection()->flushQueryLog(): 4.8 MB

// if you need the log inside a long loop, clear it as you go
DB::connection()->enableQueryLog();
foreach ($ids->chunk(500) as $chunk) {
    // ... work ...
    DB::connection()->flushQueryLog();
}
DB::connection()->disableQueryLog();

Search your code and your debugging packages for enableQueryLog. A related case is not a leak but looks like one: loading whole tables into memory. Use chunkById(), lazyById() or cursor(). I measured 54 MB for get() on 20,000 rows against 8 to 12 MB for the streaming options in the Laravel 13 performance article.

Find out which objects are being kept: php-meminfo

When the usual suspects do not explain it, you need to see what is in memory. The php-meminfo extension dumps every live item in a process to JSON. I built it from source against PHP 8.3.6 (phpize, ./configure --enable-meminfo, make) and ran a dump after creating 1,500 objects that were kept and 300 that were not:

// php -d extension=/path/to/meminfo.so script.php
$fh = fopen('/tmp/dump.json', 'w');
meminfo_dump($fh);
fclose($fh);

Counting the objects by class in that dump:

[('Order', 1500), ('Tmp', 1)]

The class that has far more instances than it should is your leak. The project ships an analyzer for this; its README documents the commands bin/analyzer summary, top-children, query -f "class=Order" and ref-path <item-id>, where ref-path shows what is still referencing a given object. I could not run the analyzer (it needs Composer packages that I could not download), so I counted classes with a short script instead.

Two warnings. The README lists PHP 7.x and 8.0 and the last commit I saw was from March 2022, so treat it as an unmaintained tool: it worked for a dump on 8.3.6 in my test, but try it on a staging copy first. And dumps of a real worker are large, so never run it in production traffic.

Contain a leak you cannot fix today

Recycling the process is a legitimate stopgap, as long as you treat it as a stopgap.

Laravel queue workers. From the Laravel 13 source:

php artisan queue:work --memory=256 --max-jobs=1000 --max-time=3600

--memory defaults to 128 (MB). In the 13.x source it also accepts a percentage of PHP's memory_limit, such as 50%. The worker compares memory_get_usage(true) in MB with the limit, and when it is reached the worker exits with status code 12.
--max-jobs and --max-time stop the worker after that many jobs or seconds.
A stopped worker needs something to start it again, such as Supervisor or systemd. See Laravel queue jobs not processing or stuck. Set --memory below the PHP memory_limit, so the worker exits cleanly between jobs instead of dying in the middle of one.

PHP-FPM. In a pool configuration, pm.max_requests is the number of requests a child handles before it is respawned. The PHP manual says this can be useful to work around memory leaks in third-party libraries, and the default is 0, meaning never respawn:

pm.max_requests = 500

Octane. The 9.x documentation says Octane restarts a worker after 500 requests by default, adjustable with php artisan octane:start --max-requests=250. I did not run Octane for this article.

Common mistakes

Trusting a single measurement. One reading proves nothing. Repeat the work and watch the trend.
Measuring without collecting cycles first. You may be chasing garbage that PHP was about to free.
Callingunset()and expecting the process size to shrink. PHP reuses freed memory internally. Judge by memory_get_usage() across rounds, not by the process size in top.
Disabling the garbage collector for speed. My cycle test shows what that costs.
Raisingmemory_limitinstead of finding the growth. It only delays the crash.
Leaving debug tools on. Query logging, event recording and similar tools hold everything they record.
Treating restarts as the fix. --max-jobs and pm.max_requests hide the leak, and a leak that grows fast enough still kills the process between restarts.

Frequently asked questions

Does PHP have memory leaks?

PHP itself frees all request memory at the end of a request, so ordinary PHP-FPM apps rarely leak in the long-term sense. Long-running processes can accumulate memory through your code (static data, listeners, logs), through reference cycles that have not been collected yet, and occasionally through bugs in extensions or libraries.

Should I call gc_collect_cycles() in my code?

Only in long loops that create large cyclic structures, and every few hundred iterations rather than every iteration. My test showed it can be the difference between finishing and a fatal error. For small objects the automatic collector is enough.

Why does the process memory in top not go down after unset()?

PHP keeps freed memory to reuse it. memory_get_usage(true) reports memory PHP has reserved, which is larger than what your data uses (7.0 against 5.4 MB in my test). Judge growth by the trend across rounds.

Is Xdebug the right tool for finding leaks?

I did not test it for this. I used built-in memory functions to find the trend and php-meminfo to see what is held, so use those first.

Is a memory limit on queue workers a real fix?

No. It protects you from a crash by restarting cleanly. Use it as a safety net while you find the cause.

Originally published on DEV Talk.

Docker Build Too Slow? 10 Ways to Speed It Up

devTalk — Wed, 11 Nov 2026 14:53:07 +0000

A slow Docker build usually has one of a few causes: you are sending far more files to the builder than you need, a cheap change at the top of the Dockerfile throws away an expensive step below it, or every build re-downloads packages it fetched an hour ago. All of these are fixable without changing your application. This article goes through ten fixes in the order I would try them. Most of them I ran and timed on a real Docker Engine, and I show the output, so you can compare it with what you see on your machine.

Step 0: how I tested, and what the numbers mean

Docker Engine 29.8.2, Buildx 0.37.1, BuildKit 0.33.1, on Linux with the containerd image store. The environment could not pull images from Docker Hub, so I built a tiny local base image (a shell plus a few core tools) and used sleep 4 as a stand-in for a slow dependency install. That makes the cache behaviour real, because the cache does not care what a step does, but the absolute timings are not what npm install or composer install will take on your project. Every timing is a single run. Look at the ratios, then measure your own project.

1. Find out which step is slow before changing anything

Run the build with plain progress output. It prints each step and how long it took, and marks steps served from cache:

docker build --progress=plain -t myapp .

#6 [2/5] WORKDIR /app
#6 CACHED
#8 [4/5] RUN sleep 4 && mkdir -p node_modules
#8 CACHED
#9 [5/5] COPY src ./src
#9 DONE 0.0s

Look for three things: transferring context with a large size (see technique 2), steps near the top that are not CACHED on a rebuild (techniques 3 and 9), and a single step that dominates the total (techniques 4 and 5). The default fancy progress view hides most of this, so use --progress=plain while you investigate.

2. Add a .dockerignore file

When your Dockerfile has COPY . ., Docker has to send everything in the build directory to the builder: .git, node_modules, logs, local build output. I made a project with 450 MB of that kind of material and one small source file, then built with COPY . .:

without .dockerignore:  transferring context: 472.0MB   total 33.9 s
with .dockerignore:     transferring context: 254B       total  1.0 s

A starting point for a Laravel project:

.git
node_modules
vendor
storage/logs
storage/framework/cache
storage/framework/sessions
storage/framework/views
.env
.env.*
*.log
.idea
.vscode

Excluding .env matters for more than speed: otherwise COPY . . bakes your local secrets into an image layer. Only exclude vendor if the image installs its own dependencies, as in the example near the end. One detail from my testing: BuildKit transfers only the files a COPY actually references. With COPY src ./src the same 450 MB project transferred 79 bytes, so the huge-context problem shows up with COPY . ., which is what most Dockerfiles use.

3. Order layers from least to most frequently changed

Docker reuses a cached layer only if the instruction and everything before it are unchanged. If COPY . . comes first, any source edit invalidates the dependency install after it. Here is the same 4-second "install" step in both orders, timed after changing one line of source:

# Slow: source copied first
FROM mini:1
WORKDIR /app
COPY . .
RUN sleep 4 && mkdir -p node_modules

# Fast: manifest first, install, then source
FROM mini:1
WORKDIR /app
COPY package.json .
RUN sleep 4 && mkdir -p node_modules
COPY src ./src

slow order, after a source edit: 4.6 s
fast order, after a source edit: 0.3 s

For real projects this means copying package.json and package-lock.json, or composer.json and composer.lock, before the rest of the code, and running the install in between.

4. Use cache mounts for package downloads

Layer caching helps until the manifest changes. Add one dependency and the whole install reruns, re-downloading everything. A BuildKit cache mount keeps the package manager's download cache between builds, outside the image:

COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci

I tested the mechanism with a step that "downloads" for 4 seconds only when its cache directory is empty, and changed package.json between builds so the layer was invalidated each time:

without cache mount: first 4.7 s | after package.json change 4.5 s
with cache mount:    first 4.7 s | after package.json change 0.5 s
after docker builder prune -af:   4.7 s again

The Docker documentation lists cache targets for common tools: /root/.npm for npm, /root/.cache/pip for pip, /root/.gem for Bundler, /go/pkg/mod and /root/.cache/go-build for Go, /tmp/cache for Composer, and for apt /var/cache/apt and /var/lib/apt with sharing=locked. For Composer I would set the directory explicitly rather than rely on a default, using Composer's documented COMPOSER_CACHE_DIR variable (I confirmed that the variable changes composer config cache-dir):

ENV COMPOSER_CACHE_DIR=/tmp/cache
RUN --mount=type=cache,target=/tmp/cache \
    composer install --no-dev --no-scripts --no-autoloader --prefer-dist

Two cautions. The cache lives in the builder's storage, not in the image, so a fresh CI runner starts with it empty (see technique 8). And as the test shows, pruning the builder cache wipes it.

5. Split independent work into stages: BuildKit builds them in parallel

A multi-stage build keeps compilers and dev tools out of the final image, and BuildKit also runs stages that do not depend on each other at the same time. A single-stage Dockerfile runs its steps one after another. I used two independent 3-second steps:

FROM mini:1 AS front
RUN sleep 3 && echo front > /front.txt

FROM mini:1 AS back
RUN sleep 3 && echo back > /back.txt

FROM mini:1
COPY --from=front /front.txt /
COPY --from=back /back.txt /

both steps in one stage (serial):   6.9 s
two independent stages (parallel):  3.7 s

The real-world version is a Laravel image where Composer dependencies and frontend assets are separate stages. A fuller example is near the end.

6. Create and delete in the same layer

Deleting a file in a later RUN does not shrink the image; the earlier layer still holds it. Bigger images mean slower pushes, pulls and CI cache uploads. I created a 100 MB temporary file and removed it, once in two steps and once in one:

two RUN steps:
 8.19kB   RUN rm /tmp/build.tmp
 105MB    RUN dd if=/dev/urandom of=/tmp/build.tmp ...

one RUN step (create and rm joined with &&):
 16.4kB   RUN dd if=/dev/urandom of=/tmp/build.tmp ... && rm /tmp/build.tmp

That is output from docker history. Use it rather than the total size from docker image inspect for this comparison: on this containerd-store install the inspect size was larger than the sum of the layers, so I did not trust it. Typical real cases are archive downloads you extract and delete, and build tools installed for one compile step.

7. Choose a smaller, pinned base image

This one I could not measure, because I could not pull images here. The reasoning is straightforward: the base image is pulled on every fresh machine, so a smaller one means faster first builds and pulls. Pin an explicit version tag (for example a specific PHP or Node version) instead of latest, so a base image update does not silently invalidate your whole cache or change behavior. Slim and Alpine variants are smaller, but they differ from the full images (Alpine uses musl instead of glibc, which can break some native extensions), so test your app before switching. Also keep your language version supported: see the PHP 8.2 end-of-life and Node.js 20 end-of-life articles.

8. Share the build cache in CI

CI runners are usually fresh machines, so every build starts with an empty cache and rebuilds everything. Buildx can export the cache and import it on the next run. The local form is easy to try:

docker buildx build --cache-to type=local,dest=./cache,mode=max -t myapp .

# later, on another machine or after a prune
docker buildx build --cache-from type=local,src=./cache -t myapp .

I ran this, pruned the whole builder cache in between, and the second build finished in 0.4 s with every step marked CACHED. In CI you would store that directory with your CI's cache feature, or use a registry or the GitHub Actions backend. The Docker documentation's GitHub Actions example is:

- name: Build and push
  uses: docker/build-push-action@v7
  with:
    context: .
    push: true
    tags: "<registry>/<image>:latest"
    cache-from: type=gha
    cache-to: type=gha,mode=max

I did not run this on GitHub Actions. The same documentation page states that the gha backend works with the default docker driver only when the containerd image store is enabled; otherwise use a different driver. mode=max exports the layers of intermediate stages too, which matters for multi-stage builds, at the cost of a larger cache. If you build several images in one workflow, give each a separate scope, otherwise each build overwrites the previous cache.

9. Stop accidentally invalidating the cache

These are the usual culprits:

A changingARGnear the top. A build timestamp or commit SHA passed as an ARG invalidates every step after it. In my test, the same build with the same argument value was fully cached (0.3 s), and changing only the value rerun the expensive step (3.5 s). Declare such arguments at the end, just before the instruction that needs them.
COPY . .before the install, as in technique 3.
Copying files that change on every build, such as logs, caches or a generated file, which also belong in .dockerignore.
Splittingapt-get updatefromapt-get install in different RUN steps, which can leave a stale package list cached. Keep them in one step.

Docker can also lint the Dockerfile for common mistakes:

docker build --check .

Check complete, 2 warnings have been found!
WARNING: JSONArgsRecommended - https://docs.docker.com/go/dockerfile/rule/json-args-recommended/
JSON arguments recommended for CMD to prevent unintended behavior related to OS signals
WARNING: FromAsCasing - https://docs.docker.com/go/dockerfile/rule/from-as-casing/

Those two rules are style and signal-handling warnings rather than speed problems, but the check is quick and catches real mistakes.

10. Watch the builder's cache, and prune on purpose

docker buildx du        # what the build cache holds
docker builder prune    # remove unused build cache
docker builder prune -af   # remove all of it, no prompt

A full prune explains "why is my build suddenly slow again" when it follows a disk cleanup, since it also empties your cache mounts, as the technique 4 test showed. If disk space is the reason you prune, consider removing only old cache instead of everything.

Putting it together: a Laravel Dockerfile

This combines techniques 3, 4, 5 and 9 for a Laravel app. I did not build this exact file, because the official PHP, Node and Composer images could not be pulled here; each technique in it was tested separately above. Check the tags and the files your frontend build reads (the config files, resources) against your project.

FROM composer:2 AS vendor
WORKDIR /app
ENV COMPOSER_CACHE_DIR=/tmp/cache
COPY composer.json composer.lock ./
RUN --mount=type=cache,target=/tmp/cache \
    composer install --no-dev --no-scripts --no-autoloader --prefer-dist
COPY . .
RUN composer dump-autoload --optimize --no-dev

FROM node:24 AS assets
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY vite.config.js ./
COPY resources ./resources
RUN npm run build

FROM php:8.4-fpm AS app
WORKDIR /var/www/html
RUN docker-php-ext-install pdo_mysql
COPY --from=vendor /app ./
COPY --from=assets /app/public/build ./public/build

The vendor and assets stages do not depend on each other, so BuildKit can run them at the same time. The slow system-level step (docker-php-ext-install) comes before any application code, so it stays cached across code changes. After the build, the image contains neither Composer's cache nor node_modules.

Common mistakes

Optimizing without reading the timings. Use --progress=plain first.
Copying the whole project before installing dependencies. It is the most common reason the cache never hits.
Using--no-cacheas a habit. It is a debugging tool. It rebuilds everything every time.
Expecting cache mounts to survive on a fresh CI runner. They live in the builder's storage.
Leaving.envout of.dockerignore. Secrets end up in image layers.
Usinglatestas the base tag. A base image update can change behavior and bust the cache without any change in your repo.

AI Coding Prompts That Actually Improve Productivity

devTalk — Tue, 10 Nov 2026 14:16:15 +0000

Most lists of "best AI coding prompts" are collections of clever wording. Wording is rarely the problem. The real problem is that AI output still has to be checked by you, and checking is the slow part. A prompt that produces more code faster but leaves you reading 400 unfamiliar lines has not saved time. This article is about prompts that make the result cheaper to verify, and every example was run against a small PHP project so you can see the actual output, including where a prompt did not make the difference I expected.

Why "faster code" is not the same as productivity

The research does not support a simple "AI makes developers faster" story. In METR's 2025 randomized trial with 16 experienced open-source developers working on their own repositories, developers took 19% longer with AI tools than without, while believing afterwards that the tools had made them about 20% faster. METR's February 2026 follow-up used a larger group (57 developers, 800+ tasks) and found changes of -18% and -4% in task time for the two groups, which would mean faster, but neither result was statistically significant, and METR listed design problems: between 30% and 50% of developers said they skipped tasks they did not want to do without AI, and time measurements get unreliable when developers run several agents at once. METR's own conclusion is that developers are likely more sped up now, but it cannot show that with the current data. (I read the 2026 figures in a secondary write-up of METR's post, so check METR's site for the original numbers.)

The 2025 DORA report on AI-assisted development points the same direction from the team side: AI improves throughput, but often at the cost of stability when the underlying engineering foundation is weak. And the Stack Overflow Developer Survey 2026 shows what developers do in practice after an AI answer arrives: 76.5% run the code locally, 63.9% compare it against their codebase, 53.0% inspect tests and security implications, and only 9.6% use it as-is.

So the useful question is not "how do I get more code out of the model" but "how do I get output I can trust quickly". The prompts below are built around that.

The five habits that did the work

Give it a check it can run. A failing test, a command, a linter. This matters more than anything you write in the prompt.
Say what it must not touch. "Do not edit anything in tests/" costs ten words and prevents the classic cheat of changing the test to pass.
Scope the task. One bug, one file, one concern. Say "security and performance only; ignore style".
Ask for evidence in a fixed format. Line numbers, severity, the command it ran, the exact line it changed.
Ask it to report, not fix, when you want to decide. Tests that expose problems are more valuable than silent patches.

The test project

All examples use this tiny project. src/Cart.php has one real bug: it truncates instead of rounding half up.

<?php
// src/Cart.php
namespace App;

class Cart
{
    /** @param array<int, array{price_cents:int, qty:int}> $items */
    public function total(array $items, int $discountPercent): int
    {
        $sum = 0;
        foreach ($items as $item) {
            $sum += $item['price_cents'] * $item['qty'];
        }

        return (int) ($sum * (100 - $discountPercent) / 100);
    }
}

tests/run.php is a plain script with a small check($name, $expected, $actual) function and three checks. Running it fails on exactly one:

php tests/run.php

PASS  no discount
FAIL  10% off, rounds half up (expected 896, got 895)
PASS  empty cart

I ran every prompt with Claude Code 2.1.318 in print mode, giving it only the tools it needed, for example --permission-mode acceptEdits --allowedTools "Read Edit Bash(php *)". The prompts are plain text and not specific to that tool, but I only ran them in Claude Code. Model output varies from run to run, so treat each result as one sample.

Prompt 1: fixing a bug

The vague version:

The cart total is wrong, fix it

The specific version:

Running 'php tests/run.php' fails: the test '10% off, rounds half up' expects 896
but total() returns 895 for one item of 995 cents with a 10% discount. Fix the bug
in src/Cart.php only: do not edit anything in tests/. Money is integer cents, so
do not introduce floats into the return type. Run 'php tests/run.php' to confirm
all tests pass, then answer in two sentences: the root cause, and the exact line
you changed.

What happened: both fixed it, and both left the test file untouched (I compared checksums). The vague prompt worked because the failing test was already in the repository, and the agent found and ran it. That is the first lesson: the test did the real work, not the wording. The differences were smaller than I expected:

	Vague prompt	Specific prompt
Result	All 3 tests pass	All 3 tests pass
Change	Replaced the return line and added a comment	Replaced the return line only
Answer	A long explanation with assumptions and an offer to look at tax, shipping and negative quantities	Two sentences: root cause and the exact line

Both used the same fix:

return intdiv($sum * (100 - $discountPercent) + 50, 100);

The specific prompt gave me a shorter, easier-to-review answer and a smaller diff. It did not give a more correct fix. Which brings us to the next prompt, because this fix has a problem the original test never covered.

Prompt 2: edge-case tests that report instead of fix

Write edge-case tests for Cart::total() in tests/edge.php, reusing the check() style
from tests/run.php. Cover: quantity 0, a 100% discount, a discount over 100, a
negative price, several items in one cart, and a large quantity. Run 'php tests/edge.php'.
Do NOT modify anything in src/. For each failing test, say whether the bug is in
Cart or in my expectation, and what behaviour you think Cart should have.

I ran this against the code after the fix above. Five tests passed, three failed, src/ was untouched (checksum compared), and I re-ran the file myself to confirm the output:

PASS  qty 0 gives 0
PASS  qty 0 with discount gives 0
PASS  100% discount is free
FAIL  discount 150 is rejected (expected 'InvalidArgumentException', got -499)
FAIL  negative price is rejected (expected 'InvalidArgumentException', got -499)
PASS  several items, 10% off
PASS  large quantity
FAIL  overflowing quantity is rejected (expected 'OverflowException', got 'TypeError')

The useful part was the triage. For a discount of 150 the agent explained that 1000 * (100 - 150) + 50 is -49950 and intdiv truncates toward zero, so the customer gets a negative total, and it argued for throwing on a discount outside 0-100. For the negative price it pointed out that the + 50 rounding trick is only correct for non-negative sums: a single item of -500 with no discount returns -499. That is a genuine bug that the fix itself introduced, and it was invisible to the original test. For the overflow test it correctly said the failure was mostly its own expectation: the code fails loudly with a TypeError and never returns a wrong number, and the exception class I asked for was an arbitrary choice.

This is the main reason to ask for tests and a verdict instead of a patch: the patch that passes your test may still be wrong, and you only learn that if something probes it.

Prompt 3: structured code review

I used a small Laravel controller with real problems: a SQL string built from request input, Order::find($id)->delete() with no existence or authorization check, an N+1 loop over relations, and an unbounded get().

Vague: review src/OrderController.php

Structured:

Review src/OrderController.php (a Laravel 13 controller) for security and performance
problems only; ignore style. For each finding give: severity (high/medium/low), the
line number, why it is a problem in one sentence, and a minimal fix as a code snippet.
Order by severity. Do not report anything you cannot point to a specific line for.
Do not edit any files.

Both reviews found the SQL injection, the missing authorization on delete, the crash on a missing ID, and the N+1 queries. I checked the line numbers in the structured answer (13, 19-20, 31 and 36) against the file and they were right. So this prompt did not find more bugs. What it changed:

The vague review returned seven findings, including a "minor" group, and a long fix-priority list. The structured one returned five findings in a fixed format with line numbers, which is easier to turn into tickets.
It stated what it could not judge: "I can't see the routes file or policies. If a middleware or policy already ..." That sentence is worth more than the extra findings, because it tells you what to verify yourself.
It left out two possible issues it could not tie to a specific line, which is exactly what the "do not report anything you cannot point to" instruction asked for.

The fixes it proposed for authorization are sketches (they assume an OrderPolicy exists). Treat review output as a list of places to look, not as a patch to apply.

More prompt templates (not run for this article)

These follow the same five habits. I have not tested them here, so adapt them and check the results.

# Plan before code
Plan how to add [feature]. List the files you would change, the new tests you would
write, and the risks. Do not write any code yet.

# Refactor with a safety net
Refactor [class] to [goal]. Behaviour must not change. Run [test command] before and
after, and show both results. Stop and tell me if any test fails.

# Explain unfamiliar code
Explain what [function] does in five bullets. Flag side effects (database writes,
network calls, global state) and anything that looks like a bug. Do not change code.

# SQL review
Here is a query and its EXPLAIN output: [paste]. Tell me what is slow and why, and
suggest an index. Say which assumptions you are making about the table size.

# Commit message
Write a commit message for the staged changes ('git diff --staged'). Subject under
72 characters, imperative mood, then a short body explaining why, not what.

Common mistakes

Treating a passing test as proof. The fix in Prompt 1 passed and still broke on negative amounts. Add edge cases and read the assertions.
No way for the agent to check itself. Without a test command, the answer is a guess presented confidently.
Prompts that invite scope creep. "Improve this class" produces a rewrite. Name one concern.
Not saying what to leave alone. Forbid edits to tests, migrations or config explicitly when that matters.
Accepting fix sketches as final. Generated authorization and validation code assumes things about your app that it cannot see.
Never measuring. If you do not track review time and defects, you cannot tell whether a habit helps. The METR results show that feelings about speed can be wrong.

Alternatives to writing better prompts every time

Put standing rules in a project file (CLAUDE.md or AGENTS.md): the test command, the formatter, directories not to touch. Then you do not repeat them in every prompt.
Use a tool that gives the agent project context. For Laravel, Laravel Boost does this; see How to use AI agents to build Laravel applications.
Automate the checks. A formatter, static analysis and a test suite that run on every change catch more than any prompt wording.

Frequently asked questions

Do these prompts work with Cursor and Copilot?

The wording is tool-agnostic, and the five habits apply to any assistant. I only ran them in Claude Code, so I cannot show results for the others.

How long should a prompt be?

Long enough to state the failing check, the constraints and the output format. The specific bug-fix prompt above is five sentences. Length beyond that rarely helped in my runs.

Is a vague prompt ever fine?

Yes. When the repository already contains a failing test, a short prompt worked. Vague prompts get risky when there is nothing for the agent to check against.

Should I ask the AI to explain its reasoning?

Ask for evidence you can verify (the line it changed, the command it ran, the output), not for a story. A confident explanation can be wrong; a test result can be rerun.

Will good prompts make me faster?

I can't promise that. The best-known controlled study found a slowdown in 2025 and an inconclusive result in 2026. Measure your own review time and defect rate over a few weeks.

Originally published on DEV Talk.

Claude Code vs Cursor vs Copilot: Which Is Best in 2026?

devTalk — Mon, 09 Nov 2026 02:46:19 +0000

Last updated: 5 November 2026. Pricing and plans for all three tools changed several times this year, so see theupdate logat the end.

Asking which of these three is "best" runs into a problem before you compare a single feature: they are not the same kind of product. Claude Code is an agent that works in your terminal. Cursor is a code editor built around AI. GitHub Copilot is an assistant that plugs into the editors you already use and into GitHub itself. Picking the wrong one usually means picking the wrong shape of tool for how you work. This article compares them on that basis, shows the commands for the two that have a CLI, and gives you a way to test all three on your own code in an afternoon, because nobody else's benchmark runs on your repository.

The short answer

	Claude Code	Cursor	GitHub Copilot
What it is	Terminal-first coding agent	AI-native code editor	Assistant for many editors, plus GitHub integration and a CLI
Where you use it	Terminal (IDE integrations exist)	The Cursor editor	VS Code, other IDEs, GitHub, terminal
Pricing model	Included in Claude Pro and Max plans, or pay-as-you-go API	Subscription with a monthly dollar usage pool	Subscription with monthly AI credits since June 2026
Best fit	Multi-file tasks, scripts, CI, people who live in the terminal	People who want the AI built into the editor itself	Teams already on GitHub and mixed editors; cheapest entry point
Watch out for	Usage limits on subscription plans	Usage pool running out on heavy agent use	Credits drawn down by agent and premium-model use

If you want one sentence: pick the one that matches where you already work, then test it on real tasks. Many developers use more than one, as the next section shows.

What developers actually use

In the Stack Overflow Developer Survey 2026, among respondents who use AI coding assistants or agents (about 12,000 answers), the most used agents were:

Tool	Share of those respondents
Claude Code	65.5%
GitHub Copilot	58.7%
OpenAI Codex	29.5%
Cursor	25.5%

Two cautions. Survey respondents choose to take the survey, so this is not a random sample of developers. And the shares add up to far more than 100%, which means many people use two or more tools. It is evidence of popularity, not of quality.

Pricing as of November 2026

I could not open the vendors' own pricing pages from my environment, so the figures below are cross-checked from several independent roundups that agreed with each other, dated between July and November 2026. Treat them as a guide and confirm on the official pages before you pay.

Tool	Plan	Monthly price	Notes
Claude Code	Pro	$20 ($17 billed annually)	Claude Code is included; the Free plan does not include it
Max 5x	$100	About 5 times Pro usage
Max 20x	$200	About 20 times Pro usage
API	Pay per token	No monthly minimum; usage-based
Cursor	Hobby	Free	Limited agent requests and tab completions
Pro	$20	Monthly usage pool in dollars
Pro+	$60	Larger pool, same features as Pro
Ultra	$200	Largest individual pool
Teams	$40 per user	Adds SSO, analytics, central billing
GitHub Copilot	Free	$0	Limited monthly allowance
Pro	$10	Includes monthly AI credits
Pro+	$39	More credits, access to all models
Max	$100	Highest individual credit allowance
Business	$19 per seat	Org policy, audit logs, SSO
Enterprise	$39 per seat	Adds knowledge bases on private code

The prices matter less than how each tool counts usage, because that is what surprises people later:

Claude plans limit usage in rolling five-hour windows plus a weekly limit, shared between Claude's apps and Claude Code. Anthropic publishes multipliers, not token counts.
Cursor uses dollar-denominated monthly pools. When the pool runs out, on-demand usage is billed after the fact.
Copilot moved to usage-based billing on 1 June 2026: each plan includes AI credits, and agent and premium-model use draws them down. Roundups report that plain code completions do not use credits. One roundup also noted that sign-ups for some individual plans were temporarily paused in mid-2026, so check that your plan is available.

Claude Code: working examples

Claude Code is the one to look at if you want scripting. The -p flag runs a single prompt non-interactively, so it works in pipes and CI. I ran these with Claude Code 2.1.318:

# Pipe a failing test into it
printf 'FAILED Tests\\Feature\\InvoiceTest::test_export - Expected 200 but received 419\n' \
  | claude -p "In one short sentence, what does this test output suggest?"

A 419 in Laravel means the CSRF token was missing or expired, so the test's export
request (likely a POST) is being rejected before it reaches the controller. ...

# Machine-readable output
claude -p "say ok" --output-format json     # the answer is in the "result" field

# Continue the most recent conversation in this directory
claude -c

# Cap spending on a scripted run
claude -p "Review the staged changes" --max-budget-usd 1

The output formats are text, json and stream-json. I did not run the --max-budget-usd example; it comes from the CLI's help text. For the interactive commands, see 10 Claude Code commands every developer should know.

GitHub Copilot CLI: working examples

Copilot also has a terminal agent, installed from npm. I installed version 1.0.105 and read its options:

npm install -g @github/copilot
copilot --version

GitHub Copilot CLI 1.0.105.

copilot -p "Explain what this repository does"     # one prompt, then exit
copilot --continue                                  # continue the last session
copilot -p "..." --deny-tool ...                    # restrict which tools it may use

The help lists -p/--prompt, --model, --continue, --allow-tool, --deny-tool and --output-format, plus --allow-all (also --yolo), which switches off permission prompts. I could not log in from my environment, so I did not run an actual prompt. Prefer the narrower --allow-tool and --deny-tool options over --allow-all.

Cursor

Cursor is an editor, so most of what it does happens in its interface (tab completion, an agent panel, inline edits) and does not translate into terminal commands. I did not install or run it, so I cannot show output for it, and I am not going to describe its features from marketing copy. The facts I can support are its plans and its usage pools, in the pricing section above. If you try it, the free Hobby plan includes a one-week Pro trial according to the roundups, which is enough for the test below.

Test all three on your own code

I did not run a head-to-head benchmark, and I would distrust any article that claims one without publishing the tasks. Run your own in an afternoon:

Pick three real tasks from your backlog: a small bug fix, a feature that touches several files, and a refactor with tests.
Use the same prompt for each tool, starting from the same git branch.
Record: did the tests pass, how large was the diff, how long did you spend reviewing and fixing, and what did it cost in usage.
Compare on review time, not on how impressive the demo looked. The slow part of AI-assisted work is reading the result.

git switch -c try-claude main
# ... run the task, then record the numbers
git diff --stat main
php artisan test        # or your own test command

Which one should you choose?

You work mostly in the terminal, or want to automate tasks in scripts and CI: Claude Code or Copilot CLI. Claude Code is the one I tested end to end.
You want AI inside the editor on every keystroke: Cursor is built for that, and Copilot is the alternative if you want to keep VS Code or a JetBrains IDE.
Your company is on GitHub and needs policy controls, audit logs and one invoice: Copilot Business or Enterprise fits that setup, because it lives where your repositories already are.
Budget is tight: Copilot Pro at $10 is the lowest-priced paid individual plan in the table, and all three have free tiers to test with. Compare usage limits, not only prices.
You use Laravel: any of them can work. Laravel Boost, the official package that gives coding agents project context, supports a dozen agents, including all three. See How to use AI agents to build Laravel applications.

Common mistakes

Choosing by demo. Short demos hide the review cost. Judge by the three-task test above.
Ignoring how usage is counted. A cheap plan with a small pool feels fine for a week and then runs out mid-task. Check the usage model, not only the price.
Switching off permission prompts. Options like --dangerously-skip-permissions in Claude Code or --allow-all in Copilot CLI remove the checks that stop a bad command. Use them only in disposable sandboxes.
Pasting secrets. Keep .env contents out of prompts with every tool.
Not reading the generated tests. A tool that writes the code and the test can make the same mistake in both.
Assuming you must pick one. Mixing is normal, for example Copilot completions in the editor and a terminal agent for larger tasks.

Alternatives

The survey data above also lists OpenAI Codex (29.5%), Google Antigravity (16.0%) and Gemini Code Assist (14.6%). JetBrains users can look at Junie. I have not tested any of these for this article.

Frequently asked questions

Which is the cheapest?

By list price, Copilot Pro at $10 per month. But all three meter agent usage, so the real cost depends on how much you use the agent features. Test with the free tiers first.

Is Claude Code free?

No. It needs a paid Claude plan (Pro or higher) or API credits. The Free Claude plan does not include it.

Can I use more than one?

Yes, and many developers do. They can coexist in the same project, since they work on the same files and git history. Review changes from each before committing.

Which one is best for beginners?

An in-editor tool (Copilot or Cursor) is usually the gentler start, because suggestions appear where you are already typing. A terminal agent asks you to be comfortable with the command line and git.

Will my code be used for training?

Policies differ by vendor and plan, and they change. I did not verify them for this article. Read each vendor's current data-use terms, especially on free and individual plans, before using private code.

Originally published on DEV Talk.

AI Agents for Laravel: Boost Setup and a Safe Workflow

devTalk — Sun, 08 Nov 2026 03:56:46 +0000

An AI coding agent can write a controller, a migration and a test in a minute. It can also invent a method that does not exist in your Laravel version, ignore how your project is structured, and tell you everything works without running anything. Getting good results is less about the agent and more about what you give it: accurate context, a way to check its own work, and limits on what it may touch. This guide covers that setup for Laravel, using Laravel Boost, the official package for this job, and a workflow that keeps you in control.

What goes wrong without setup

A general-purpose agent knows Laravel from its training data, which mixes versions. Typical results are code written for an older release, queries that ignore your actual schema, and a new style next to your existing one. It also cannot see runtime problems: the exception in your log, the table columns in your database, or what your last request returned. An agent that can read those things fixes its own mistakes. One that cannot guesses.

Step 1: Install Laravel Boost (development only)

Laravel Boost gives agents Laravel-specific guidelines, skills and an MCP server connected to your running app. Install it as a development dependency, then run its installer:

composer require laravel/boost --dev
php artisan boost:install

The installer asks which agents you use and which parts to set up. You can also run parts separately: --guidelines, --skills and --mcp. In the current source (v2.10.4, released 29 October 2026), Boost knows these agents: Claude Code, Codex, Copilot, Cursor, Junie, Kiro, OpenCode, Zed, Amp, Antigravity, Grok Build and Pi. For several of them the guidelines go into AGENTS.md in your project root. Claude Code uses CLAUDE.md if that file already exists and AGENTS.md otherwise, its skills go into .claude/skills, and its MCP configuration into .mcp.json. Boost requires PHP 8.2 or newer and supports Laravel 11, 12 and 13.

Commit the generated guidelines so the whole team shares them. Keep them current when you upgrade Laravel or add packages:

php artisan boost:update
php artisan boost:list-skills

What the agent can do through Boost

The MCP server exposes tools the agent can call while it works. From the tool definitions in the source:

Tool	What it gives the agent
Search docs	Version-specific Laravel documentation for the packages installed in your project
Database schema and connections	Your real tables and columns instead of guessed ones
Database query	Read-only SQL (SELECT, SHOW, EXPLAIN, DESCRIBE); write statements are rejected, and the query runs inside a read-only transaction
Tinker	Runs PHP in the application context, like `artisan tinker`
Last error and log entries	The latest exception and application log lines
Browser logs	Frontend console errors
Absolute URL	Correct URLs for routes, so the agent can check pages
Record rule	Saves a project rule into `.ai/rules`, only when you explicitly ask for one to be remembered

This list reflects the source at the time of writing. For example, an older application-info tool was removed in v2.10.4, so tool names in older tutorials may not match what you get.

Step 2: Use a workflow, not one big prompt

The pattern that gives consistent results is small steps with a check after each one.

Ask for a plan first. "Plan how to add invoice PDF export: which files change, which routes, which tests. Do not write code yet." Fix the plan before any code exists.
Write the test first. "Write a feature test for the export endpoint that fails right now." A failing test is a precise definition of "done".
Implement in small pieces. One migration, one model, one controller action at a time, not the whole feature.
Make the agent run the checks. Tell it to run the tests and the formatter, and to read the output:php artisan test --filter=InvoiceExportTest ./vendor/bin/pint --dirty
Review the diff yourself. Read every line before you commit. You own the code that ships.

A prompt in this style, for a change in an existing project:

Add soft deletes to the Project model.
- Check the real projects table schema first.
- Create the migration and update the model.
- Update the existing ProjectTest so it covers restoring a project.
- Run php artisan test and fix failures. Do not change unrelated files.
- Show me the migration SQL with php artisan migrate --pretend before running it.

migrate --pretend prints the SQL a migration would run without running it, which is a cheap safety check on anything the agent generates.

Step 3: Set guardrails

Keep Boost out of production. It is a dev dependency, and in the source its server only starts when the app environment is local or when APP_DEBUG is true. Production should have neither. A server with APP_DEBUG=true would qualify, which is one more reason never to run production that way.
Point agents at a local database with fake data. The query tool is read-only, but Tinker can run any PHP, including writes. Never give an agent production credentials.
Review security-sensitive code by hand. Authorization (policies and gates), validation rules, mass-assignment settings and file uploads are where plausible-looking code is often wrong. A missing authorization check does not fail any test unless someone wrote one.
Review migrations before you run them. Dropping a column or changing a type on a large table is not something to approve by skimming.
Look for performance mistakes. Agents readily write queries inside loops. Check for N+1 patterns in anything that lists records.
Keep secrets out of the conversation. Do not paste .env contents into prompts.
Use version control as your undo button. Work on a branch and commit after each working step.

Common mistakes

Accepting "done" without evidence. If the agent did not run the tests, ask it to. Only a passing run counts.
Prompting for a whole feature at once. Large changes bury mistakes in a big diff that nobody reviews well.
Stale guidelines. After upgrading Laravel or adding packages, rerun boost:update, or the agent keeps following old conventions.
Letting the agent restyle your code. Tell it to follow existing patterns, and keep formatter changes to files it touched.
Treating generated tests as proof. An agent that writes both the code and the test can encode the same misunderstanding in both. Read the assertions.

Agents inside your app are a different thing

Everything above is about agents that help you write the application. If you want an agent as a feature of your product (a support assistant, a tool-calling workflow), that is the Laravel AI SDK, covered in the Laravel AI SDK article. The two combine well, since a coding agent can help you build SDK-based features.

Frequently asked questions

Which coding agent works best with Laravel?

Boost supports a dozen of them, and I have no evidence that one is clearly better. Choose by workflow (terminal, editor or IDE) and test two on a small real task from your own project.

Do I need Boost to use an AI agent with Laravel?

No. Any agent can edit Laravel files. Boost adds the project context and the runtime tools that reduce guessing.

Is it safe to let an agent run commands?

Run it in a development environment, with a throwaway database, on a branch, and review what it ran. Keep production access out of reach.

Will it write my whole application?

It can produce a lot, but you still need to know what good looks like. People who understand Laravel get far better results because they can plan the work and review the output.

Originally published on DEV Talk.

Docker vs Kubernetes: What’s the Difference? Simple Guide

devTalk — Sat, 07 Nov 2026 15:01:34 +0000

People ask this as if they were rivals, and they are not. Docker packages your application so it runs the same everywhere. Kubernetes runs and looks after many of those packages across many servers. One builds the box, the other manages the warehouse full of boxes. Most teams that use Kubernetes also use Docker-built images, so the real question is not "which one?" but "do I need the bigger tool yet?"

The short answer

	Docker	Kubernetes
What it does	Builds images and runs containers	Runs containers across a group of machines and keeps them healthy
Works on	One machine	A cluster of machines
You use it to	Package an app and run it	Deploy, scale, update and restart many apps
Setup effort	Install it and write a Dockerfile	Much higher: cluster, networking, storage, config
Typical user	Every developer	Teams running many services in production

What Docker does

A container is your application plus everything it needs to run (runtime, libraries, config), isolated from the rest of the machine. You describe it in a Dockerfile, build an image from it, and run containers from that image. I built and ran the smallest possible example with Docker 29.8.2:

# Dockerfile
FROM scratch
COPY hello /hello
CMD ["/hello"]

docker build -t hello:1 .
docker run --rm hello:1

hello from a container

Here hello was a tiny statically linked program, which is why the base image is empty (scratch). In real projects you start from an image such as a PHP, Node or Python base image instead. The image came to 354 kB of content, and I could start two containers from the same image side by side. That is the main idea: one image, as many identical containers as you like, on the same machine.

Docker answers: "How do I package this app so it behaves the same on my laptop, in CI and on the server?"

What Kubernetes does

Kubernetes (often written K8s) is an open source system for running containers at scale. Once you have more than a handful of containers on more than one server, new questions appear: what restarts a container when it crashes? What spreads traffic between five copies? How do you release a new version without downtime? Kubernetes handles these. You tell it the state you want, and it works to keep reality matching. A minimal description looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/my-app:1.0
          ports:
            - containerPort: 80

That says: "I want three copies of this container running." If one dies or a server fails, Kubernetes starts a replacement. To roll out version 1.1, you change the image tag, and Kubernetes replaces the copies gradually. Kubernetes answers: "How do I keep many containers running, scaled and updated across many machines?"

Do Kubernetes and Docker work together?

Yes. Images you build with Docker run on Kubernetes. The Kubernetes project says so directly: "Docker-produced images will continue to work in your cluster with all runtimes, as they always have."

The confusion comes from a change in Kubernetes 1.24, which removed "dockershim", the small piece of code that let Kubernetes talk to the Docker Engine directly. Kubernetes now talks to container runtimes through its own standard interface (CRI), using runtimes such as containerd or CRI-O. For you as a developer nothing changes: you still build with Docker, push the image to a registry, and Kubernetes pulls and runs it. What changed is only which program on the server starts the container.

The middle step: Docker Compose

Between "one container" and "a Kubernetes cluster" sits Docker Compose. It describes several containers on one machine in a single file, for example an app and its database:

services:
  app:
    build: .
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: mysql:8.4
    environment:
      MYSQL_ROOT_PASSWORD: change-me

docker compose up -d

For many small and medium projects, a single server with Docker Compose is enough, and far simpler to run than a cluster. (I confirmed that Docker Compose v5.5.1 is available with the Docker install I tested. I did not start this particular stack, because the sandbox could not download images.)

When to use which

Use Docker alone (or with Compose) for local development, CI builds, and production on one or a few servers with modest traffic. You get reproducible environments with little to learn.
Move to Kubernetes when you run many services, need several copies for availability, need zero-downtime updates, or must scale up and down automatically. The cost is real: you need to learn its concepts, and someone has to operate the cluster or you pay for a managed service from a cloud provider.
Do not adopt Kubernetes to look modern. If a single server handles your load, a cluster adds work without adding value. Teams often start on Compose and move when a specific problem, such as needing automatic failover, justifies it.

Frequently asked questions

Is Kubernetes a replacement for Docker?

No. They do different jobs. Docker builds and runs containers on one machine. Kubernetes coordinates containers across many machines. Kubernetes needs container images, and Docker is a common way to create them.

Do I need to learn Docker before Kubernetes?

Yes, in practice. Kubernetes manages containers, so you should understand images, containers, ports and volumes first. Learning them with Docker takes days. Kubernetes takes much longer.

Is Docker free?

The Docker Engine used in my test is free to install on Linux. Docker Desktop and some Docker services have their own license terms for larger companies, so check Docker's current terms for your situation.

What version of Kubernetes is current?

Kubernetes 1.36 was the current supported release when I checked on 5 November 2026. Its latest patch was 1.36.5 (released 15 September 2026), with end of life on 28 June 2027. Versions change every few months, so check the release page.

Can I run Kubernetes on my laptop?

Yes, with tools designed for learning and testing, such as kind or minikube. I did not test them here.

Sources

Originally published on DEV Talk.

What Developers Use and Search in 2026: Survey Data

devTalk — Sat, 07 Nov 2026 11:11:11 +0000

If you ask "what are developers searching for these days", the honest answer is not a list of keywords. Search volume data from Google is not public in a form anyone can quote reliably, and most "top search" lists online are guesses. What can be checked is what developers say they use, how they look for answers, and what they actually push to GitHub. Two large reports landed in the last five weeks: the Stack Overflow Developer Survey 2026 (published 6 October) and GitHub's Octoverse 2026 (published 28 October). This article pulls out the numbers that matter for working developers and says what each one does and does not tell you.

Where developers look for answers has changed

This is the headline for anyone who writes or reads technical content. From the Stack Overflow 2026 survey, which had more than 30,000 respondents:

83% search online for answers, and 70% ask an AI agent. Many do both.
64% visit Stack Overflow less often for simple questions.
16% visit Stack Overflow more often, to check where an AI answer came from.
93% say source attribution is needed for them to trust AI output.

What do developers do after an AI answer arrives? The survey asked (about 13,000 answers, multiple choices allowed):

Next step after an AI response	Share
Run it locally	76.5%
Compare against the codebase	63.9%
Inspect tests and security implications	53.0%
Read official documentation	38.0%
Search Stack Overflow	12.2%
Ask a coworker	6.9%
Use as-is	9.6%

Only about one in ten uses the answer without checking it. Verification, not generation, is where the search effort has moved. The trust question points the same way: 48.0% said they trust AI output when they can easily verify it, 12.3% do not trust it for most work tasks, and 6.6% trust it for many tasks including important decisions.

The languages and databases in daily use

The survey's technology page gives these shares of respondents:

Language	Share	Database	Share
JavaScript	62.0%	PostgreSQL	57.9%
SQL	58.4%	SQLite	42.1%
HTML/CSS	58.2%	MySQL	35.1%
Python	58.0%	Redis	28.3%
Bash/Shell	51.3%	Microsoft SQL Server	27.1%
TypeScript	43.8%	MariaDB	20.3%
Java	27.6%	MongoDB	19.0%
C#	27.1%	Elasticsearch	14.8%

Three things stand out. SQL moved ahead of HTML/CSS, but by 0.2 percentage points, which is within the noise of a survey. PostgreSQL is used by well over half of respondents, far above MySQL. And Redis and MariaDB each sit in the top seven databases, so the "classic" stack of PHP or Python with MySQL, MariaDB and Redis is a long way from disappearing. Rust moved up to 12th place among languages, though the survey summary gives no percentage for it.

What GitHub's own data adds

Surveys record what people say. GitHub records what they push. Octoverse 2026 covers the year from 1 October 2025 to 30 September 2026:

Volume: 17.9 billion pushes, 34.3 billion commits (public and private) and 1.3 billion merged pull requests. GitHub reports more than 225 million developers.
Languages: TypeScript is first, Python second and JavaScript third, the same order as 2025, when TypeScript passed Python for the first time. Net monthly contributor gains over the year were 3.62 million for TypeScript, 3.23 million for Python and 1.82 million for JavaScript. Rust "doubled" over the past year, per GitHub.
Agents: more than 40% of pull requests started with an agent's first draft in September 2026, up from 17% in March 2026. That is 110 million agent-started pull requests in a single month.
Fastest-growing projects: the lists are dominated by AI tooling, with anthropics/claude-code, ggml-org/llama.cpp, vllm-project/vllm and openai/codex among those named.

Note that the Octoverse language ranking counts contributors, which is a different measure from the survey's "used in the past year". That is why JavaScript leads the survey while TypeScript leads GitHub. GitHub also reports that, among repositories created in 2026, those with an agent configuration file logged eight times as many commits as those without. That is a correlation: projects that adopt agent tooling may simply be the more active ones.

AI tools in practice

Among the survey respondents who use AI coding assistants or agents (12,255 answered), the most used agents were:

Tool	Share
Claude Code	65.5%
GitHub Copilot	58.7%
OpenAI Codex	29.5%
Cursor	25.5%
Google Antigravity	16.0%
Gemini Code Assist	14.6%

Of those who use AI tools, 73% use them daily, and 31% of the daily users spend four or more hours a day with them. The main uses are generating code in familiar areas (67%) and debugging (61%). Only 20% use AI for deploying, operating or troubleshooting production systems. Treat the tool ranking with care: the respondents chose to take a Stack Overflow survey and are not a random sample of developers, and the figures are shares of people who answered that question.

What this means if you build or write for developers

The following points are my reading of the numbers above, not extra data:

Short factual questions are going to AI chat, and the checking is going to documentation. Pages that survive are those with something a chat answer cannot easily give: tested commands, real output, version-specific behaviour, and sources that can be cited. With 93% asking for attribution, citing the official docs is no longer optional.
Verification skills are in demand. Three out of four developers run AI-generated code locally before trusting it. Tutorials on testing, reading stack traces, reviewing diffs and security checks fit that behaviour.
SQL and PostgreSQL knowledge keeps its value. Both are at or near the top of the survey, and AI tools produce queries that still need a person who can read an execution plan.
TypeScript is the default for new work on GitHub, with Python close behind. GitHub's own 2025 report argued that type checking helps catch errors in AI-generated code. That is their explanation, not a settled fact.
Old stacks still matter. MySQL, MariaDB, Redis and Bash are all in the survey's top ten for their category. (The survey figures I read do not break out PHP, so I make no claim about it.) Maintenance, upgrade and troubleshooting topics for them have a steady audience, but I have no search volume data to put numbers on that.

What these numbers do not tell you

They are not search volumes. A technology that few people "use" can still draw many searches because it is hard to configure.
Survey samples are self-selected, and the survey pages do not always say which population a chart covers. Where they do not, I say so above.
Octoverse counts activity on GitHub, including private repositories, so it leans toward teams that host code there.
For actual search demand on a topic, use Google Search Console for your own site and a keyword tool you trust. I did not use one here.

Frequently asked questions

What is the most popular programming language in 2026?

It depends on the measure. JavaScript leads the Stack Overflow survey at 62.0% of respondents, and TypeScript leads GitHub by monthly contributors, ahead of Python and JavaScript.

Is Stack Overflow still relevant?

The survey says 64% visit it less often for simple questions, while 16% visit more to check AI-provided sources. It is used less for quick answers and more as a reference to verify them.

What database do developers use most?

PostgreSQL, at 57.9% of respondents in the survey, followed by SQLite (42.1%) and MySQL (35.1%).

Are AI agents replacing developers?

The data shows something narrower: agents now open a large share of pull requests (over 40% in September 2026), and developers are still the ones reviewing, merging and verifying. Nothing in these reports measures replacement.

Originally published on DEV Talk.

10 Claude Code Commands Every Developer Should Know

devTalk — Thu, 05 Nov 2026 17:08:32 +0000

Most people start Claude Code, type a request and hope for the best. That works until the conversation gets long, the answers get worse, and a change you did not want lands in your working tree. A small set of slash commands fixes most of that: they control what Claude remembers, how much context it carries, whether it may act, and how you get back when something goes wrong. These ten are the ones worth learning first, followed by a few command-line options for scripts and CI.

Everything here was checked against Claude Code 2.1.318. Commands change between versions, so type /help in your own install to see what yours has.

The ten at a glance

#	Command	Use it to
1	`/init`	Create a `CLAUDE.md` for your project
2	`/memory`	Edit `CLAUDE.md` files and memory settings
3	`/clear`	Start fresh when the topic changes
4	`/compact`	Summarize a long session and keep going
5	`/context`	See what is using the context window
6	`/plan`	Plan before any code changes
7	`/rewind`	Go back to an earlier point
8	`/resume`	Continue an earlier conversation
9	`/permissions`	Control what Claude may run without asking
10	`/usage`	Check cost and usage (aliases: `/cost`, `/stats`)

1. /init: give Claude project knowledge

Claude starts every session without knowing your project. /init analyzes the codebase and creates a CLAUDE.md file with documentation about it, which Claude reads at the start of future sessions. Run it once in the project root, then edit the result. A generated file is a draft: delete anything wrong or vague, and add the facts only you know. For a Laravel project, the useful lines are the ones that save a wrong guess:

# Project notes
- Run tests: php artisan test
- Format code: ./vendor/bin/pint --dirty
- Do not edit migrations that are already merged; add a new one.
- Authorization lives in app/Policies; every controller action must use it.

2. /memory: edit what Claude remembers

The command opens your CLAUDE.md files and memory settings for editing. Use it when you catch yourself correcting the same thing twice. Put the rule in the file once instead of repeating it in every session. Keep the file short, because everything in it is loaded into context each time.

3. /clear: start clean

It starts a new session with empty context. The previous session stays on disk and can be reopened with /resume, so nothing is lost. Use it between unrelated tasks. A long conversation about a billing bug is noise when you move on to a CSS problem, and stale context makes answers worse and costs more.

4. /compact: shrink a long session instead of abandoning it

/compact summarizes the conversation so far to free up context. It accepts optional instructions for what the summary should keep:

/compact keep the failing test names, the files we changed, and the decision to use a queue

Use it when you are mid-task and want to continue. Use /clear when you are done with the task.

5. /context: see where the context goes

It shows current context usage by category. I ran it in a fresh session and got a table like this:

**Tokens:** 31.7k / 500k (6%)

| Category      | Tokens | Percentage |
| System prompt | 3.7k   | 0.7%       |
| System tools  | 21.2k  | 4.2%       |
| Skills        | 6.8k   | 1.4%       |

Your numbers will differ with your model, tools and settings. The point is that even an empty session uses some of the window, and MCP servers, skills and big CLAUDE.md files add to it. When responses start degrading in a long session, check this before blaming the model.

6. /plan: think before changing files

/plan enables plan mode, or shows the current session plan if one exists. Use it for any change that touches more than a file or two: ask for the approach, read it, correct it, then let Claude implement. Catching a wrong approach in a plan costs a minute. Catching it in a 20-file diff costs an hour. Plan mode is also one of the permission modes you can start a session with, using claude --permission-mode plan.

7. /rewind: undo to an earlier point

The command restores the code and/or the conversation to a previous point. It also answers to /checkpoint and /undo. It is the fast way out when an approach goes wrong. Do not treat it as a replacement for git: commit before larger tasks, and check the Claude Code documentation for exactly what is tracked, since changes made outside Claude's own edits may not be.

8. /resume: pick up where you left off

/resume (alias /continue) reopens a previous conversation, and accepts a session ID or a search term. From the terminal, two flags do the same job:

claude -c          # continue the most recent conversation in this directory
claude -r          # open the picker; or: claude -r "invoice export"

I tested claude -c in a scratch directory: it resumed the previous session and could repeat my earlier message back. Name sessions with -n or --name when you start them, so they are easy to find later.

9. /permissions: decide what runs without asking

It manages allow and deny rules for tools. Allow the safe, repetitive commands (running tests, git status) so you are not clicking "approve" all day, and leave everything else on ask. Be conservative: an allow rule is a standing permission. The same rules can be given at startup. The CLI help shows the syntax:

claude --allowedTools "Bash(git *) Edit"

Avoid --dangerously-skip-permissions on a normal machine. The help text itself recommends it only for sandboxes with no internet access.

10. /usage: know what you are spending

It shows session cost, plan usage and activity statistics, under the aliases /cost and /stats too. Check it after long agentic runs, and before you decide to automate something at scale.

Bonus: use Claude Code in scripts

The -p (--print) flag runs one prompt, prints the answer and exits, which makes Claude usable in shell pipelines and CI. Pipe data in, and ask for structured output when another program reads the result:

php artisan test 2>&1 | claude -p "Summarize the failures in one sentence each"

claude -p "List the routes without auth middleware" --output-format json

I piped a failing test line (Expected 200 but received 419) into claude -p and got back an explanation that a 419 in Laravel means a CSRF token problem. The JSON output format returns one object. In my run, the answer was in the result field, and the object also included fields such as session_id, total_cost_usd and usage, plus many other diagnostic keys, so read only the fields you need. The other output formats are text (the default) and stream-json.

Two more options worth knowing: claude -w feature-x starts the session in a new git worktree, so experiments do not touch your main checkout, and claude doctor checks the health of your installation.

Common mistakes

Never clearing. One endless session accumulates stale context. Use /clear between tasks.
An unreviewed CLAUDE.md. A bloated or wrong file misleads every session. Edit it like code.
Skipping the plan. Large changes without a plan produce large diffs that are hard to review.
Trusting rewind instead of version control. Commit before big tasks.
Allow-listing broad commands. A narrow rule such as Bash(git *) is safer than allowing arbitrary shell access.

Frequently asked questions

How do I see all available commands?

Type /help in a session. It shows help and the available commands for your version.

What is the difference between /clear and /compact?

/clear starts a new session with empty context. /compact keeps the same session but replaces the history with a summary.

Do these commands work the same in an IDE?

I only tested the terminal version. Check your IDE integration's documentation for differences.

Can I run slash commands in print mode?

Some, yes. In my tests /context and /usage worked with claude -p. Others, such as /rewind, are interactive only.

Sources

Originally published on DEV Talk.

Laravel Herd Setup: Sites, PHP Versions, HTTPS and Databases

devTalk — Thu, 05 Nov 2026 15:29:05 +0000

Laravel Herd is a local development environment for macOS and Windows that runs PHP and nginx natively, with no Docker and no virtual machine. You put a project in a folder, and it is available at project-name.test a moment later. This guide covers what you get, how to set up a site, how to switch PHP versions per project, how to turn on HTTPS, and where databases fit, using the commands from Herd's own documentation.

What Herd is, and where it runs

Herd bundles PHP, nginx, a local DNS service (so .test domains resolve) and Node. It is available for macOS and Windows. Linux is not supported: the Herd website says the team is working on a Linux version but it is not ready to ship, so on Linux, Laravel Sail or a manual setup is still the route. Plans, as stated on the Herd site at the time of writing:

Plan	Price	Includes
Herd (free)	No cost, no license	PHP, nginx, DNS and Node; per-project site configuration; Herd Studio; the PHP Profiler; community support
Herd Pro	$99 per year	Everything in free, plus MySQL, PostgreSQL, Redis and more as managed services; Mail; Insights; Tinker; Xdebug detection; email support
Herd for Teams	$299 per year	10 Pro licenses, a license portal, shared project configuration, priority email support

Prices and plan contents change, so check the Herd website before you budget around them.

Create your first site

Herd parks one directory for you by default: ~/Herd on macOS and %USERPROFILE%\Herd on Windows. Every folder inside a parked directory is served as http://folder-name.test. So the fastest start is:

cd ~/Herd
laravel new my-app
cd my-app
herd open

laravel new creates the application and herd open opens http://my-app.test in your browser. The Herd documentation notes that new Laravel apps use SQLite by default, so this works before you install any database server.

A project that lives somewhere else

You do not have to move existing projects into the Herd directory. Link one from its own folder:

cd ~/code/client-portal
herd link client-portal      # served at http://client-portal.test
herd links                   # list linked sites
herd unlink client-portal

Or park a whole folder of projects so that every subfolder becomes a site:

herd park ~/code
herd parked                  # list sites inside parked paths
herd forget ~/code           # stop serving that folder

HTTPS for a local site

From the project directory, generate a trusted certificate for the site:

herd secure
herd secured      # lists secured sites and when their certificates expire
herd unsecure     # remove the certificate and the HTTPS redirect

Do this when your app needs HTTPS to behave properly, for example secure cookies, OAuth callbacks, or webhooks that refuse plain HTTP. Remember to set APP_URL in .env to the https:// address afterwards.

PHP versions

Herd ships with the latest stable PHP, which its documentation lists as PHP 8.5 at the time of writing. You set a global version, and you can pin individual sites to another one:

herd php:list              # versions and install status
herd php:install 8.3       # install another version
herd use 8.4               # global version for sites that are not isolated

cd ~/Herd/legacy-app
herd isolate 8.2           # pin this site to PHP 8.2
herd isolated              # list pinned sites
herd unisolate             # go back to the global version

If the folder name and the site name differ, add --site="site-name" to herd isolate. The same thing is available in the app: select the site in the Applications window and choose a version in the Environment section.

Use the right PHP in the terminal

The php that your shell finds is not necessarily the version Herd serves for that site. Herd provides wrappers that pick the version configured for the current directory:

herd php artisan migrate
herd composer install
herd which-php             # which PHP binary serves this path

Use these when you see "works in the browser, fails in the terminal" or a Composer platform error that mentions the wrong PHP version. Node works the same way: herd node:install 22 installs a version through Herd's nvm, and herd isolate-node pins one to the current directory.

Databases

This is the part that differs between plans. Herd's PHP includes the extensions for MySQL, MariaDB, PostgreSQL, MongoDB, Redis, Valkey and SQLite, so your code can talk to any of them, but the database servers themselves are another matter:

Free: SQLite works out of the box. For MySQL, PostgreSQL or Redis, install the server from its vendor or use a free tool such as DBngin, and point your .env at it.
Pro: Herd manages the services for you. You switch an application to a service in the Applications window, Herd updates .env and can create the database. The CLI mirrors this, for example herd services:list, herd services:create <type> and herd db:create.

The documentation pages I read do not list default ports or credentials, so read them from herd db:connection (Pro) or from your own database tool instead of guessing.

Other things worth knowing

Health check: herd status shows whether Herd and its services are running. herd restart restarts them.
Logs: herd log tails Herd's log files, which is where to look when a site returns an nginx error.
Proxies: herd proxy my-api http://127.0.0.1:3000 creates an nginx proxy host, useful for a Node server or a frontend dev server next to Laravel. (Check the exact target format against herd proxy in your version.)
Sharing: herd share exposes a site through an Expose tunnel, handy for webhook testing.
Debugging: herd debug runs PHP with the site's version and a debug configuration, and herd coverage runs it with Xdebug coverage.
Project manifest: herd init configures a project from a herd.yml file, so a team can share setup. See the docs for the format.

Common problems

.testsite does not load. Run herd status to see whether nginx, DNS and PHP are running, then herd restart. Check that the folder really sits in a parked path (herd paths) or is linked (herd links).
Wrong PHP version. Compare herd which-php with herd isolated, and run commands through herd php and herd composer.
Another local server uses ports 80 or 443. Herd and another web server cannot both listen there. Stop the other one (MAMP, an old Valet install, a Docker container publishing those ports). This is general networking behaviour, not a documented Herd message.
Database connection refused. On the free plan nothing is running unless you installed a server yourself. Check DB_CONNECTION in .env: a new app uses SQLite.
Browser warns about the certificate. Run herd secure from the right directory, then restart the browser, since the certificate is issued per site.

Herd or Sail?

They solve different problems. Herd runs natively, starts fast and needs no container knowledge, but it exists for macOS and Windows only, and your machine's PHP stack is not your server's stack. Sail runs your app in Docker containers, works on Linux and can match production services more closely, at the cost of Docker's overhead and learning curve. Teams on mixed operating systems, or with strict production parity needs, often pick Sail. A solo developer on a Mac who wants a quick setup will usually be happier with Herd. Neither choice locks you in, because your application code does not change.

Sources

Originally published on DEV Talk.

Laravel CORS Error with React or Vue: Causes and Fixes

devTalk — Thu, 05 Nov 2026 15:28:41 +0000

You split the project in two: Laravel serves an API on localhost:8000, and a React or Vue app runs on localhost:5173. The first request from the browser fails, and the console shows a message along these lines (Chrome's wording):

Access to fetch at 'http://localhost:8000/api/users' from origin 'http://localhost:5173'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

The API itself is usually fine. CORS is a browser rule: the browser asks the server whether a page from another origin may read its response, and the server answers with headers. Laravel already has the machinery for that answer. Most fixes are a few lines of config, and I checked each one against the real middleware.

Why you only see it in the browser

Two URLs have the same origin only if scheme, host and port all match. localhost:5173 and localhost:8000 differ in the port, so every request between them is cross-origin. The server never blocks anything. It sends Access-Control-* headers, and the browser decides whether your JavaScript may see the response. That is why curl and Postman work while the browser fails, and why the real fix always means changing what the server sends, not changing the frontend code.

Requests that use Authorization, JSON content types or methods like PUT and DELETE trigger a preflight first: the browser sends an OPTIONS request asking permission, and only sends the real request if the answer allows it. A CORS problem is very often a failed preflight.

How Laravel handles CORS

Laravel's HandleCors middleware is in the global middleware stack by default, and it uses the fruitcake/php-cors library. In Laravel 11 and newer, a fresh application does not have a config/cors.php file, but the framework supplies one. In the Laravel 13 source (13.38.0) the defaults are:

'paths' => ['api/*', 'sanctum/csrf-cookie'],
'allowed_methods' => ['*'],
'allowed_origins' => ['*'],
'allowed_origins_patterns' => [],
'allowed_headers' => ['*'],
'exposed_headers' => [],
'max_age' => 0,
'supports_credentials' => false,

To change anything, publish the file and edit it:

php artisan config:publish cors

Also note that a new Laravel 11+ skeleton has no routes/api.php until you run php artisan install:api. If your frontend calls /api/... and gets a 404, that is a routing problem, not CORS.

Test the preflight without a browser

Reproduce what the browser sends and read the headers that come back:

curl -i -X OPTIONS http://localhost:8000/api/users \
  -H 'Origin: http://localhost:5173' \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: content-type,authorization'

A healthy answer is a 204 with Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers. I ran this through the real HandleCors middleware and fruitcake/php-cors with the default config:

status 204
access-control-allow-origin: *
access-control-allow-methods: POST
access-control-allow-headers: content-type,authorization

With defaults, a plain API on /api/* using bearer tokens works from any origin. If yours does not, the cause is one of the cases below.

Cause 1: The path is not in `paths`

CORS headers are only added for URLs that match paths. A request to /login, /broadcasting/auth, /graphql or /storage/... gets none, because those do not start with api/. In my test, a preflight to /login with the default config came back with no CORS headers at all. Add what you serve to the frontend:

'paths' => ['api/*', 'sanctum/csrf-cookie', 'login', 'logout', 'broadcasting/auth'],

Patterns use the same matching as $request->is(), so * is a wildcard.

Cause 2: Cookies or sessions (Sanctum SPA) need credentials

If your React or Vue app logs in through cookies, the browser will not send or accept them across origins unless both sides opt in. On the server:

'allowed_origins' => ['http://localhost:5173'],   // an explicit list, not '*'
'supports_credentials' => true,

In my test, a preflight with that configuration returned:

access-control-allow-origin: http://localhost:5173
access-control-allow-credentials: true

On the frontend, the request must ask to include cookies. With axios that is withCredentials: true, with fetch it is credentials: 'include'. The Sanctum SPA setup needs more besides CORS: the stateful-domains setting, the session cookie domain, and a call to /sanctum/csrf-cookie before logging in. Check the Sanctum documentation for those, since I only tested the CORS part. In Laravel 13, $middleware->statefulApi() in bootstrap/app.php turns on Sanctum's frontend middleware.

Do not combine credentials with `'*'`

Browsers refuse a wildcard origin on a credentialed request. What surprised me is what Laravel does with that configuration. With allowed_origins => ['*'] and supports_credentials => true, a request from http://localhost:5173 got this back:

access-control-allow-origin: http://localhost:5173
vary: Origin
access-control-allow-credentials: true

The library reflected the caller's origin instead of sending *. That makes it work in the browser, and it also means any website can make credentialed requests to your API and read the answers. For production, list your real frontend origins (or use allowed_origins_patterns with a strict regex) and never leave * on when supports_credentials is true.

Cause 3: A request header is not allowed

The default allowed_headers is ['*']. If you set an explicit list and forget Authorization or a custom header, the preflight succeeds but the browser then blocks the real request. In my test, with ['Content-Type', 'X-Requested-With'] and a preflight asking for authorization:

access-control-allow-headers: content-type, x-requested-with

There is no authorization in the list, so the browser refuses to send it. Add the header to the list, or go back to ['*'].

Cause 4: The origin is not listed

If you set allowed_origins to one origin, the response carries that origin whatever the caller sends. With ['http://localhost:5173'], a request from http://evil.test still got access-control-allow-origin: http://localhost:5173, and the browser rejected it because it does not match the page. When the browser says the origin is not allowed, compare it character by character: http against https, a trailing slash, 127.0.0.1 against localhost, and the port are all different origins. For several environments, use a list or a pattern:

'allowed_origins' => [env('FRONTEND_URL', 'http://localhost:5173')],
'allowed_origins_patterns' => ['#^https://.*\.example\.com$#'],

Things that make it look like a CORS error

Stale config. After editing config/cors.php on a server that caches config, run php artisan config:clear (or config:cache again). The cached copy wins over the file.
The real error is something else. Open the browser's Network tab and look at the status code of the request. A 404, 419 or 401 from Laravel is not a CORS problem. In my test, a 500 response from the application still carried the CORS header, so you should see the real status. Errors produced by the web server or a proxy in front of Laravel (502, 504, 413) do not pass through the middleware and arrive without CORS headers, so the browser reports them as CORS failures.
Headers added twice. If Nginx or Apache also adds Access-Control-Allow-Origin, the browser can receive two values and reject the response. Set CORS in one place only. I did not test this.
Redirects. A request that Laravel redirects (for example an unauthenticated browser request sent to a login page) can fail the CORS check on the redirect. Send Accept: application/json from your API client so Laravel answers with JSON errors instead of redirects.
Dev proxy as an alternative. Vite can proxy /api to Laravel during development, which removes CORS from local development. That hides a misconfiguration you will meet in production, so keep the real settings correct as well.

Sources

Originally published on DEV Talk.

DEV Community: devTalk

Secure a Laravel App Before Production: Tested Checklist

What Laravel handles for you, and what it does not

1. Turn off debug mode and set the environment

2. Point the web server at public/, never the project root

3. Protect APP_KEY and plan for rotating it

4. Cache config in production, and stop calling env() outside config files

5. Force HTTPS and secure cookies

6. Trust proxies precisely, never blindly

7. Trust your own hostnames

8. Send security headers

9. Keep CSRF protection on

10. Harden login: hashing, throttling, sessions

11. Authorize every record access (the IDOR check)

12. Block mass assignment

13. Never interpolate into SQL, never print raw HTML

14. Treat uploads as hostile

15. Audit dependencies and keep patching

Infrastructure items I did not test

Pre-launch checklist

Common mistakes

Related Dev Talk articles and tools

Frequently asked questions

Is Laravel secure by default?

What is the difference between APP_ENV and APP_DEBUG?

Do I need all of these if I'm behind Cloudflare or a load balancer?

Should staging have debug mode off too?

How often should I run composer audit?

PostgreSQL vs MySQL Performance: Real Benchmarks Compared

The short answer

How I tested

Result 1: OLTP throughput with sysbench

Result 2: reporting queries over 2 million rows

Result 3: adding an index made MySQL's join slower

Result 4: what repeated updates do to the table

Result 5: connections

How to run this comparison on your own data

Common mistakes when comparing databases

Choosing: what the numbers do and do not say

Related Dev Talk articles and tools

Frequently asked questions

Is PostgreSQL faster than MySQL?

Should I migrate from MySQL to PostgreSQL for speed?

Does Laravel work with both?

What about MariaDB?

Would you get the same results on bigger hardware?

How to Detect and Fix PHP Memory Leaks

How I tested

Step 1: Confirm it is a leak, not just a big job

Cause 1: a static array, singleton or global that only grows

Cause 2: circular references, and why PHP's garbage collector does not always save you

The sneaky cycle: a closure that captures $this

Cause 3: listeners and callbacks registered over and over

Cause 4: the query log in a long-running process

Find out which objects are being kept: php-meminfo

Contain a leak you cannot fix today

Common mistakes

Related Dev Talk articles and tools

Frequently asked questions

Does PHP have memory leaks?

Should I call gc_collect_cycles() in my code?

Why does the process memory in top not go down after unset()?

Is Xdebug the right tool for finding leaks?

Is a memory limit on queue workers a real fix?

Docker Build Too Slow? 10 Ways to Speed It Up

Step 0: how I tested, and what the numbers mean

1. Find out which step is slow before changing anything

2. Add a .dockerignore file

3. Order layers from least to most frequently changed

4. Use cache mounts for package downloads

5. Split independent work into stages: BuildKit builds them in parallel

6. Create and delete in the same layer

7. Choose a smaller, pinned base image

8. Share the build cache in CI

9. Stop accidentally invalidating the cache

10. Watch the builder's cache, and prune on purpose

Putting it together: a Laravel Dockerfile

Common mistakes

Related Dev Talk articles and tools

AI Coding Prompts That Actually Improve Productivity