DEV Community: devTalk

Laravel .env Configuration: env() vs config() Explained

devTalk — Sat, 14 Nov 2026 15:12:18 +0000

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

The classic Laravel deployment bug goes like this: everything works on your machine, you run php artisan config:cache in production, and a setting that was fine yesterday is suddenly null. The cause is almost always an env() call in the wrong place. This article explains how .env, env() and config() fit together, with short examples you can run, and covers the parts that bite in practice: value types, quoting, environment files, config caching and encrypted env files.

Everything below was run on Laravel 13.40.0 with PHP 8.3.

The flow in one line

.env (or a real environment variable) → read by env() inside a file inconfig/ → read everywhere else with config().

The Laravel docs state the rule directly: once the configuration is cached, the .env file is no longer loaded, so you should only call env() from your configuration files. Everything else in the app reads config().

A working example: adding your own setting

Say you integrate a payment API. First add the values to .env:

PAYMENT_API_URL=https://api.pay.example.test
PAYMENT_TIMEOUT=30
PAYMENT_DEBUG=true

Then expose them through a config file. Here I added an entry to config/services.php. The second argument to env() is the default, used when the variable doesn't exist:

// config/services.php
'payment' => [
    'url'     => env('PAYMENT_API_URL', 'https://sandbox.pay.example.test'),
    'timeout' => (int) env('PAYMENT_TIMEOUT', 10),
    'debug'   => env('PAYMENT_DEBUG', false),
],

In application code, use config() with dot notation. Using the same pattern in a controller, job or service:

$url     = config('services.payment.url');
$timeout = config('services.payment.timeout');

To see the effect, I printed both calls from an Artisan command. With nothing in .env, the defaults apply. After adding the three lines, the values come through, already converted: the timeout is an integer, and true became a real boolean.

-- nothing in .env --
env(PAYMENT_API_URL)             = NULL
config(services.payment.url)     = 'https://sandbox.pay.example.test'
config(services.payment.timeout) = 10
config(services.payment.debug)   = false

-- after adding the three lines --
env(PAYMENT_API_URL)             = 'https://api.pay.example.test'
config(services.payment.url)     = 'https://api.pay.example.test'
config(services.payment.timeout) = 30
config(services.payment.debug)   = true

(php artisan probe in these outputs is a throwaway command I defined in routes/console.php to print the values; it is not built into Laravel.)

Real environment variables beat .env

A variable set in the process environment (by your shell, systemd, Docker, your host's dashboard) overrides the same key in .env. This is what the docs describe, and it is why production servers often need no .env file at all:

$ PAYMENT_API_URL=https://override.example.test php artisan probe
env(PAYMENT_API_URL)         = 'https://override.example.test'
config(services.payment.url) = 'https://override.example.test'

Value types: what env() returns

Everything in .env is a string, except a few reserved words that env() converts:

`.env` value	`env()` returns
`true` / `(true)`	`true` (bool)
`false` / `(false)`	`false` (bool)
`empty` / `(empty)`	`''` (empty string)
`null` / `(null)`	`null`

I tested a few of these, including one the docs don't spell out, a quoted "false":

.env:  FLAG_TRUE=true  FLAG_FALSE=false  FLAG_QUOTED_FALSE="false"
       FLAG_EMPTY=     FLAG_NULL=null    FLAG_TEXT=hello

FLAG_TRUE          true
FLAG_FALSE         false
FLAG_QUOTED_FALSE  false
FLAG_EMPTY         ''
FLAG_NULL          NULL
FLAG_TEXT          'hello'
FLAG_UNSET         NULL

Note that the quoted "false" still came back as boolean false, so quotes do not keep the word as a string. Also note that a key with an empty value (FLAG_EMPTY=) returns an empty string, which is not the same as null, and a key that is missing entirely gives null unless you pass a default. If a setting can legitimately be a plain string like "false", don't use those words as values.

Spaces need quotes

A value containing spaces must be in double quotes. Without them the app doesn't just misread the value, it refuses to start:

# .env
MY_TITLE=My Application

$ php artisan probe
The environment file is invalid!
Failed to parse dotenv file. Encountered unexpected whitespace at [My Application].

Writing MY_TITLE="My Application" fixes it. The docs show the same rule with APP_NAME="My Application".

The config:cache trap

php artisan config:cache merges all config files into one cached file, which is faster, and you should run it on deploy. But after that, Laravel stops loading .env on each request, so a direct env() call outside config/ only sees real system environment variables. Here is the demo. I cached the config, then changed the URL in .env:

$ php artisan config:cache
   INFO  Configuration cached successfully.

$ sed -i 's#^PAYMENT_API_URL=.*#PAYMENT_API_URL=https://changed.example.test#' .env

$ php artisan probe
env(PAYMENT_API_URL)         = NULL
config(services.payment.url) = 'https://api.pay.example.test'

$ php artisan config:clear
   INFO  Configuration cache cleared successfully.

$ php artisan probe
env(PAYMENT_API_URL)         = 'https://changed.example.test'
config(services.payment.url) = 'https://changed.example.test'

Two lessons in one output. First, env() in application code returned NULL while the cache was active, even though the variable is in .env. That's the production-only bug from the introduction. Second, config() kept serving the old value, because the cache is a snapshot: changing .env has no effect until you run config:cache again (or config:clear locally). So the deploy order is: update the environment, then rebuild the cache.

The fix for the bug is always the same. Move the env() call into a config file, as in the payment example, and read config() in your code.

Environment names and extra env files

APP_ENV names the current environment, and App::environment() reads it:

use Illuminate\Support\Facades\App;

if (App::environment('local')) { /* ... */ }
if (App::environment(['local', 'staging'])) { /* local OR staging */ }

The docs also describe an environment-specific file: if APP_ENV is set externally or you pass --env, Laravel looks for .env.[name] and loads it instead of .env if it exists. The word "instead" matters. I created a .env.staging with only two keys:

.env.staging:
APP_NAME="Staging App"
PAYMENT_API_URL=https://staging.pay.example.test

$ php artisan probe --env=staging
config(services.payment.url)     = 'https://staging.pay.example.test'
config(services.payment.timeout) = 10
config(services.payment.debug)   = false
config(app.name)                 = 'Staging App'
App::environment()               = 'staging'

The timeout and debug flag fell back to their defaults (10 and false) even though .env sets them to 30 and true: the staging file replaced .env, it was not layered on top. So a .env.staging must contain every variable the app needs. And when the named file does not exist, nothing breaks, you just get the default .env under a different name:

$ APP_ENV=qa php artisan probe       # no .env.qa exists
config(services.payment.url) = 'https://api.pay.example.test'
config(app.name)             = 'Laravel'
App::environment()           = 'qa'

That quietly misleads: the app reports it is in qa while running on the .env values.

Catching wrong types: the typed getters

Laravel's Config facade has typed getters that throw when a value is the wrong type, which turns a silent bug into a clear error at the call site:

use Illuminate\Support\Facades\Config;

$timeout = Config::integer('services.payment.timeout');  // 30
$url     = Config::string('services.payment.url');
Config::integer('services.payment.url');                 // throws

Config::integer -> InvalidArgumentException: Configuration value for key [services.payment.url] must be an integer, string given.
Config::boolean -> InvalidArgumentException: Configuration value for key [services.payment.url] must be a boolean, string given.

Keeping secrets out of git: encrypted env files

The docs are clear that .env should not be committed, since it holds credentials. If you want your environment in source control anyway, Laravel can encrypt it. The commands and the default cipher (AES-256-CBC, which needs a 32-character key) come from the docs. Here is the round trip I ran, with a throwaway key:

$ php artisan env:encrypt --key=3UVsEgGVK36XN82KKeyLFMhvosbZN1aF
   INFO  Environment successfully encrypted.
  Key ........ 3UVsEgGVK36XN82KKeyLFMhvosbZN1aF
  Cipher ..... AES-256-CBC
  Encrypted file ..... .env.encrypted

$ php artisan env:decrypt --key=3UVsEgGVK36XN82KKeyLFMhvosbZN1aF
   ERROR  Environment file already exists.

$ rm .env
$ php artisan env:decrypt --key=3UVsEgGVK36XN82KKeyLFMhvosbZN1aF
   INFO  Environment successfully decrypted.
  Decrypted file ..... .env

$ diff .env .env.original && echo identical
identical

Decrypting refuses to overwrite an existing .env unless you pass --force. On a server you can also set the key in the LARAVEL_ENV_ENCRYPTION_KEY environment variable instead of passing --key. With --readable, variable names stay visible and only values are encrypted, which makes diffs in pull requests much more useful:

$ php artisan env:encrypt --readable --force --key=3UVsEgGVK36XN82KKeyLFMhvosbZN1aF
$ cut -c1-40 .env.encrypted | head -3
APP_NAME=eyJpdiI6Ik1VQU5yU1BQa0pGK0VycVZ
APP_ENV=eyJpdiI6IjBpVDZTeFRwOVNxRlUxZGtU
APP_KEY=eyJpdiI6Im53RTkxbG9sS0J3SGtTR0tP

(The ciphertext differs on every run; yours will look different.) Never commit the key, and don't reuse the key shown here. Store the real one in a password manager or your CI secret store. Per the docs, comments and blank lines from the original file are dropped in the readable form.

Common mistakes

env()in controllers, models or services. Works locally, returns null after config:cache. Read config() instead.
Forgetting to rebuild the cache on deploy. The cache is a snapshot; new .env values are ignored until you run config:cache again.
Unquoted values with spaces. The app refuses to boot.
Assuming.env.stagingadds to.env. It replaces it.
SettingAPP_ENVto a name with no matching file and assuming it is isolated. It silently uses .env.
Committing.env. Commit .env.example with placeholders, as the docs recommend.
Runningconfig:cacheon your dev machine. You will chase "my change does nothing" for an hour. Run it on deploy.
LeavingAPP_DEBUG=truein production. See the checklist in the production security article.

Alternatives to a .env file

On servers, real environment variables (systemd units, Docker's environment or secrets, your platform's settings page, a secrets manager) avoid keeping a plaintext file on disk at all, and Laravel reads them with the same env()-in-config pattern. That is a deployment preference rather than a Laravel requirement, so choose what fits your hosting. I only tested .env and shell variables here.

Frequently asked questions

Can I use env() anywhere if I never run config:cache?

It will work, but you are one deploy script away from the bug. Reading config() everywhere costs nothing and keeps you safe if caching is switched on later.

Why does my .env change not take effect?

Either the config is cached (run php artisan config:clear), or a real environment variable with the same name is overriding .env. Check with printenv NAME.

What is the difference between .env and .env.example?

.env holds your real values and stays out of git. .env.example is committed and lists the variable names with placeholders so teammates know what to set.

Is the encrypted env file safe to commit?

The docs say encrypted environment files may be placed in source control. The safety depends entirely on keeping the key out of the repository.

Sources

Laravel documentation: Configuration, Environment Configuration

Originally published on DEV Talk.

Palo Alto PAN-OS CVE-2026-0330: Panorama Root RCE Fix

devTalk — Sat, 14 Nov 2026 07:40:57 +0000

Palo Alto Networks published an advisory on 11 November 2026 for a PAN-OS flaw that lets an attacker run arbitrary code as root. The headline is alarming, and parts of it are justified: root on a security appliance is about as bad as it gets. But the details matter more than the headline. This one is CVE-2026-0330, it affects Panorama, it needs an authenticated administrator, and Palo Alto says it is not aware of any exploitation.

A different PAN-OS flaw, CVE-2026-0322, was exploited in October and is easy to confuse with this one. Both are covered below so you can tell them apart.

The short version

What: CVE-2026-0330, a code injection flaw (CWE-94) that lets an authenticated administrator with network access run arbitrary code with root privileges.
Where: Panorama running PAN-OS 12.2, 12.1, 11.2, 11.1 and 10.2. Cloud NGFW, Prisma Access and standalone PAN-OS firewalls are not affected.
Severity: Medium, urgency "moderate" in the advisory, though the base score is high (see below).
Exploited: Palo Alto says it is not aware of malicious exploitation. Exploit maturity is listed as unreported.
Fix: upgrade Panorama to a fixed release. No workaround is known.

What the advisory says

Item	Detail (from Palo Alto's advisory)
Weakness	CWE-94, code injection
Requirement	Authenticated administrator with network access. No user interaction. No special configuration needed to be affected
CVSS 4.0	CVSS-BT 6.1 (medium), CVSS-B 8.6. If management access is limited to a jump box, the scores drop to BT 5.7 and B 8.4
Exploitation	"not aware of any malicious exploitation"; exploit maturity: unreported
Workarounds	None known
Published	11 November 2026; found internally by Palo Alto researcher Daniel Voce

Why 6.1 and 8.6 at the same time?

One news write-up called those two numbers inconsistent. They aren't. The first, CVSS-BT, is the base score adjusted by threat information: here, exploit maturity "unreported" pulls it down. The second, CVSS-B, is the base score alone, which is high because a successful attack has high impact on confidentiality, integrity and availability. The advisory shows both, and its urgency rating follows the lower, threat-adjusted score. That reading comes from the vector in the advisory (it includes the exploit maturity field), not from an explanation Palo Alto gives, so treat it as my interpretation.

Is "attackers can execute code as root" accurate?

Yes, with a condition that the headline drops: the attacker must already be an authenticated administrator who can reach Panorama over the network. This is not an unauthenticated attack from the internet. Its practical meaning is privilege escalation: a user who can log in as an administrator, a stolen admin credential, or a compromised admin session can turn that access into full control of the underlying operating system, below the level the product normally exposes.

That matters because Panorama manages other firewalls. Root on a management server can mean visibility into, or influence over, the configuration of every device it manages. I'm describing the general role of Panorama here, not a confirmed attack path for this CVE, and the advisory doesn't discuss one.

Affected and fixed versions

The advisory lists fixed releases per branch. Find your Panorama's branch, then check you are at or above the fixed hotfix for it:

Branch	Fixed in (depending on your maintenance release)
12.2	12.2.4-h2 or later
12.1	12.1.4-h14, 12.1.7-h12, or 12.1.10-h4 or later
11.2	11.2.4-h24, 11.2.7-h24, 11.2.10-h18, 11.2.13-h5, or 11.2.16-h2 or later
11.1	11.1.4-h39, 11.1.6-h41, 11.1.7-h13, 11.1.10-h37, 11.1.13-h17, or 11.1.16-h5 or later
10.2	10.2.7-h40, 10.2.10-h43, 10.2.13-h28, 10.2.16-h13, or 10.2.18-h14 or later

Unsupported older versions have no fix; the advisory says to upgrade to a supported fixed release. Read the way hotfix versions work: 11.2.7-h24 fixes the 11.2.7 line, and it does not mean 11.2.7-h10 is fixed. The "or later" applies within a line, so match your maintenance release first. Where it's ambiguous, trust the advisory page over any table, including this one.

On the Panorama CLI, the installed version can be read with:

show system info | match sw-version

That is the standard PAN-OS way to display the software version, but I didn't run it against a device. The web interface shows the same value on the dashboard.

Reduce exposure while you schedule the upgrade

The advisory states that restricting management access to trusted internal IP addresses significantly reduces the risk, and gives a lower score when access goes through a jump box. In practice:

Never expose Panorama's management interface to the internet or to general user networks.
Allow management only from a small set of internal addresses or a dedicated jump host. In the PAN-OS web interface this is the management interface's permitted IP addresses setting. Check Palo Alto's documentation for the exact location in your version, as I haven't verified the menu path.
Reduce the number of administrator accounts, remove stale ones and require MFA where you can. The flaw needs an administrator, so every admin account is part of the attack surface.
Palo Alto notes that customers with a Threat Prevention subscription get limited coverage from Threat IDs 510045 and 510048, and that this requires SSL decryption. It is partial coverage, not a substitute for patching.

The advisory says access restriction reduces risk but doesn't replace the update.

Don't mix it up with CVE-2026-0322

The same weeks brought a second, better-known PAN-OS flaw:

	CVE-2026-0322	CVE-2026-0330
Product	PA-Series and VM-Series firewalls, and Panorama	Panorama only
Impact	Authenticated RCE as root on the management interface	Authenticated RCE as root
CVSS	8.6 (as reported)	CVSS-B 8.6, CVSS-BT 6.1
Exploited	Yes: "very limited exploitation" reported; added to CISA's KEV catalog	Not known to be
Patched	15 October 2026	11 November 2026

The 0322 details come from The Hacker News coverage, not the vendor page, which I couldn't open. If you patched for 0322 in October, you may still need the new Panorama release for 0330. The fixed hotfix numbers differ.

The Hacker News also lists three IP addresses that Palo Alto assessed as linked to the 0322 activity: 66.42.72.14, 208.83.239.114 and 149.248.47.234. If you keep management-interface access logs, a quick look is cheap:

grep -E -w '66\.42\.72\.14|208\.83\.239\.114|149\.248\.47\.234' /path/to/your/access.log

No hits don't mean you are clean (attackers change addresses), and these are not indicators for CVE-2026-0330. The -w flag makes 66.42.72.14 not match 66.42.72.145. I tested the command against a sample log.

A sensible order of operations

Inventory every Panorama (physical and virtual) and its PAN-OS version.
Check that none are reachable from untrusted networks, and fix that first. It takes minutes.
Schedule upgrades to the fixed release for each branch, starting with the most exposed.
Review administrator accounts, API keys and recent admin logins.
After the upgrade, confirm the new version and that managed devices still check in.

Common mistakes

Assuming "medium" means "can wait" on a device with root-level impact. A moderate score reflects the admin requirement and no known exploitation, not harmlessness.
Confusing the two CVEs, and patching only one.
Checking firewalls but forgetting Panorama.
Applying the wrong hotfix for your maintenance line.
Treating a management interface behind a VPN as safe without limiting who can log in.

Frequently asked questions

Does CVE-2026-0330 affect my PA-Series firewall?

According to the advisory, standalone PAN-OS firewalls, Cloud NGFW and Prisma Access are not affected by this CVE. CVE-2026-0322 is the one that covers firewalls.

Is it exploited in the wild?

Palo Alto says it is not aware of any malicious exploitation of CVE-2026-0330. That can change, so check the advisory page.

Can an unauthenticated attacker use it?

The advisory requires an authenticated administrator with network access.

Is there a workaround?

None known. Restricting management access lowers risk but does not fix the flaw.

Sources

Originally published on DEV Talk.

Chrome Zero-Day CVE-2026-125350: Update and Check

devTalk — Sat, 14 Nov 2026 05:57:57 +0000

Google has patched another Chrome vulnerability that attackers were already exploiting. It is tracked as CVE-2026-125350, a use-after-free bug in Chrome's XML component, and the fix shipped on 9 November 2026. If your browser is older than the fixed build, a web page can be enough to trigger it.

The headlines say "execute malicious code remotely", which is true but easy to over-read. This article explains what has actually been confirmed, what has not, which versions are safe, and how to check every Chromium-based browser you and your team run, including the ones that don't look like browsers.

The short version

Bug: CVE-2026-125350, use-after-free (CWE-416) in Chrome's XML component, rated High by Chrome.
Exploited: Google says it is aware that an exploit for this CVE exists in the wild.
Fixed in: Stable 157.0.8103.50 (Linux) and 157.0.8103.50/.51 (Windows, macOS); Extended Stable 156.0.8078.96.
Your action: update, then relaunch the browser. The fix does not apply until the restart.

What is confirmed

Item	Detail
CVE	CVE-2026-125350
Component and type	XML, use-after-free
Reported	6 November 2026, by an anonymous researcher
Fixed and disclosed	9 November 2026 (Chrome Stable channel update)
CISA KEV	Added 10 November 2026, with a due date of 24 November for US federal civilian agencies
Severity	High (Chrome). CVSS 3.1 base score 8.8, scored by CISA, per two security news sites
Affected	Chrome builds before 157.0.8103.50, per the CVE record
Same release	Nine security fixes in total. Another XML use-after-free, CVE-2026-125346, is in the same update, but the in-the-wild statement applies only to CVE-2026-125350

What "remote code execution" means here

This is where the headlines run ahead of the evidence. The CISA catalog entry, as quoted by one write-up, describes a remote attacker running code inside the sandbox through a crafted web page. Chrome's sandbox is a separate layer that limits what a compromised renderer can do to the rest of the machine. A sandbox escape or full device compromise has not been publicly confirmed for this bug.

That is still serious. Real attacks on browsers are usually chains: one bug to get code running in the renderer, and a second one to break out. A bug exploited in the wild is often the first link of such a chain, though nobody has published what the second link was here. Treat the missing information as unknown, not as a reason to wait.

It also needs a user to visit a page. No account, no credentials, no prior access: just a link, an ad, a compromised site or an embedded frame. Google and CISA have not said who is using the exploit or against whom, so don't assume you are not a target because you are not a high-profile one.

Why a use-after-free bug is dangerous

A use-after-free happens when code keeps using memory after it has been released. If an attacker can control what gets placed in that freed memory, the program may end up reading or running attacker-chosen data. Browsers parse untrusted input constantly, in a language (C++) where this class of mistake is possible, so they see a steady supply of such bugs. That is why Chrome security updates arrive so often, and why running an old build is the real risk, not any single CVE.

BleepingComputer's headline calls this the eighth Chrome zero-day exploited in attacks this year. I could only read the headline, not the article, so I'm quoting it as reported.

Check your version in one minute

The fastest check is the browser itself: open chrome://version, or go to Help, then About Google Chrome, which also triggers the update download. Look for 157.0.8103.50 or newer.

From a terminal:

# Linux
google-chrome --version

# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --version

# Windows (default install path)
(Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

To compare it against the fixed build in a script (a fleet audit, a CI image check), here is a small helper. It accepts either the whole version string or just the number:

#!/usr/bin/env bash
# usage: ./chk.sh "<version output from the browser>"
# Fixed builds for CVE-2026-125350: Stable 157.0.8103.50 or newer,
# Extended Stable 156.0.8078.96 or newer.
CUR="$(echo "$1" | grep -oE '[0-9]+(\.[0-9]+){3}' | head -1)"
[ -z "$CUR" ] && { echo "no version found in: $1"; exit 2; }
ge() { [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -1)" = "$2" ]; }
MAJOR="${CUR%%.*}"
if [ "$MAJOR" -ge 157 ] && ge "$CUR" 157.0.8103.50; then echo "$CUR: has the fix"
elif [ "$MAJOR" -eq 156 ] && ge "$CUR" 156.0.8078.96; then echo "$CUR: has the fix (Extended Stable line)"
elif [ "$MAJOR" -gt 157 ]; then echo "$CUR: newer major, assume fixed"
else echo "$CUR: older than the fixed builds, update"; fi

Running it:

$ ./chk.sh "Google Chrome 156.0.8078.96"
156.0.8078.96: has the fix (Extended Stable line)
$ ./chk.sh "157.0.8103.9"
157.0.8103.9: older than the fixed builds, update
$ ./chk.sh "153.0.8010.12"
153.0.8010.12: older than the fixed builds, update

The comparison uses sort -V, which compares dotted numbers correctly, so 157.0.8103.9 is treated as older than 157.0.8103.50. A plain string comparison would get that wrong. I tested the script against those cases, including a version-less input, which exits with an error.

How to update

Desktop Chrome (Windows, macOS): Help, About Google Chrome, then Relaunch. Chrome downloads updates in the background, but the fix takes effect only after a restart. A browser that has run for weeks with a pending update is still vulnerable.
Linux: use the package manager. For Google's apt repository, that is sudo apt update && sudo apt install --only-upgrade google-chrome-stable, then restart the browser. Use the equivalent command for your distribution if you installed Chromium from a distro package, and check that its maintainers have shipped the fix.
Android: update through Google Play. One report lists the Android build as 157.0.8103.50, but the Android advisory does not list this CVE individually, so confirm the version on your own device.
Managed fleets: use your endpoint management tool to read installed versions, and consider Chrome's enterprise relaunch notification policies so users are not left on a pending update indefinitely. Check the current policy documentation for exact names and behavior, since I did not test them.

Other Chromium browsers and apps

The vulnerable code lives in Chromium, the open-source engine, so Edge, Brave, Opera, Vivaldi and others may be affected until they ship a build based on the fix. Each vendor patches on its own schedule. Two data points from the sources I read:

Microsoft's Edge release notes of 9 November said it was aware of exploits in the wild and was working on a fix, without naming the CVE, according to a secondary write-up. Check the Edge security notes for the current fixed build.
I did not find a confirmed fixed version for Opera, Vivaldi or Brave in what I read. Look up each vendor's own advisory rather than assuming.

As developers we also run Chromium in places that don't look like browsers:

Playwright, Puppeteer and Selenium test browsers. They download pinned Chromium builds. In my test environment, Playwright's bundled Chromium reported 153.0.8010.12, which is older than the fixed build. By the CVE's affected range that means it does not contain this fix. I did not test whether the exploit works against it. If your CI browses untrusted pages (scraping, link checking, screenshot services), update the browser package and the cached browser downloads.
Electron apps. Each app bundles its own Chromium. Whether an app is exposed depends on its Electron version and on whether it loads untrusted content. Look at the vendor's release notes rather than your installed Chrome.
Headless Chrome in containers. A Docker image built months ago keeps the browser version it was built with. Rebuild images that include Chrome or Chromium.

If you can't patch right away

Patching is the fix. Everything below only reduces exposure, and none of it replaces updating:

Close long-running browser sessions and restart the browser, so a downloaded update is actually applied.
Avoid opening untrusted links from email and chat on unpatched machines.
Keep browser isolation features and the sandbox enabled. Don't launch Chrome with --no-sandbox outside a throwaway container, and if CI needs it, keep that CI away from untrusted pages.
Restrict unapproved extensions, and use DNS or web-gateway filtering if your organization has them.
Watch endpoint telemetry for unusual browser child processes, repeated browser crashes and odd outbound connections.

Common mistakes

Updating without relaunching.
Checking only Chrome and forgetting Edge, Brave, Electron apps and CI browsers.
Assuming a sandboxed bug is harmless, or assuming it means total compromise. Neither is established.
Waiting for details of the exploit before patching.
Reading the CISA deadline as applying to everyone. The 24 November date is for US federal civilian agencies; for everyone else it is a useful priority signal.

Frequently asked questions

Is CVE-2026-125350 being exploited right now?

Google says it is aware that an exploit exists in the wild. It has not disclosed who is using it or how widely.

Do I need to do anything if Chrome updates itself?

Yes: relaunch. Check chrome://version afterwards and confirm the number is at least 157.0.8103.50 (or 156.0.8078.96 on Extended Stable).

Does it affect Firefox or Safari?

The sources I read describe a Chrome and Chromium bug. I did not find anything saying Firefox or Safari are affected, but I did not test them.

Did the attackers escape the sandbox?

Not publicly confirmed. Code execution in the sandbox is the confirmed description.

How do I know if I was attacked?

There are no public indicators of compromise that I could find. Google has not published any attacker details. The practical response is to patch and review endpoint telemetry for unusual browser behavior.

Sources

Originally published on DEV Talk.

Malicious Claude Code Extension in Cursor: Check Your Machine

devTalk — Sat, 14 Nov 2026 05:20:14 +0000

If you use Cursor and had the Claude Code extension installed on 29 October 2026, there is a real chance you ran a backdoored copy of it. Headlines have described this as "Anthropic hacked", and that is not what the vendor reports say. This post separates what has been confirmed from what has been claimed, and gives you a short, practical checklist.

The short version: a modified build of the extension sat in Cursor's extension marketplace for about 11 hours. It tried to give an attacker SSH access to the developer's machine. Cursor says Anthropic did not publish it and that its product was not vulnerable.

What is confirmed

These points come from Cursor's own notices, with Sophos and other security vendors repeating them:

Affected versions: Anthropic.claude-code 2.1.312 and 2.1.313, on Windows and macOS, from the Cursor VS Code extension marketplace. Cursor's first notice named 2.1.313; it was updated on 30 October to include 2.1.312.
Window: about 09:27 to 20:35 UTC on 29 October 2026 (Cursor gives it as roughly 2:27 am to 1:35 pm Pacific).
Exposure: Cursor estimates up to 5,000 users. It describes these as users who requested the specific cached versions that day.
Who built it: Cursor states that the malicious versions "were not developed by Anthropic."

Was Anthropic hacked?

Based on Cursor's incident update (13 November), no. Cursor says an attacker used a credential taken from Cursor's own internal data to place unauthorized copies of the extension on the cache that serves its marketplace. It says Anthropic did not publish this copy, this was not a vulnerability in Anthropic's product, and the upstream source, Open VSX, never had the malware.

The same update describes how the attacker got that credential: an access key Cursor had issued to a third-party inference provider, Fireworks, which Cursor says was exposed by Fireworks. The attacker used it to copy data from a read-only storage bucket, and some stored traces contained unredacted credentials. I have only Cursor's account of this chain. Treat it as the vendor's statement, not independent confirmation.

I could not open the Doublepulsar article that prompted this post, so I can't say how it frames the incident. If you have read it, compare its claims against Cursor's notices linked at the end.

What the malicious build does

According to Cursor, it:

Collects host and user details (hostname, username, OS, architecture, home directory, environment variable names, working directories, Git email and public IP) and sends them to an attacker's server.
Tries to add an attacker-controlled SSH key, enable SSH and open a reverse tunnel. Cursor says this would usually fail without administrator rights.
Tries to persist through a LaunchAgent on macOS or a scheduled task on Windows, retrying about every 60 seconds.

Note the word "tries". Sophos, citing an analysis by Phorion, says coding errors made SSH enablement fail on most macOS and Windows hosts. That limits the damage on many machines, but it is not a reason to skip the checks. Environment variable names alone can tell an attacker what cloud providers and services you use.

Cursor says the attacker's server has been taken offline. That means blocking the IP is of limited use now, but its logs and your own are still useful for working out whether a machine connected.

Check whether you were affected

Did you have the extension in Cursor on 29 October? Look at your installed extensions and the version. If you only use Claude Code in VS Code from Microsoft's marketplace, or in a terminal, these notices do not cover you.
Look for the planted SSH key. Cursor's notice names the key comment svc-telemetry. On macOS or Linux:grep -n 'svc-telemetry' ~/.ssh/authorized_keys No output (or "No such file") means that key is not there. A matching line means the key was added.
Look at running processes and persistence. Cursor provides platform-specific remediation scripts (remediate-macos.sh and remediate-windows.ps1) and the full list of indicators. Use those rather than a checklist copied from a blog, including this one, because indicators were updated after the first notice.

On Windows, Cursor gives an equivalent PowerShell check for the user's and ProgramData's authorized_keys files. Get it from the notice itself.

If you find something

Cursor's advice, in order of priority:

Isolate the machine if there are signs the code ran or a backdoor was installed.
Do not rely on uninstalling the extension. Cursor warns that uninstalling may not be enough because standalone persistence scripts can keep running. Remove the unauthorized key, the persistence entries and the tunnel processes. Consider rebuilding the host.
Rotate credentials and sessions that were reachable from that machine, doing it from a trusted system. Start with SSH keys, cloud provider keys, API tokens and anything stored in environment variables or .env files.

If you have no sign of the key and no sign of the persistence entries, a precautionary rotation of the most sensitive credentials is still cheap compared with the alternative.

Lessons for the rest of us

These are my recommendations, not findings from the incident:

Extensions run with your privileges. They can read your environment, your SSH directory and your project secrets. Treat an editor extension update like a dependency update, not like a theme change.
Auto-update is a trade-off. It gets you security fixes quickly, but it also delivers a bad build quickly. For machines that hold production credentials, consider managing extension versions deliberately.
Keep production secrets off developer laptops. Short-lived credentials, a secrets manager and separate deploy keys limit what a compromised editor can reach. Our SSH deploy article uses a dedicated deploy key for that reason.
Watch yourauthorized_keys. A new key you didn't add is a high-signal alert on any machine, and it is simple to monitor.
Supply-chain risk follows the tooling. A malicious build under a trusted vendor's name is exactly the case where checking the publisher alone is not enough.

Common mistakes during cleanup

Uninstalling the extension and stopping there.
Rotating credentials from the possibly compromised machine.
Assuming you are safe because you use the Microsoft marketplace. The notices concern the Cursor marketplace only; check where your copy came from.
Searching only for one version number. Cursor extended the affected versions after its first notice.
Relying on the attacker IP alone, since the server was taken down.

Frequently asked questions

Does this affect the Claude Code CLI or the extension in VS Code?

The notices I read describe the Cursor marketplace copy only. Cursor says there is no evidence that other versions of the extension or the official distribution are affected. I did not test any of this.

Is it a remote access trojan?

Cursor describes an attempt to add an SSH key and open a reverse tunnel, which would give an attacker remote access if it worked. I haven't seen the term "remote access trojan" in the vendor notices I read, so I use their wording.

Which version should I be on now?

Follow Cursor's current notice. One third-party advisory I read mentioned 2.1.314 as the fixed version, but I couldn't verify that, and updating alone does not remove anything already planted.

Sources

Originally published on DEV Talk.

10 Common API Design Mistakes

devTalk — Sat, 14 Nov 2026 03:15:18 +0000

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

Most API problems don't show up on launch day. They show up months later, when a mobile app can't be updated because a field changed type, when a retry double-charges a customer, when a support ticket turns out to be one user reading another user's order. The code worked. The design was the bug, and by then a hundred clients depend on it.

This article covers ten mistakes that I see repeated in REST-style JSON APIs, with a small demo server behind each one so the symptom is real output rather than a claim. Every mistake comes with the fix, and where the fix is written down in a standard (HTTP semantics, Problem Details, the deprecation headers) I checked the standard instead of quoting from memory. The demo servers are plain Node, so nothing here depends on a framework; the PHP/Laravel snippets show how the fixes map to the stack many readers use.

The ten at a glance

#	Mistake	The fix in one line
1	Returning `200 OK` for errors	Use the status code, let clients branch on it
2	A different error shape on every endpoint	One format, ideally `application/problem+json`
3	Ignoring HTTP method semantics	Match method to safe / idempotent behavior
4	Unbounded lists and offset pagination	Always paginate; use cursors for changing data
5	Retries that create duplicates	Idempotency keys for non-idempotent writes
6	Breaking changes with no warning	Additive changes, plus `Deprecation` and `Sunset` headers
7	No object-level authorization	Check ownership on every object access
8	Exposing and accepting whole models	Explicit response shapes and allow-listed input
9	No rate limiting	Limit, and answer `429` with `Retry-After`
10	Sloppy data conventions: money, dates, naming	Integer minor units, RFC 3339 timestamps, one naming style

1. Returning 200 OK for errors

It looks harmless and it is one of the most expensive habits. The endpoint returns 200 and puts the failure in the body:

$ curl -si localhost:4040/bad/users/999
HTTP/1.1 200 OK
Content-Type: application/json

{"success":false,"error":"User not found"}

Everything between your server and the client's code treats that as a success: HTTP clients that only throw on 4xx/5xx, retry logic, monitoring that counts error rates from status codes, caches, and the browser's network panel. Your dashboards say the API is 100% healthy while users see "not found". Every client team also has to learn your private convention for finding the real outcome.

$ curl -si localhost:4040/good/users/999
HTTP/1.1 404 Not Found
Content-Type: application/problem+json

{"type":"https://api.example.com/problems/user-not-found","title":"User not found","status":404,"detail":"No user with id 999.","instance":"/good/users/999"}

The status codes you need most are all defined in RFC 9110: 201 Created for a successful create, 204 No Content for success without a body, 400 for a malformed request, 401 and 403 for authentication and permission problems, 404, 409 Conflict, and 422 for a well-formed request that fails validation. The spec's current name for 422 is "Unprocessable Content". (My Node server still prints the older phrase "Unprocessable Entity" in the status line, which is only a label; the number is what matters.) Rate limiting uses 429, which comes from RFC 6585, and gets its own section below.

2. A different error format on every endpoint

Even with correct status codes, clients suffer when one endpoint returns {"error": "..."}, another {"message": "...", "code": 12}, and a third a bare string. Pick one shape. You don't need to invent it: RFC 9457, "Problem Details for HTTP APIs", defines one, and it replaced RFC 7807.

Per the RFC, the media type is application/problem+json and the standard members are all optional:

type: a URI that identifies the kind of problem. If it is absent, clients assume about:blank, meaning "nothing beyond the HTTP status".
status: the HTTP status code. Generators must send the same code in the actual response; consumers treat the member as advisory, since a proxy could change the real status.
title: a short summary of the problem type that stays the same across occurrences.
detail: an explanation of this specific occurrence, meant to help the client fix the problem.
instance: a URI identifying this particular occurrence.

You can add your own members, such as an errors array for per-field validation failures. Clients must ignore extension members they don't recognize, so adding them later doesn't break anyone. Keep detail useful to the caller and free of stack traces and SQL; the RFC says it is meant to help the client fix the problem rather than to provide debugging information.

Whatever your framework returns by default for a 404 or a validation failure, call two or three endpoints with curl -i and look at the shapes. If they differ, that is the work.

3. Ignoring HTTP method semantics

Two properties from RFC 9110 matter in practice. A safe method is essentially read-only: of the methods defined there, GET, HEAD, OPTIONS and TRACE are safe. An idempotent method has the same intended effect whether it is sent once or many times: PUT, DELETE and the safe methods are idempotent. POST is not on that list.

Why you care: clients, proxies and browsers act on these properties. A client may retry an idempotent request automatically after a connection failure, and a crawler or link prefetcher can follow a GET without anyone clicking. So these designs go wrong:

GET /orders/42/cancel or GET /users/7/delete: a state change behind a safe method. Anything that fetches the URL, including a prefetcher or a monitoring probe, triggers it.
POST /getUser, POST /updateUser, POST /deleteUser: everything funneled through POST, so no caching of reads and no automatic retry of anything.
A PUT that appends instead of replacing, so a retry applies the change twice and the "idempotent" label lies.

The straightforward mapping: GET /orders/42 reads, POST /orders creates, PUT /orders/42 replaces, DELETE /orders/42 removes. For actions that aren't CRUD, a sub-resource noun usually reads better than a verb in the path, for example POST /orders/42/cancellation. Don't fight over naming purity; the rule that matters is that the method's promised behavior is true.

4. Unbounded lists and offset pagination

The first version of GET /items returns everything. It works in development with 50 rows and takes the server down with 5 million. Always cap and paginate, even if you only have one client today.

The second trap is the pagination style. Offset pagination (?limit=3&offset=3) breaks when data changes between page requests. I fetched page one, deleted item 2, then fetched page two:

$ curl -s "localhost:4040/items?limit=3&offset=0"
{"data":[{"id":1,"name":"item1"},{"id":2,"name":"item2"},{"id":3,"name":"item3"}]}
$ curl -s -X DELETE localhost:4040/items/2        # 204
$ curl -s "localhost:4040/items?limit=3&offset=3"
{"data":[{"id":5,"name":"item5"},{"id":6,"name":"item6"},{"id":7,"name":"item7"}]}

Item 4 never appeared. Deleting a row on an earlier page shifted everything up by one, and the next offset jumped over it. An insert does the opposite and shows a duplicate. Cursor (keyset) pagination asks for "the items after the last one I saw" and doesn't care what moved:

$ curl -s "localhost:4040/items?limit=3&after=0"
{"data":[{"id":1,...},{"id":2,...},{"id":3,...}],"next_cursor":3}
$ curl -s -X DELETE localhost:4040/items/2        # 204
$ curl -s "localhost:4040/items?limit=3&after=3"
{"data":[{"id":4,"name":"item4"},{"id":5,"name":"item5"},{"id":6,"name":"item6"}],"next_cursor":6}

Same sequence, nothing skipped. (I shortened the first page's items with ... for width.) The Laravel documentation makes the same two points: offset pagination "may skip records or show duplicates" on data with frequent writes, and the offset clause scans through all previously matched rows, so cursor pagination performs better on large tables when the ordering columns are indexed.

// Laravel: cursor pagination (the ordering must include a unique column)
return Order::query()
    ->orderBy('id')
    ->cursorPaginate(25);

The documented limits of cursor pagination: it only supports next/previous navigation, not "jump to page 40", and it requires ordering on at least one unique column, with no null values in the ordering columns. If users truly need page numbers (an admin table, say), offset is fine; just know you are trading consistency for convenience. Also set a maximum page size on the server so ?limit=100000 is not an option.

5. Retries that create duplicates

A client sends POST /orders and the connection drops before the response arrives. Did the order go through? The client can't know, so it retries, and now there may be two orders. Mobile networks, load balancers and impatient users make this routine, not rare. Without protection, the demo server does exactly what you fear:

$ curl -s -X POST localhost:4040/orders -d '{"sku":"A1","qty":1}'
{"id":1,"sku":"A1","qty":1}  [201]
$ curl -s -X POST localhost:4040/orders -d '{"sku":"A1","qty":1}'
{"id":2,"sku":"A1","qty":1}  [201]
$ curl -s localhost:4040/orders
{"count":2}

The standard answer is an idempotency key: the client generates a unique value per logical operation and sends it with every retry, and the server remembers the result for that key. The IETF has an Internet-Draft for this, draft-ietf-httpapi-idempotency-key-header. It is a draft, not an RFC; revision 08 was the latest when I checked, and details may still change. What it currently describes:

The header is Idempotency-Key, a structured-field String, and the draft recommends a UUID or similar random value.
It targets non-idempotent methods, named as POST and PATCH.
A request that reuses a key with a different payload should get 422.
A retry that arrives while the first request is still processing should get 409.
A missing key, for an operation that requires one, should get 400.
Expiry is left to the service, which should document its policy.

My demo follows that behavior:

$ curl -si -X POST localhost:4040/orders -H 'Idempotency-Key: "k-123"' -d '{"sku":"A1","qty":1}'
HTTP/1.1 201 Created
{"id":1,"sku":"A1","qty":1}
$ curl -si -X POST localhost:4040/orders -H 'Idempotency-Key: "k-123"' -d '{"sku":"A1","qty":1}'
HTTP/1.1 201 Created
Idempotent-Replayed: true
{"id":1,"sku":"A1","qty":1}
$ curl -s localhost:4040/orders
{"count":1}

$ curl -si -X POST localhost:4040/orders -H 'Idempotency-Key: "k-123"' -d '{"sku":"B2","qty":5}'
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{"type":"about:blank","title":"Idempotency key reused with a different payload","status":422}

(Idempotent-Replayed is my own demo header, not part of the draft.) The retry returned the original order and the count stayed at one. A real implementation needs more than my in-memory map:

Store the key, a hash of the request body, and the response in the database, with a unique constraint on the key (scoped to the user or API client, so one customer can't collide with another).
Insert the key before doing the work, so two simultaneous retries can't both pass the check. The loser gets the 409.
Write the key and the business change in the same transaction, or you can record a key for work that rolled back.
Expire old keys on a schedule you document.

I did not write a Laravel implementation for this article, so there is no copy-paste middleware here; the four rules above are the part that makes it correct, and the storage can be a plain table.

6. Breaking changes with no warning

Clients you don't control (mobile apps in particular) can't be updated the day you ship. What counts as breaking is mostly a matter of reasoning about what a client has to assume. Adding a new optional response field or a new endpoint is normally safe, as long as clients ignore unknown fields. Removing or renaming a field, changing its type (a number to a string, an object to an array), tightening validation, or changing what a status code means will break someone.

When you must break something, say so in the response itself. Two standards cover this. RFC 9745 defines a Deprecation response header whose value is a date written as a structured-field Date, for example @1688169599, and it can be in the past (already deprecated) or the future (planned). The older RFC 8594 defines Sunset, the time the resource is expected to stop responding, and RFC 9745 says the Sunset time must not be earlier than the Deprecation date. A Link header with rel="deprecation" points to the migration documentation. A response from the demo:

$ curl -si localhost:4042/v1/report
HTTP/1.1 200 OK
Deprecation: @1788912000
Sunset: Thu, 30 Sep 2027 23:59:59 GMT
Link: <https://api.example.com/docs/migrate-v2>; rel="deprecation"; type="text/html"

Note the two date formats: Deprecation is a Unix timestamp prefixed with @ (here 1788912000 is 9 September 2026, 00:00 UTC), while Sunset uses the classic HTTP date. RFC 9745 itself points out that they differ for historical reasons. I got the weekday wrong on my first draft of that header, which is a good reason to generate these values with code instead of typing them.

The headers only help if someone reads them. Log which clients still call deprecated endpoints (by API key or user agent) so you can contact them before the sunset date, and keep the old version running until the numbers say it is safe. How you expose versions (a /v1/ path prefix, a header, a media type) is a trade-off with no universally right answer; a path prefix is the simplest to route, cache and debug, so it is a reasonable default.

7. No object-level authorization

Authentication tells you who is calling. Authorization has to check, on every request for a specific object, whether this caller may touch it. The classic mistake is checking only that the token is valid, then loading /orders/{id} for whatever ID the client sent. This is Broken Object Level Authorization, and it is API1 in the OWASP API Security Top 10 (2023 edition). In the demo, Ann's token reads Bob's order:

$ curl -s -H 'Authorization: Bearer tok-ann' localhost:4041/bad/orders/11
{"id":11,"owner":2,"total":9900} [200]

$ curl -s -H 'Authorization: Bearer tok-ann' localhost:4041/good/orders/11
{"title":"Not found"} [404]

$ curl -s -H 'Authorization: Bearer tok-ann' localhost:4041/good/orders/999
{"title":"Not found"} [404]

The fixed version returns the same 404 for "exists but isn't yours" and "doesn't exist", so the response doesn't confirm which IDs are real. Whether to use 404 or 403 is a design decision: 403 is more honest and easier to debug but tells an attacker the object exists; 404 hides that. Pick one on purpose and apply it consistently.

Using sequential integer IDs makes the bug easy to exploit, because the attacker just counts upward, but switching to UUIDs doesn't fix the missing check; it only makes guessing harder. The fix is the check, and the cheapest way to make it hard to forget is to query through the owner:

// Scope the lookup to the authenticated user; a foreign id behaves like a missing one
$order = $request->user()->orders()->findOrFail($id);

// Or, if you prefer explicit policies (this returns 403 on denial):
$order = Order::findOrFail($id);
$this->authorize('view', $order);

The same applies to functions, not only objects: an endpoint like DELETE /admin/users/5 needs its own role check (OWASP lists that as API5, Broken Function Level Authorization). For a wider checklist of what to lock down in a Laravel app.

8. Exposing and accepting whole models

Two mirror-image mistakes share one cause: the API shape is whatever the database model happens to look like.

On the way out, returning the model directly leaks columns nobody meant to publish. In the demo, GET /bad/me serializes the whole user record:

$ curl -s -H 'Authorization: Bearer tok-ann' localhost:4041/bad/me
{"id":1,"name":"Ann","email":"ann@example.test","is_admin":false,"password_hash":"$2y$secret"}

$ curl -s -H 'Authorization: Bearer tok-ann' localhost:4041/good/me
{"id":1,"name":"Ann","email":"ann@example.test"}

On the way in, copying the request body onto the model is mass assignment. Ann sends one extra field:

$ curl -s -X PATCH -H 'Authorization: Bearer tok-ann' -d '{"name":"Ann","is_admin":true}' localhost:4041/good/me
{"ok":true,"is_admin":false}

$ curl -s -X PATCH -H 'Authorization: Bearer tok-ann' -d '{"name":"Ann","is_admin":true}' localhost:4041/bad/me
{"ok":true,"is_admin":true}

On the unsafe endpoint she promoted herself to admin. OWASP groups both under API3:2023, Broken Object Property Level Authorization. The fix is the same in both directions: write the shape down. In Laravel that means a Form Request with explicit rules, using only validated() input, and an API Resource for output:

// app/Http/Requests/UpdateProfileRequest.php
class UpdateProfileRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name'  => ['sometimes', 'string', 'max:100'],
            'email' => ['sometimes', 'email', 'max:255'],
        ];
    }
}

// app/Http/Resources/UserResource.php
class UserResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id'    => $this->id,
            'name'  => $this->name,
            'email' => $this->email,
        ];
    }
}

// controller
public function update(UpdateProfileRequest $request)
{
    $request->user()->update($request->validated());

    return new UserResource($request->user()->refresh());
}

Because validated() returns only the keys that have rules, an is_admin field in the body is dropped rather than saved. Treat the model's $fillable list as a second line of defense, not the first. The explicit resource also gives you a stable contract: adding a column to the table doesn't silently add a field to the public API.

9. No rate limiting

Without limits, one buggy client in a retry loop, one scraper or one credential-stuffing script can eat the capacity every other user shares. OWASP calls the general problem Unrestricted Resource Consumption (API4:2023). Limits also protect your database and your bill.

RFC 6585 defines 429 Too Many Requests: the client sent too many requests in a given time. The response should describe the problem and may include a Retry-After header saying how long to wait. Giving well-behaved clients a number is what turns a limit from a wall into a protocol:

$ for i in 1 2 3 4; do curl -s -o /dev/null -w "req $i -> %{http_code}\n" localhost:4042/search; done
req 1 -> 200
req 2 -> 200
req 3 -> 200
req 4 -> 429

$ curl -si localhost:4042/search
HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 30

{"title":"Too Many Requests","status":429,"detail":"Limit is 3 requests per minute."}

In Laravel, define a named limiter and attach it with the throttle middleware. This is the example from the framework documentation:

// app/Providers/AppServiceProvider.php, in boot()
RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});

The docs state that Laravel returns a 429 automatically when the limit is exceeded, but they don't list which headers it sends, so run curl -i against your own app and confirm that Retry-After is present before you tell client developers they can rely on it. Think about what you key the limit on: per-IP limits punish everyone behind one office or mobile carrier address, while per-user limits don't stop anonymous floods, so most APIs need both. Stricter limits belong on login and password-reset endpoints, and the limit counters should live in a shared store like Redis when you run more than one server, otherwise each server counts separately.

10. Sloppy data conventions: money, dates and naming

These are small decisions that are very hard to change later.

Money as floating point. JSON numbers are doubles in many clients, and binary floating point can't represent most decimal amounts exactly:

$ node -e 'console.log(19.99*100); console.log(Math.round(19.99*100))'
1998.9999999999998
1999

$ php -r 'var_dump((int)(19.99*100));'
int(1998)

That PHP line is the dangerous one: a cast truncates, and a customer is charged 1998 cents instead of 1999. Send money as an integer in the smallest currency unit plus an explicit currency, {"amount": 1999, "currency": "USD"}, or as a decimal string ("19.99") that the client parses with a decimal library. Be careful with currencies that don't have two minor digits; this is why the currency should travel with the amount.

Dates without a time zone. "2026-11-09 22:03" means nothing without an offset. Use RFC 3339 / ISO 8601 timestamps with an explicit offset or Z, and store UTC. The same instant in both forms, from Node:

2026-11-09T22:03:00+05:30      (what the user saw in Colombo)
2026-11-09T16:33:00.000Z       (the same instant in UTC)

Mixed naming. userId in one response, user_id in another, UserID in a third. Pick one convention (snake_case or camelCase), and apply it to field names, query parameters and error members alike. Same for booleans (is_active everywhere, not active here and enabled there), plural collection names, and ID types. A lint step in CI over your OpenAPI file will catch most drift, and having that file at all is the other half of this mistake: an API without a machine-readable description gets documented by whoever last read the code.

Git Merge vs Rebase: Practical Examples and When to Use Each

devTalk — Fri, 13 Nov 2026 15:13:58 +0000

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

You branched off main, did some work, and now main has moved on. Git offers two ways to bring the branches back together, git merge and git rebase, and both end with the same files on disk. What differs is the history you leave behind, how many conflicts you resolve, and what happens to your teammates if the branch is shared. Pick wrongly and you get either a tangle of merge commits or a force-push that wrecks someone's afternoon.

This article runs both on the same repository, side by side, with the real commands and output, then covers the situations where the choice matters: conflicts, shared branches, squash merges, pulling, and undoing a mistake. All of it was run on Git 2.43.0.

The short answer

	Merge	Rebase
What it does	Adds one new commit with two parents that joins the histories	Replays your commits one by one on top of the new base, creating new commits
History afterwards	Branches and joins stay visible	One straight line
Your existing commits	Untouched, same SHAs	Replaced, new SHAs
Conflicts	Resolved once, in the merge commit	Can appear once per replayed commit
Safe on a branch others use	Yes	No, unless everyone agrees
Undo	`reset` before pushing; `revert -m 1` after	`reset --hard ORIG_HEAD` or the reflog

My rule of thumb, as a practical recommendation rather than a law: rebase your own unpublished work to keep it tidy, merge anything that other people already have. The sections below show why.

The starting point

A small repository. main has two commits. feature/search was branched from the second one and has two commits of its own. Meanwhile someone added a third commit to main, so the histories have diverged:

git log --oneline --graph --decorate --all

* cb7fefb (HEAD -> main) Update README
| * ad97d89 (feature/search) Add search filters
| * 1625bc4 Add search index
|/
* 61382cb Add app skeleton
* db814b5 Initial commit

Merge: keep the history exactly as it happened

git switch main
git merge feature/search

Merge made by the 'ort' strategy.
 search.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 search.txt

*   a3e6b0f (HEAD -> main) Merge branch 'feature/search'
|\
| * ad97d89 (feature/search) Add search filters
| * 1625bc4 Add search index
* | cb7fefb Update README
|/
* 61382cb Add app skeleton
* db814b5 Initial commit

Nothing was rewritten. ad97d89 and 1625bc4 kept their SHAs, and a new merge commit a3e6b0f records that the two lines of work joined. The graph is honest, but it gets busy on a team that merges many branches a day. One tool helps: --first-parent follows only the main line and hides the commits inside each merged branch:

git log --oneline --first-parent

a3e6b0f Merge branch 'feature/search'
cb7fefb Update README
61382cb Add app skeleton
db814b5 Initial commit

That gives you a readable "one line per feature" view of main without rewriting anything.

Rebase: replay your commits on top of main

Same starting point, different command. Run it on the feature branch:

git switch feature/search
git rebase main

Successfully rebased and updated refs/heads/feature/search.

(While it works, Git also prints a progress line such as Rebasing (2/2).) Compare the two commits before and after:

before:                  after:
ad97d89 Add search filters       cb365e1 Add search filters
1625bc4 Add search index         9a325d7 Add search index

* cb365e1 (HEAD -> feature/search) Add search filters
* 9a325d7 Add search index
* cb7fefb (main) Update README
* 61382cb Add app skeleton
* db814b5 Initial commit

The commit messages and changes are the same, but the SHAs are different. A commit's SHA includes its parent, and the parent changed, so Git created new commits and moved the branch label to them. The old commits still exist (more on that in the undo section). The history is now a single line, and merging into main becomes a fast-forward with no merge commit:

git switch main
git merge feature/search

Updating cb7fefb..cb365e1
Fast-forward
 search.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 search.txt

If you want Git to refuse anything that is not a clean fast-forward, add --ff-only. On the diverged branches from the start of this article it stops and tells you what to do:

$ git merge --ff-only feature/search
hint: Diverging branches can't be fast-forwarded, you need to either:
hint:
hint:   git merge --no-ff
hint:
hint: or:
hint:
hint:   git rebase
hint:
hint: Disable this message with "git config advice.diverging false"
fatal: Not possible to fast-forward, aborting.

Fast-forward vs --no-ff, when nothing has diverged

If main has not moved, a merge does not need a merge commit. Git just slides the branch pointer forward:

$ git merge feature/login
Updating 61382cb..e6c3f9a
Fast-forward
 login.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 login.txt

* e6c3f9a (HEAD -> main, feature/login) Add login validation
* 0745ccd Add login form
* 61382cb Add app skeleton
* db814b5 Initial commit

The result is linear, and afterwards nobody can tell a branch ever existed. If you want to keep a visible record of the feature as a unit, force a merge commit with --no-ff:

$ git merge --no-ff -m "Merge feature/login" feature/login
Merge made by the 'ort' strategy.

*   767bc44 (HEAD -> main) Merge feature/login
|\
| * e6c3f9a (feature/login) Add login validation
| * 0745ccd Add login form
|/
* 61382cb Add app skeleton
* db814b5 Initial commit

Keeping a feature branch up to date

The most common daily use: main moved, and you want its changes in your branch. Merging main into the feature branch works, but adds a merge commit every time you do it:

$ git merge main
Merge made by the 'ort' strategy.

*   eeec354 (HEAD -> feature/search) Merge branch 'main' into feature/search
|\
| * cb7fefb (main) Update README
* | ad97d89 Add search filters
* | 1625bc4 Add search index
|/
* 61382cb Add app skeleton
* db814b5 Initial commit

Rebasing onto main instead (as in the earlier section) keeps the branch a clean series of commits on top of the latest main, which makes the pull request easier to review. The cost is that you must not do it once other people have based work on your branch.

Conflicts: where the two really differ

A merge brings both branches together in one step, so you resolve each conflicting area once. A rebase replays your commits one at a time, so if several of your commits touch the same lines, you may resolve them repeatedly. I set up a conflict deliberately: main changed timeout=30 to timeout=60, while the feature branch has two commits, the first setting it to 45 and the second setting 50 and adding a retries line.

* e62c282 (HEAD -> main) Raise timeout to 60
| * 91af4b7 (feature/timeout) Tune timeout and add retries
| * cba3fc7 Tune timeout for slow API
|/
* 1b8f2a7 Initial commit

Merge: one conflict

$ git merge feature/timeout
Auto-merging config.txt
CONFLICT (content): Merge conflict in config.txt
Automatic merge failed; fix conflicts and then commit the result.

$ cat config.txt
<<<<<<< HEAD
timeout=60
=======
timeout=50
retries=3
>>>>>>> feature/timeout

$ git status --short
UU config.txt

I resolved it to timeout=60 plus retries=3, committed, and was done: one resolution, and the graph shows the join.

*   82da93a (HEAD -> main) Merge branch 'feature/timeout'
|\
| * 91af4b7 (feature/timeout) Tune timeout and add retries
| * cba3fc7 Tune timeout for slow API
* | e62c282 Raise timeout to 60
|/
* 1b8f2a7 Initial commit

Rebase: a conflict for each commit that collides

$ git rebase main
Auto-merging config.txt
CONFLICT (content): Merge conflict in config.txt
error: could not apply cba3fc7... Tune timeout for slow API
Could not apply cba3fc7... Tune timeout for slow API

$ cat config.txt
<<<<<<< HEAD
timeout=60
=======
timeout=45
>>>>>>> cba3fc7 (Tune timeout for slow API)

(I trimmed Git's hint: lines throughout.) Here HEAD is the new base, main, and the other side is the single commit being replayed. I resolved it to timeout=60, ran git add config.txt and git rebase --continue, and Git moved on to the second commit, which collided as well:

$ git rebase --continue
Auto-merging config.txt
CONFLICT (content): Merge conflict in config.txt
error: could not apply 91af4b7... Tune timeout and add retries
Could not apply 91af4b7... Tune timeout and add retries

$ cat config.txt
<<<<<<< HEAD
timeout=60
=======
timeout=50
retries=3
>>>>>>> 91af4b7 (Tune timeout and add retries)

Second resolution: timeout=60 plus retries=3, then git rebase --continue:

[detached HEAD 8fc3ae3] Tune timeout and add retries
 1 file changed, 1 insertion(+)
Successfully rebased and updated refs/heads/feature/timeout.

* 8fc3ae3 (HEAD -> feature/timeout) Tune timeout and add retries
* e62c282 (main) Raise timeout to 60
* 1b8f2a7 Initial commit

Two things to notice. First, the two conflicts: the merge asked once, the rebase asked twice. Second, the branch ended with one commit, not two. My first resolution (timeout=60) matched what main already had, so the first commit became empty and Git dropped it without a message. That is correct behavior, but it surprises people who expect every commit to survive.

Cutting down repeated conflicts: squash first

If your branch has several small commits that keep colliding, squash them into one before rebasing, so you resolve once. This does throw away the individual commit history, which is the trade-off:

git reset --soft $(git merge-base main feature/timeout)
git commit -m "Tune timeout and add retries"
git rebase main

* d3d35ff (HEAD -> feature/timeout) Tune timeout and add retries
| * e62c282 (main) Raise timeout to 60
|/
* 1b8f2a7 Initial commit
Auto-merging config.txt
CONFLICT (content): Merge conflict in config.txt
error: could not apply d3d35ff... Tune timeout and add retries

One commit, one conflict. For picking which commits to combine more precisely, use git rebase -i (covered in the rebase part of this Git series).

Bailing out of either one

git merge --abort
git rebase --abort

Both put the branch back as it was before you started. After git rebase --abort in my test the status was nothing to commit, working tree clean and the graph showed the original 91af4b7 and cba3fc7 commits again.

Rebase refuses to run on a dirty working tree

$ git rebase main
error: cannot rebase: You have unstaged changes.
error: Please commit or stash them.

$ git rebase --autostash main
Created autostash: 44ed3df
Applied autostash.
Successfully rebased and updated refs/heads/feature/search.

--autostash stashes your uncommitted changes, rebases, and reapplies them. If the reapply conflicts, Git keeps the stash for you. For the manual version, see the stash part of this series.

The golden rule: don't rewrite commits other people have

Rebase creates new commits to replace old ones. On your own local branch that is harmless. On a branch that a teammate has already pulled, it leaves their copy of the old commits stranded. I simulated that with a bare remote and two clones. Alice and Bob both have feature/search. Alice rebases it onto an updated main and tries to push:

$ git push
 ! [rejected]        feature/search -> feature/search (non-fast-forward)
error: failed to push some refs to '…'
hint: Updates were rejected because the tip of your current branch is behind

$ git push --force-with-lease
 + 871afc9...731f5a1 feature/search -> feature/search (forced update)

(I replaced the repository path with ….) The plain push is rejected because the rewritten branch is no longer a descendant of what is on the remote. --force-with-lease overwrites it. Bob still has the old commits and adds one of his own:

* 6db2161 (HEAD -> feature/search) Add search sorting
* 871afc9 (origin/feature/search) Add search filters
* 7ed4e8b Add search index
* db814b5 (origin/main, origin/HEAD, main) Initial commit

Now Bob runs a plain merge-style pull, and gets a conflict in a file he never touched:

$ git pull --no-rebase
Auto-merging search.txt
CONFLICT (add/add): Merge conflict in search.txt
Automatic merge failed; fix conflicts and then commit the result.

$ git status --short
M  README.md
AA search.txt

The AA means both sides added search.txt: Alice's rewritten commits created it, and so did Bob's old ones, as unrelated commits to Git. After git merge --abort, Bob can recover with git pull --rebase:

$ git pull --rebase
Successfully rebased and updated refs/heads/feature/search.

* 5474049 (HEAD -> feature/search) Add search sorting
* 731f5a1 (origin/feature/search) Add search filters
* 769bcce Add search index
* bf92bdd (origin/main, origin/HEAD) Update README
* db814b5 (main) Initial commit

Here Git recognized that Bob's two old commits were already upstream in rewritten form and dropped them, keeping only Add search sorting. That worked because Alice's rebase did not change the contents of her commits. If she had also edited or conflict-resolved them, the recovery would be harder. Do not rely on it as a plan.

Always --force-with-lease, never --force

In a second run, Alice rebased locally, then Bob pushed a new commit to the same branch before Alice pushed. Alice had not fetched his commit:

$ git push --force-with-lease
 ! [rejected]        feature/search -> feature/search (stale info)

$ git push --force
 + 811a4ba...3265a02 feature/search -> feature/search (forced update)

$ git log --oneline feature/search      # on the remote, afterwards
3265a02 Add search index
36bce11 Update README
d8f1998 Initial commit

The lease refused, because the remote had moved since Alice last looked ("stale info"). The plain force overwrote it, and Bob's commit Add search sorting is gone from the remote. The lease costs nothing, and it is the difference between an annoying rejection and lost work. The rebase part of the series covers pushing after a rebase in more depth.

Squash merge: one commit per branch

Many teams squash a branch into a single commit when merging a pull request. Locally that is git merge --squash:

$ git merge --squash feature/search
Automatic merge went well; stopped before committing as requested
Squash commit -- not updating HEAD

$ git commit -m "Add search (squashed)"

* ad97d89 (feature/search) Add search filters
* 1625bc4 Add search index
| * 902732e (HEAD -> main) Add search (squashed)
| * cb7fefb Update README
|/
* 61382cb Add app skeleton
* db814b5 Initial commit

The result on main is one new commit, and the feature branch is not connected to it in the graph. That has a practical consequence, because Git no longer knows the branch was merged:

$ git branch --merged main
* main

$ git branch -d feature/search
error: the branch 'feature/search' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/search'

Only delete such a branch with -D after checking that the squash commit contains everything. Also avoid continuing work on a branch after it has been squash-merged, since its old commits will conflict with the squashed copy. The GitHub documentation says the same: "Squash merging works best for short-lived branches."

GitHub's pull request button offers all three strategies from this article, as documented: create a merge commit (a --no-ff merge that keeps all the branch's commits), squash and merge, and rebase and merge. For rebase and merge, GitHub's page states that it "always updates the committer information and creates new commit SHAs", so commits on main will not match the SHAs on your local branch. I did not test GitHub itself.

Rebasing a branch that contains merges

A plain git rebase flattens merge commits. Here feature/cart contains a merge of a smaller branch (feature/cart-coupons), and main has moved on:

*   4892d20 (HEAD -> feature/cart) Merge coupons into cart
|\
| * b575b69 (feature/cart-coupons) Add coupon codes
* | c934647 Add cart total
|/
* 31aa099 Add cart list
* db814b5 Initial commit

$ git rebase main
Successfully rebased and updated refs/heads/feature/cart.
* ff2d7ef (HEAD -> feature/cart) Add coupon codes
* 6a3df45 Add cart total
* 5b818cf Add cart list
* c5906fe (main) Update README
* db814b5 Initial commit

The merge commit disappeared and the structure of the work was flattened. If you want to keep it, use --rebase-merges:

$ git rebase --rebase-merges main
Successfully rebased and updated refs/heads/feature/cart.

*   8a9845e (HEAD -> feature/cart) Merge coupons into cart
|\
| * 1dd0e01 Add coupon codes
* | 6a3df45 Add cart total
|/
* 5b818cf Add cart list
* c5906fe (main) Update README
* db814b5 Initial commit

Note that feature/cart-coupons itself still points at its old commit in both cases; a rebase moves only the branch you are on.

Undoing each one

A merge you have not pushed. Git saves the previous tip as ORIG_HEAD:

$ git reset --hard ORIG_HEAD
HEAD is now at cb7fefb Update README

A rebase you have not pushed. Same trick, and the old commits come back with their old SHAs:

before:        ad97d89 Add search filters / 1625bc4 Add search index
after rebase: 6976b4e Add search filters / f18a57b Add search index

$ git reset --hard ORIG_HEAD
HEAD is now at ad97d89 Add search filters

(The rebased SHAs differ from the earlier rebase example because this was a separate test run; the point is that they change.) ORIG_HEAD is overwritten by the next merge, reset or rebase, so if you have done anything since, use git reflog. The undo part of the series covers that.

A merge that is already pushed. You cannot rewrite shared history, so you add a commit that reverses it. A merge commit has two parents, so you must tell Git which side to keep with -m 1 (the first parent, normally main):

$ git revert -m 1 HEAD
[main 1b63300] Revert "Merge branch 'feature/search'"
 Date: Thu Jan 1 00:01:00 2026 +0000
 1 file changed, 2 deletions(-)
$ ls
README.md
app.txt

The feature's changes are gone from the working tree. Now the trap: when the fixed branch is ready and you merge it again, Git thinks it is already merged.

$ git merge feature/search
Already up to date.

The original merge still counts as having included those commits. To get the changes back, revert the revert:

$ git revert --no-edit 1b63300
[main f224762] Reapply "Merge branch 'feature/search'"
 Date: Thu Jan 1 00:02:00 2026 +0000
$ ls
README.md
app.txt
search.txt

Or merge a new branch that includes your fixes as new commits on top of the old ones. Either way, know about this behavior before the day you need it.

What git pull does: pick a default

git pull is a fetch followed by a merge or a rebase, and Git 2.43 will not pick for you when the branches have diverged:

$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
fatal: Need to specify how to reconcile divergent branches.

$ git pull --ff-only
fatal: Not possible to fast-forward, aborting.
$ git pull --rebase
Successfully rebased and updated refs/heads/main.
* 47f354b (HEAD -> main) Bob: add notes
* ddd4bcf (origin/main, origin/HEAD) Alice: add app
* db814b5 Initial commit

Set one default and stop thinking about it. pull.rebase true keeps your local, unpushed commits on top of the remote ones, which is safe because those are the only commits being rewritten. pull.ff only makes a diverged pull stop and ask, which is the most cautious. Use git config --global to apply either to every repository.

Which should you use?

Situation	Use	Why
Your own unpushed branch is behind `main`	Rebase	Clean history, nobody affected
A branch you pushed, only you use it	Rebase, then `--force-with-lease`	Safe if you are the only one; the lease checks it
A branch shared with teammates	Merge	Rewriting strands their copies
`main`, `develop`, release branches	Merge, never rebase	Everyone builds on them
Finished feature into `main`, you want context	Merge commit (`--no-ff`)	One visible unit per feature, easy `revert -m 1`
Finished feature, many noisy commits	Squash	One tidy commit per pull request
Finished feature, you want a straight line with every commit	Rebase and fast-forward	Linear history, each commit stays
You need to undo a pushed integration	`revert`	Never rewrite published history

A workflow that works for many teams, again as a recommendation: rebase locally while you work, open the pull request, let the team's chosen merge strategy (merge commit or squash) land it on main, and never rebase a branch after someone else has pulled it. What matters more than the choice is that everyone on the team uses the same one.

Common mistakes

Rebasing a branch other people have pulled. It strands their commits and creates confusing conflicts like the add/add above.
Usinggit push --force. Use --force-with-lease. In my test the plain force deleted a teammate's commit from the remote.
Rebasingmainonto a feature branch. The direction matters: rebase the feature onto main, never the other way around.
Panicking when commits seem to vanish after a rebase. They are still there; use ORIG_HEAD or git reflog.
Resolving the same conflict repeatedly. Squash first, or consider merging instead.
Deleting a squash-merged branch with-Dwithout checking. Git cannot tell it was merged.
Merging again afterrevert -m 1and getting "Already up to date". Revert the revert instead.
Ignoring thepulldefault. Set pull.rebase or pull.ff once.

Alternatives to both

git cherry-pick to copy specific commits without merging the whole branch (see the stash and cherry-pick part).
git rebase -i to reorder, edit and squash your commits before you share them.
git merge --squash when you want the changes but a single commit.

Sources

GitHub Docs: Pull request merges (merge commit, squash and merge, rebase and merge)

Originally published on DEV Talk.

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.

DEV Community: devTalk

Laravel .env Configuration: env() vs config() Explained

The flow in one line

A working example: adding your own setting

Real environment variables beat .env

Value types: what env() returns

Spaces need quotes

The config:cache trap

Environment names and extra env files

Catching wrong types: the typed getters

Keeping secrets out of git: encrypted env files

Common mistakes

Alternatives to a .env file

Related Dev Talk articles

Frequently asked questions

Can I use env() anywhere if I never run config:cache?

Why does my .env change not take effect?

What is the difference between .env and .env.example?

Is the encrypted env file safe to commit?

Sources

Palo Alto PAN-OS CVE-2026-0330: Panorama Root RCE Fix

The short version

What the advisory says

Why 6.1 and 8.6 at the same time?

Is "attackers can execute code as root" accurate?

Affected and fixed versions

Reduce exposure while you schedule the upgrade

Don't mix it up with CVE-2026-0322

A sensible order of operations

Common mistakes

Frequently asked questions

Does CVE-2026-0330 affect my PA-Series firewall?

Is it exploited in the wild?

Can an unauthenticated attacker use it?

Is there a workaround?

Related Dev Talk articles

Sources

Chrome Zero-Day CVE-2026-125350: Update and Check

The short version

What is confirmed

What "remote code execution" means here

Why a use-after-free bug is dangerous

Check your version in one minute

How to update

Other Chromium browsers and apps

If you can't patch right away

Common mistakes

Frequently asked questions

Is CVE-2026-125350 being exploited right now?

Do I need to do anything if Chrome updates itself?

Does it affect Firefox or Safari?

Did the attackers escape the sandbox?

How do I know if I was attacked?

Related Dev Talk articles

Sources

Malicious Claude Code Extension in Cursor: Check Your Machine

What is confirmed

Was Anthropic hacked?

What the malicious build does

Check whether you were affected

If you find something

Lessons for the rest of us

Common mistakes during cleanup

Related Dev Talk articles

Frequently asked questions

Does this affect the Claude Code CLI or the extension in VS Code?

Is it a remote access trojan?

Which version should I be on now?

Sources

10 Common API Design Mistakes

The ten at a glance

1. Returning 200 OK for errors

2. A different error format on every endpoint

3. Ignoring HTTP method semantics

4. Unbounded lists and offset pagination

5. Retries that create duplicates

6. Breaking changes with no warning

7. No object-level authorization

8. Exposing and accepting whole models

9. No rate limiting