DEV Community: devTalk

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

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

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

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

The short answer

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

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

What developers actually use

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

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

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

Pricing as of November 2026

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

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

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

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

Claude Code: working examples

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

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

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

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

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

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

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

GitHub Copilot CLI: working examples

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

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

GitHub Copilot CLI 1.0.105.

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

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

Cursor

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

Test all three on your own code

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

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

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

Which one should you choose?

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

Common mistakes

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

Alternatives

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

Frequently asked questions

Which is the cheapest?

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

Is Claude Code free?

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

Can I use more than one?

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

Which one is best for beginners?

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

Will my code be used for training?

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

Originally published on DEV Talk.

AI Agents for Laravel: Boost Setup and a Safe Workflow

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

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

What goes wrong without setup

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

Step 1: Install Laravel Boost (development only)

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

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

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

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

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

What the agent can do through Boost

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

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

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

Step 2: Use a workflow, not one big prompt

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

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

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

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

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

Step 3: Set guardrails

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

Common mistakes

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

Agents inside your app are a different thing

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

Frequently asked questions

Which coding agent works best with Laravel?

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

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

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

Is it safe to let an agent run commands?

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

Will it write my whole application?

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

Originally published on DEV Talk.

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

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

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

The short answer

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

What Docker does

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

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

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

hello from a container

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

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

What Kubernetes does

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

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

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

Do Kubernetes and Docker work together?

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

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

The middle step: Docker Compose

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

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

docker compose up -d

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

When to use which

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

Frequently asked questions

Is Kubernetes a replacement for Docker?

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

Do I need to learn Docker before Kubernetes?

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

Is Docker free?

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

What version of Kubernetes is current?

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

Can I run Kubernetes on my laptop?

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

Sources

Originally published on DEV Talk.

What Developers Use and Search in 2026: Survey Data

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

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

Where developers look for answers has changed

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

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

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

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

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

The languages and databases in daily use

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

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

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

What GitHub's own data adds

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

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

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

AI tools in practice

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

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

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

What this means if you build or write for developers

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

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

What these numbers do not tell you

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

Frequently asked questions

What is the most popular programming language in 2026?

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

Is Stack Overflow still relevant?

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

What database do developers use most?

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

Are AI agents replacing developers?

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

Originally published on DEV Talk.

10 Claude Code Commands Every Developer Should Know

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

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

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

The ten at a glance

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

1. /init: give Claude project knowledge

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

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

2. /memory: edit what Claude remembers

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

3. /clear: start clean

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

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

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

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

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

5. /context: see where the context goes

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

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

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

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

6. /plan: think before changing files

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

7. /rewind: undo to an earlier point

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

8. /resume: pick up where you left off

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

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

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

9. /permissions: decide what runs without asking

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

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

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

10. /usage: know what you are spending

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

Bonus: use Claude Code in scripts

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

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

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

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

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

Common mistakes

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

Frequently asked questions

How do I see all available commands?

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

What is the difference between /clear and /compact?

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

Do these commands work the same in an IDE?

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

Can I run slash commands in print mode?

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

Sources

Originally published on DEV Talk.

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

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

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

What Herd is, and where it runs

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

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

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

Create your first site

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

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

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

A project that lives somewhere else

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

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

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

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

HTTPS for a local site

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

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

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

PHP versions

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

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

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

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

Use the right PHP in the terminal

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

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

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

Databases

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

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

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

Other things worth knowing

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

Common problems

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

Herd or Sail?

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

Sources

Originally published on DEV Talk.

Laravel CORS Error with React or Vue: Causes and Fixes

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

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

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

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

Why you only see it in the browser

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

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

How Laravel handles CORS

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

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

To change anything, publish the file and edit it:

php artisan config:publish cors

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

Test the preflight without a browser

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

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

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

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

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

Cause 1: The path is not in `paths`

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

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

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

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

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

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

In my test, a preflight with that configuration returned:

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

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

Do not combine credentials with `'*'`

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

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

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

Cause 3: A request header is not allowed

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

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

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

Cause 4: The origin is not listed

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

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

Things that make it look like a CORS error

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

Sources

Originally published on DEV Talk.

MySQL Too Many Connections (Error 1040): Causes and Fixes

devTalk — Thu, 05 Nov 2026 02:06:38 +0000

Your site suddenly shows a database error, and the log says this:

ERROR 1040 (08004): Too many connections

MySQL accepts only a fixed number of simultaneous connections. Once that number is reached, the next client is refused until someone disconnects. Raising the number fixes the symptom in one command. Finding out why you reached it fixes the cause. This article shows both.

What the error means

The limit is the max_connections setting. Its default is 151, which I confirmed from the MySQL 8.0.46 server's own help output. Every open connection counts, whether it is running a query or sitting idle waiting for the next one. A PHP-FPM worker, a queue worker, a cron job, a database GUI left open on someone's laptop: each one holds a slot until it disconnects. MySQL also keeps one extra slot for administrators. A user with the CONNECTION_ADMIN or SUPER privilege can connect even when the limit has been reached, so you can still log in to investigate. Do not give that privilege to application accounts, or you lose this safety valve.

Reproduce it in two minutes

On a test server with max_connections=5 and an application user, I opened five connections that each ran SELECT SLEEP(40) and then tried a sixth:

$ mysql -uapp -ppw -e "select 1"
ERROR 1040 (08004): Too many connections

An admin account still got in, and showed what was using the slots:

mysql> show global status where Variable_name in
    -> ('Threads_connected','Max_used_connections','Connection_errors_max_connections');
Connection_errors_max_connections   1
Max_used_connections                6
Threads_connected                   6

Six connections for a limit of five: the five application connections plus the one reserved for the administrator.

Step 1: See who is connected

SHOW VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

SELECT user, COUNT(*) AS connections
FROM information_schema.processlist
GROUP BY user
ORDER BY connections DESC;

In my test, the grouped query returned app 5, root 1 and the internal event_scheduler 1. In your case, one account or one host will usually stand out. To see what each connection is doing, run SHOW FULL PROCESSLIST;, which is the same data with the query text.

What you see	What it usually means
Many connections in state `Sleep`	Clients opened a connection and are not using it: leaks, no connection reuse, or a pool bigger than needed
Many connections running the same slow query	One query is slow and requests are piling up behind it. More connections will not help.
Connections from a host you do not expect	A forgotten script, a staging server pointed at production, or a GUI left open
`Max_used_connections` equals `max_connections` + 1	You hit the limit at some point since the server started

Step 2: Raise the limit (the quick fix)

You can change it on the running server without a restart, using the admin account:

SET GLOBAL max_connections = 200;

In my test the application user could connect again immediately. This change is lost when MySQL restarts. In MySQL 8.0 you can make it permanent from SQL:

SET PERSIST max_connections = 300;

That wrote the value into mysqld-auto.cnf in the data directory in my test. The other option, which works on every version and is easier to review in version control, is the config file:

[mysqld]
max_connections = 300

Restart MySQL after editing the file, or use SET GLOBAL as well so you do not need a restart right now. On MariaDB the same variable and statements work, but SET PERSIST is a MySQL 8 feature.

Do not set a huge number "to be safe". Each connection uses memory for its buffers and a thread, and a very high limit lets a traffic spike or a leak overload the whole server instead of failing early. Raise it in steps, and watch memory and Max_used_connections. Also check that the operating system allows enough open files for the number you choose, or MySQL may lower it at startup.

Step 3: Fix why it happens

Applications that open connections and never close them

Long-running scripts, workers and loops that create a new database connection per task are the usual cause. Reuse one connection per process. In PHP, PDO connections close when the object is destroyed or the script ends, so a leak means the object is being kept alive, for example in a static property or a long-running worker.

Too many workers for the database

Count the maximum number of connections your application can open at once: PHP-FPM pm.max_children across all servers, plus queue workers, plus scheduled jobs, plus every other service. If that total is above max_connections, you will hit the limit under load by design. Either lower the worker counts or raise the limit with the memory to match.

Idle connections kept too long

wait_timeout decides how long MySQL keeps an idle connection open before closing it. The default is 28800 seconds, which is 8 hours (confirmed on the 8.0.46 server). Lowering it, for example to a few minutes, frees slots held by abandoned clients. Make sure your applications can reconnect, because a client that holds on to a connection the server has closed gets "MySQL server has gone away". I did not test that setting.

Slow queries that hold connections

If most connections run the same query, the problem is the query. Add the missing index, or fix it, before you add connections. More connections to an overloaded database usually make it slower.

One account taking everything

You can cap a single account so it cannot starve the others:

ALTER USER 'reports'@'%' WITH MAX_USER_CONNECTIONS 20;

The global default max_user_connections is 0, which means no per-account limit. I did not run the per-account limit in my test.

Connection pooling

If you really do need thousands of client connections, put a connection pooler or proxy in front of MySQL, such as ProxySQL, so many clients share fewer database connections. That is a bigger change than the steps above, so use it when raising the limit stops being sensible.

If you cannot even log in

If an administrator account is also locked out, it is probably because an application account or script is configured with admin privileges and used the spare slot. Connect as root through the local socket (sudo mysql on many Linux distributions), run SHOW PROCESSLIST;, and end the offending connections with KILL <id>;. Then fix the privileges.

Frequently asked questions

Is the limit per user or for the whole server?

max_connections is for the whole server. max_user_connections is the optional limit per account.

Why does Max_used_connections show one more than my limit?

Because of the extra connection reserved for administrators, as in the test above.

Will restarting MySQL fix it?

It clears the connections for a while, and the cause will fill them up again. Use it only as an emergency step, after you have looked at the process list.

Does this error appear in Laravel?

Yes. It shows up as a database connection exception carrying error code 1040 (SQLSTATE 08004, the same pair the mysql client printed above). Laravel is not special here: the cause is how many workers and processes connect at once.

Sources

Originally published on DEV Talk.

Laravel Queue Jobs Not Processing or Stuck: Causes and Fixes

devTalk — Wed, 04 Nov 2026 14:43:20 +0000

You dispatch a job, nothing happens, and there is no error. Or the job ran once, then ran again, or sits in the queue while the worker idles. "Queue not working" is one symptom with about a dozen causes, and most of them can be told apart in a few minutes if you check in the right order. This guide goes from the cheapest checks to the subtle ones, with the commands to confirm each.

Quick diagnosis: start here

Is the job really queued? If QUEUE_CONNECTION=sync, jobs run inline during the request and no worker is involved.
Is a worker running, for the right connection and queue name? Check ps aux | grep queue:work and compare its --queue value with the queue the job was dispatched to.
Where is the job right now? Waiting, delayed, reserved (running or lost), or failed. Each state has a different fix.
Is the worker running current code and config? Workers keep the application in memory.

Step 3 is where most guessing stops, so do it first.

Find out where the job is

On the Redis driver, a queue named default uses three keys. These come from the RedisQueue class:

Redis key	Type	Meaning
`queues:default`	list	Jobs waiting to be picked up
`queues:default:delayed`	sorted set	Jobs scheduled for later (`delay()`, retries with backoff)
`queues:default:reserved`	sorted set	Jobs a worker has taken and not finished or released

redis-cli llen queues:default
redis-cli zcard queues:default:delayed
redis-cli zcard queues:default:reserved
redis-cli keys 'queues:*'

If your app uses a Redis prefix, include it in the key names. The last command lists every queue that has data, which is how you spot a job sitting in a queue nobody listens to. On the database driver, the same information is in the jobs table: reserved_at is null for waiting jobs and set for reserved ones, and available_at in the future means delayed. Failed jobs are in failed_jobs (see the failed section below).

Cause 1: Nobody is working that queue

A worker only reads the queues it is told about. php artisan queue:work reads the default queue of the default connection. A job dispatched with onQueue('emails') goes to a different list. I tested this with the real RedisQueue class:

push job to 'emails'
worker on 'default' pops: NULL
redis keys: queues:emails:notify, queues:emails   |   llen queues:emails = 1

The job sits in queues:emails forever and nothing reports an error. The fix is to tell the worker which queues to read, in priority order:

php artisan queue:work redis --queue=emails,default

The --queue option takes a comma-separated list, and queues earlier in the list are processed first. The same applies to a different connection: if the job was dispatched to redis and the worker runs against database, they never meet. Look at the first argument of queue:work and at QUEUE_CONNECTION in the environment the web app uses.

Cause 2: No worker is running at all

This is the usual one after a server reboot, a deploy that rebuilt containers, or a crashed process. A worker is a long-running PHP process. It does not start by itself. In production, run it under a process manager so it restarts after a crash. A typical Supervisor program:

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

Adjust the path, user and connection. After editing:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl status

--max-time=3600 makes each worker exit after an hour and lets Supervisor start a fresh one, which keeps memory from growing forever. stopwaitsecs should be longer than your longest job, so a stop does not kill a job in the middle of its work. The output of supervisorctl status should say RUNNING. If it says FATAL or keeps restarting, read the log file named in the program section, since the worker is crashing at boot, typically on a bad .env or a missing PHP extension.

Cause 3: QUEUE_CONNECTION is sync, or points somewhere else

The default in the Laravel 13 application skeleton is QUEUE_CONNECTION=database in .env.example and 'default' => env('QUEUE_CONNECTION', 'database') in config/queue.php. With sync, the job runs immediately inside the request, so there is nothing to process later and a slow job slows the page. If you changed .env and nothing changed, you are probably serving a cached config:

php artisan config:show queue.default
php artisan config:clear

If you deploy with php artisan config:cache, the .env file is no longer read at runtime, so edits to it have no effect until you cache again. Also remember to restart the workers (next section).

Cause 4: The worker is running old code

A queue:work process boots the framework once and keeps it in memory. After a deploy, it keeps running the old job classes and the old config until it is restarted. This is the classic "I fixed the bug and the queue still fails" report. Add this to every deploy, after the new code is in place:

php artisan queue:restart

The command does not kill anything. It writes a timestamp to the cache under the key illuminate:queue:restart, and each worker checks that key between jobs and exits after finishing its current job. Your process manager then starts a new one. That design has two consequences worth knowing:

It needs a cache store that the CLI deploy command and the workers share. With the array cache driver, or a file cache on a different machine from the workers, the signal never arrives and nothing restarts. Use the database, Redis or Memcached store for this.
It needs a process manager to start the new worker. Without Supervisor or an equivalent, the workers exit and nothing replaces them. That turns "stale code" into "no worker at all".

During local development, php artisan queue:listen reloads the code for every job at the cost of speed. The Laravel 13 skeleton uses it in its composer dev script. Do not use it in production.

Cause 5: The queue is paused, or the app is in maintenance mode

The framework has queue:pause and queue:resume commands. A paused queue is not processed, and the pause state is stored in the cache under keys like illuminate:queue:paused:redis:default. In the framework source I read, pause() uses forever(), so a pause stays until someone resumes. If workers are running and healthy but a queue does not move, run:

php artisan queue:resume redis:default
# or everything:
php artisan queue:resume --all

Separately, a worker does not process jobs while the application is in maintenance mode (php artisan down) unless it was started with --force. If a deploy script runs down and then crashes before up, the queue stops with it. Check with php artisan up.

Cause 6: A delayed job that is not due yet

Jobs dispatched with delay() sit in the delayed set until their time arrives. Mixing this up with a stuck queue is common, especially because the queue size includes delayed jobs. I pushed a job with a 60 second delay:

later(60): pop = NULL   delayedSize = 1   size = 1

The worker sees nothing to do, while size() reports 1. Check zcard queues:default:delayed before assuming the worker is broken. Jobs that failed and are waiting for a retry with backoff are in the same state. Server clock drift between the web server and the worker machine produces a similar picture, so keep NTP running.

Cause 7: retry_after is shorter than the job runtime (jobs run twice)

This one looks like a stuck queue and a duplicate-job bug at the same time. When a worker takes a job, it moves into the reserved set with an expiry of retry_after seconds. If the job is still running when that time passes, the queue assumes the worker died and makes the job available again. A second worker picks it up while the first is still working. I reproduced it with retry_after set to 2 seconds:

worker 1 reserved the job:  attempts = 1   reservedSize = 1   (job "still running")
worker 2 pops right away:   NULL
worker 2 pops after 3s:     the same job, attempts = 2

The rule is that retry_after must be longer than the longest time a job can run, and the worker's --timeout (60 seconds by default) must be shorter than retry_after. The skeleton sets retry_after to 90 for the database, Redis and Beanstalkd connections through environment variables such as REDIS_QUEUE_RETRY_AFTER. A job that takes five minutes needs both raised:

php artisan queue:work redis --timeout=300
# config/queue.php, or the env var REDIS_QUEUE_RETRY_AFTER
'retry_after' => 360,

You can also set a per-job timeout on the job class with the $timeout property. The --timeout option is enforced through the pcntl extension: in the worker source, the timeout handler is only registered when pcntl is loaded. Without it, a hung job is never killed by the worker, so check php -m | grep pcntl for the CLI binary that runs your workers.

The effect of getting this wrong gets worse with --tries=1. When the job comes back after retry_after, its attempt count is 2, which exceeds the limit. In the source, the worker then marks it failed and raises MaxAttemptsExceededException with the message <JobClass> has been attempted too many times. That message in failed_jobs usually means a worker died or was killed mid-job, or retry_after was too short, not that your code threw it.

Cause 8: The job is stuck because of a worker that died

When a worker is killed during a job (out of memory, kill -9, a container stop, a timeout), nothing records that the job failed. The job stays in the reserved set until retry_after expires and is then retried. So "stuck" for exactly retry_after seconds is normal behaviour after a crash. If a job is stuck much longer than that:

Confirm that a worker is running at all, because expired reserved jobs are only moved back when some worker polls that queue (the Redis queue migrates expired jobs on each pop).
Look for out-of-memory kills in dmesg or the container runtime. The worker's --memory option defaults to 128 MB and makes the worker exit cleanly when it is exceeded. A kernel OOM kill is different and leaves no log line from Laravel.
Check the unique or overlap locks (next section).

Cause 9: A lock that was never released

Jobs that implement ShouldBeUnique and jobs with the WithoutOverlapping middleware use locks stored in the cache. If a worker dies while holding such a lock, new dispatches of the same job are silently skipped until the lock expires. The default is to hold a unique lock until the job finishes or fails, so set an expiry that matches the job (uniqueFor on unique jobs, expireAfter() on WithoutOverlapping). Since these locks live in the cache, php artisan cache:clear on a shared store also clears them, with the side effects of clearing everything else, so prefer removing the one key. This section follows the framework's documented behaviour. I did not reproduce lock expiry in a test.

Cause 10: The job is failing, not stuck

If the worker output shows jobs as FAIL, the job exists in the failed jobs store. The commands, from the framework source:

php artisan queue:failed                  # list failed jobs
php artisan queue:retry all               # retry everything
php artisan queue:retry 5d3b...           # retry one by ID
php artisan queue:retry --queue=emails    # retry one queue
php artisan queue:flush                   # delete all failed records
php artisan queue:prune-failed --hours=48 # delete failed records older than 48 hours

The exception column of each failed job holds the full message and stack trace, which is where the real answer usually is. The skeleton stores failed jobs with the database-uuids driver, so the IDs are UUIDs. If failed_jobs does not exist, run php artisan make:queue-failed-table followed by php artisan migrate, and if you are on the database driver, check that the jobs table exists too (php artisan make:queue-table).

Common reasons a job fails only on the worker: a missing environment variable because the worker was started without the right user or .env, a model deleted before the job ran (ModelNotFoundException when the serialized model is restored), and a job dispatched inside a transaction that had not committed yet. The last one is covered in Laravel queued notification runs before the transaction commits.

Cause 11: Jobs are queued but the dispatch never happens

If the queue is empty and the worker is healthy, the job might never have been pushed. Reasons include the code path not running, an exception thrown before dispatch(), Queue::fake() left active in a test environment, or dispatchAfterResponse() being used when you expected a normal push. A direct check is to dispatch from php artisan tinker and watch the store:

php artisan tinker
>>> App\Jobs\ProcessOrder::dispatch(1);
# then, in another shell:
redis-cli llen queues:default

If the length goes up, the push works and the problem is on the worker side. If it does not, the application is writing somewhere else (compare config('queue.default') and the Redis prefix between tinker and the web app).

Monitoring so you notice sooner

The queue:monitor command checks queue sizes and fires an event when a queue exceeds a threshold. Schedule it and attach a notification listener:

php artisan queue:monitor redis:default,redis:emails --max=100

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::command('queue:monitor redis:default,redis:emails --max=100')->everyMinute();

It dispatches a QueueBusy event when a queue grows past the limit, and you listen for that event to send a Slack message or email. Note that in Laravel 13 the event exposes $connectionName rather than $connection, as covered in the Laravel 12 to 13 upgrade guide. The command needs a working scheduler, so an unhealthy cron entry takes the alarm down with the queue. If you run Redis queues in production, Laravel Horizon adds a dashboard with throughput, wait times and failed jobs.

Checklist for a stuck queue

ps aux | grep "queue:work": is a worker running, with the connection and --queue list you expect?
php artisan config:show queue.default: is the app using the connection you think it is?
Count the waiting, delayed and reserved jobs (Redis keys above, or the jobs table).
php artisan queue:failed: read the latest exception.
php artisan queue:resume --all and php artisan up: rule out a pause and maintenance mode.
Compare retry_after, the worker --timeout and your longest job.
php artisan queue:restart after any deploy, and confirm the cache store is shared between the deploy command and the workers.
Read the worker log (Supervisor's stdout_logfile) for crashes at boot.

Sources

Originally published on DEV Talk.

PHP Allowed Memory Size Exhausted: Causes and Fixes

devTalk — Tue, 03 Nov 2026 15:38:30 +0000

The error looks like this, and it always stops the script on the spot:

PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 33554440 bytes) in /var/www/app/report.php on line 3

The quick fix is to raise memory_limit. The better fix is to find out why the script needs that much memory, because in most cases it is holding something it could have processed piece by piece. Here is how to read the message, raise the limit properly, and cut the memory use itself.

Reading the message

Allowed memory size of 33554432 bytes is your memory_limit in bytes. Divide by 1,048,576: this one is 32 MB.
tried to allocate 33554440 bytes is the single allocation that failed, not the total used. A big number here usually means one large array or string being created or grown. PHP arrays resize by doubling, so a loop that appends to an array fails at a request about the size of the array so far.
in ... on line N is where the limit was hit, which is not always where the memory was wasted. The line that fails is just the one that asked for memory when none was left. The real cause is often earlier.

A tiny example that fails with a 32 MB limit:

$a = [];
for ($i = 0; $i < 10000000; $i++) {
    $a[] = $i;
}

php -d memory_limit=32M a.php

That prints the exact error above, including the doubled allocation.

Step 1: Find the limit that actually applies

The CLI, PHP-FPM and Apache can each use a different php.ini, so the value you see in a terminal may not be the one your web request runs with.

php --ini                    # which php.ini the CLI loads
php -r 'echo ini_get("memory_limit");'
php-fpm8.3 -i | grep memory_limit    # FPM's value (binary name varies by distro)

On the machine I tested, the CLI php.ini set memory_limit to -1 (unlimited), while PHP's built-in default, checked with php -n, is 128M. That is a common reason for "it works from the command line but fails on the web": the CLI has no limit and the web server does.

Step 2: Raise it, in the right place

Where	How	Scope
`php.ini`	`memory_limit = 256M`	Everything using that ini file. Restart FPM or Apache after changing it.
Command line	`php -d memory_limit=512M script.php`	That one run
In the script	`ini_set('memory_limit', '256M');`	The current request or process
FPM pool file	`php_admin_value[memory_limit] = 256M`	One pool

ini_set() worked in my test: a script started with an 8 MB limit raised itself to 64 MB and then allocated a 30 MB string. Be aware that a value set with php_admin_value in the FPM pool configuration cannot be changed afterwards with ini_set(), according to the PHP manual, so if your ini_set seems to be ignored on the web, look at the pool file. I did not test FPM here.

Composer runs out of memory often and has its own switch:

COMPOSER_MEMORY_LIMIT=-1 composer update
# or
php -d memory_limit=-1 $(which composer) update

Avoid memory_limit = -1 for web requests. The limit is what stops one runaway request from taking down the whole server. Use a number, and size it from measurements.

Step 3: Use less memory

Raising the limit hides the problem until the data grows again. These are the usual patterns that use far more memory than needed. The numbers below are from PHP 8.3.6 on a 70 MB text file with 1.5 million lines:

Approach	Peak memory
`$lines = file('big.txt');`	216 MB (fails under a 64 MB limit)
`while (($line = fgets($h)) !== false)`	2 MB
Generator that yields one line at a time	2 MB

Note that the file is 70 MB but file() needs triple that, because every line becomes a separate PHP string with its own overhead. A generator keeps the code readable while holding one item at a time:

function lines(string $path): Generator
{
    $h = fopen($path, 'r');
    try {
        while (($line = fgets($h)) !== false) {
            yield $line;
        }
    } finally {
        fclose($h);
    }
}

foreach (lines('big.txt') as $line) {
    // process one line
}

The same shape applies to data that is generated rather than read. With 2 million small values, building an array with iterator_to_array() peaked at 126 MB, while looping over the generator directly peaked at 2 MB. If you only need to loop once, do not collect first.

Database results (Laravel)

The most common source in Laravel apps is Model::all() or ->get() on a large table, which hydrates every row into a model object at once. Process in batches instead:

// Fixed-size batches, safe when you update rows while looping
User::query()->chunkById(1000, function ($users) {
    foreach ($users as $user) {
        // ...
    }
});

// Same idea, one model at a time through a lazy collection
foreach (User::query()->lazyById(1000) as $user) {
    // ...
}

I did not run these against a database for this article. They are documented Eloquent methods. Prefer chunkById or lazyById over chunk when the loop changes the column you filter on, because chunk uses offsets and can skip rows. If you only need a few columns, select() them. Exporting a whole table to CSV belongs in a queued job that streams, not in a request.

Step 4: Find what is using the memory

If it is not obvious, log the numbers when the limit is hit. A shutdown function still runs after this fatal error, so it can report where things stood:

register_shutdown_function(function () {
    $e = error_get_last();
    if ($e && str_contains($e['message'], 'Allowed memory size')) {
        error_log(sprintf(
            'OOM peak=%.1f MB at %s:%d',
            memory_get_peak_usage(true) / 1048576,
            basename($e['file']),
            $e['line']
        ));
    }
});

In my test this printed peak=16.0 MB and the failing line for a script limited to 16 MB. For finding the cause, call memory_get_usage() before and after suspicious steps and see which one jumps. A profiler such as Xdebug or Blackfire gives a full picture when that is not enough, though I did not use one for this article.

Things worth checking first:

Queries without a limit, and results collected into an array "to process later".
file_get_contents() or file() on user uploads or exports.
Image processing: the decoded bitmap in memory is far larger than the file on disk, since its size follows the pixel dimensions, not the file size.
An infinite loop or runaway recursion that keeps adding data. If the usage grows forever whatever limit you set, this is it.
Long-running processes such as queue workers, where leaks accumulate across jobs. Laravel's queue:work has a --memory option (128 MB by default) that makes the worker exit and restart when it grows too large.

Sources

Originally published on DEV Talk.

Node.js 20 Is End of Life: How to Upgrade to Node 24

devTalk — Tue, 03 Nov 2026 02:36:01 +0000

Node.js 20 stopped receiving security fixes on 30 April 2026. If a server, container image or CI job still runs it, every new Node vulnerability from now on is one you carry yourself. The October 2026 security releases, for example, patched the 22.x, 24.x and 26.x lines, and Node 20 was not among them. This guide shows what changes between Node 20 and Node 24, the handful of things that actually break, how to find them in your code before you switch, and how to roll the upgrade out.

Which version should you move to?

Version	Status (end of October 2026)	Security support ends
Node 20	End of life	30 April 2026
Node 22	Maintenance LTS	30 April 2027
Node 24 "Krypton"	Maintenance LTS since 20 October 2026	30 April 2028
Node 26 "Lithium"	LTS since 28 October 2026	30 April 2029

Dates are from the Node.js release schedule (the nodejs/Release repository) and match endoflife.date. Node 24 is a solid target for an existing application: it has been an LTS line since October 2025, so tools and libraries have had time to add support. Node 26 has just entered LTS and gives you the longest support window, so it is a reasonable choice for new projects, as long as your dependencies (especially native ones) support it. This article is about 20 to 24, and it notes where Node 26 differs.

What changes between Node 20 and Node 24

I installed Node 20.20.2, 24.22.2 and 26.13.0 side by side and read these values from process.versions:

	Node 20.20.2	Node 24.22.2	Node 26.13.0
V8	11.3	13.6	14.6
OpenSSL	3.0.19	3.5.9	3.5.9
Undici (`fetch`)	6.24	7.30	8.12
Native module ABI (`process.versions.modules`)	115	137	147

The Node 24 release notes add npm 11 (Node 20 ships npm 10), and these new capabilities, which I confirmed are missing in Node 20 and present in 24:

URLPattern is a global (typeof URLPattern is undefined in 20 and function in 24).
Float16Array, RegExp.escape() and Error.isError() exist in 24 and not in 20.
The permission model flag is now --permission.
AsyncLocalStorage uses a more efficient implementation by default.

One thing that is not new: require() of an ES module already works on Node 20.20.2. I tested it, and it returned the module without a flag. If you were avoiding that on Node 20, check your own version; on current 20.x releases it works.

What actually breaks

Most applications need no code changes. The cases below are the ones I could reproduce, each tested on Node 20 and Node 24.

Code	Node 20	Node 24	Fix
`tls.createSecurePair()`	Function exists	Removed (`undefined`, calling it throws)	Use `tls.TLSSocket`
`dirent.path` from `readdir(..., {withFileTypes: true})`	String	Removed (`undefined`)	Use `dirent.parentPath`
`--experimental-permission` flag	Works	"bad option", the process will not start	Use `--permission`
`url.parse()`	Silent	Runtime deprecation warning DEP0169	Use `new URL()`
`fs.F_OK`, `R_OK`, `W_OK`, `X_OK`	Silent	Warning DEP0176 (still works)	Use `fs.constants.F_OK` etc.
`spawn()` / `execFile()` with an args array and `shell: true`	Silent	Warning DEP0190	Drop `shell: true`, or build the command string yourself

The first three can stop your app or script. The rest only print warnings today but are on the road to removal, and Node 26 shows how that ends: in Node 26.13.0, fs.F_OK is already undefined, so code reading it no longer works at all. The Node 24 release notes list other removals and deprecations, such as SlowBuffer, Zlib classes used without new, and 32-bit s390 and ppc support, but those are rare in application code. If you build Node from source, the release notes also raise the minimum macOS to 13.5 and require ClangCL on Windows.

The fixes in code

// url.parse() -> WHATWG URL
const u = new URL(req.url, 'http://localhost');
u.hostname; u.port; u.pathname; u.searchParams.get('y');

// dirent.path -> dirent.parentPath
const full = require('node:path').join(entry.parentPath, entry.name);

// fs.F_OK -> fs.constants.F_OK
fs.access(file, fs.constants.F_OK, cb);

// spawn without shell: arguments are passed safely, no quoting needed
require('node:child_process').spawnSync('echo', ['hi']);

One difference to watch with url.parse(). It can return the query as an object when you pass true as the second argument, while new URL() gives you searchParams instead. Replace those lines by hand rather than with a search and replace.

Find the problems before you switch

1. Search the code

grep -rnE "url\.parse\(|\.createSecurePair|fs\.(F_OK|R_OK|W_OK|X_OK)|\{ *(F_OK|R_OK|W_OK|X_OK)|new Buffer\(|\bSlowBuffer\b|experimental-permission|\b(dirent|entry|ent|e)\.path\b|shell: *true" \
  src scripts package.json Dockerfile .github --include=*.js --include=*.mjs --include=*.cjs --include=*.ts --include=package.json --include=Dockerfile --include=*.yml

I ran this against a sample file and it matched each old usage and skipped the modern ones such as fs.constants.F_OK and parentPath. It will also report false positives, like a variable named e.path that has nothing to do with fs, so read each hit. Your dependencies can also trigger these warnings, which the next step covers.

2. Run your tests with deprecations turned into errors

NODE_OPTIONS=--throw-deprecation npm test

With --throw-deprecation, a deprecated API throws instead of warning, so the first one fails the run. I confirmed the process exits with code 1. To find where a warning comes from, whether in your code or in node_modules, use:

node --trace-deprecation app.js

This prints the stack for each deprecation warning. For stricter checks, --pending-deprecation turns on extra deprecation warnings, such as the one for new Buffer() (DEP0005), which I saw with that flag.

3. Rebuild native dependencies

Packages with compiled addons, such as image, database or hashing libraries, are built for one ABI version. Node 20 is ABI 115 and Node 24 is 137, so the old binaries will not load. Start from a clean install under the new version:

rm -rf node_modules
npm ci
npm rebuild    # only needed if an addon did not install a prebuilt binary for Node 24

If an addon fails to build or load, check that package's release notes for Node 24 support and update it. Do the same for your build tools (Vite, webpack, test runners): each documents the Node versions it supports.

Roll it out

Local and server

# nvm
nvm install 24
nvm alias default 24
node -v

# fnm
fnm install 24 && fnm default 24

# pin it for the project
echo "24" > .nvmrc

On Debian or Ubuntu servers installed through NodeSource, switch the repository to the Node 24 setup script and reinstall the package. Restart every long-running process afterwards, because a running process keeps using the Node binary it started with. Check the version a running service really uses, not just the one on your shell's PATH.

package.json

{
  "engines": {
    "node": ">=24"
  }
}

With engines set, npm warns when someone runs the project on an older Node. Add engine-strict=true to .npmrc if you want it to refuse instead.

Docker

FROM node:24-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

Change the tag in every Dockerfile, including build stages, and rebuild without cache so npm ci compiles native modules against the new Node.

CI

# GitHub Actions
- uses: actions/setup-node@v4
  with:
    node-version: 24

Use the current major version of the action. Update any test matrix that still lists 20, and keep 22 and 24 in the matrix while you migrate.

A safe order of work

Run the grep and the --throw-deprecation test run on Node 20 itself to see what you will hit, then fix the code. All the fixes above work on Node 20 too, so you can ship them first.
Switch CI to Node 24 and get the test suite green.
Deploy to staging with the new Node and watch logs for deprecation warnings and native module errors.
Roll production forward one service or one instance group at a time, so you can roll back by redeploying the old image.

Frequently asked questions

Is Node.js 20 still safe to use?

No. It reached end of life on 30 April 2026, so it no longer receives security fixes. Vulnerabilities found since then are not patched in the 20.x line.

Should I upgrade to Node 24 or Node 26?

Either is supported. Node 24 is the safer choice for an existing app because the ecosystem has had a year with it. Node 26 became LTS on 28 October 2026 and is supported until 30 April 2029, so consider it for new projects after checking that your native dependencies support it.

Can I skip from Node 20 straight to 24?

Yes. You do not have to install 22 first, but the removals and deprecations of both releases apply at once, which is why it helps to run the checks above on Node 20 first.

Will my npm packages work on Node 24?

Pure JavaScript packages usually do. Packages with native addons must be reinstalled or rebuilt for the new ABI, and some need a newer version.

What happens to Node 24 after October 2026?

It is in Maintenance LTS: it still gets critical fixes and security updates, but not new features, until 30 April 2028.

Sources

Originally published on DEV Talk.

Upgrade MySQL 8.0 to 8.4: What Breaks and How to Check

devTalk — Mon, 02 Nov 2026 15:49:50 +0000

MySQL 8.0 reached end of life in April 2026, which means no more security fixes from Oracle for the community edition. The supported target is MySQL 8.4, the current long-term support (LTS) release. The move is a direct in-place upgrade, but 8.4 removed a number of things that 8.0 still accepted. Most of them fail quietly until the day a user cannot log in or the server refuses to start. This guide lists what breaks, gives a query or command for finding each one in your own system, and walks through the upgrade.

The short version

You can upgrade directly from MySQL 8.0 to 8.4 (the manual's example path is 8.0.37 to 8.4.x). An in-place upgrade is supported. If you are still on 5.7, go to 8.0 first.
Run MySQL Shell's upgrade checker against the server before you do anything else.
The usual breakages are accounts that use mysql_native_password, removed settings in my.cnf, old replication commands in scripts, and changed InnoDB defaults.
There is no mysql_upgrade step. The 8.4 server upgrades the data dictionary and system tables itself when it starts.

Step 1: run the upgrade checker

MySQL's own checker finds many of the problems below automatically. It ships with MySQL Shell, so use the 8.4 version of the shell, because the checker can only target versions up to the shell's own release number:

mysqlsh -- util checkForServerUpgrade root@localhost:3306 \
  --target-version=8.4.0 --output-format=JSON --config-path=/etc/mysql/my.cnf

Pass --config-path, or the checks that read your configuration file will fail. The account needs the RELOAD, PROCESS and SELECT privileges. Relevant checks include removedSysVars, removedFunctions, pluginUsage and authMethodUsage. The sections below show how to look for the same things by hand, which is useful when you want to see exactly what is affected.

What breaks, and how to find it

1. Accounts that use mysql_native_password

In 8.4 the mysql_native_password plugin is still present but disabled by default. Release note wording: it "can be enabled by starting MySQL with the new --mysql-native-password=ON server option, or by adding mysql_native_password=ON to the [mysqld] section". Any account that still uses it cannot log in until you change the account or turn the plugin back on. Find them:

SELECT user, host, plugin
FROM mysql.user
WHERE plugin = 'mysql_native_password';

On my test server, an account created with IDENTIFIED WITH mysql_native_password appeared here, and the system accounts did not. Fix each one before the upgrade by moving it to the default plugin. You must supply the password again, because the stored hash cannot be converted:

ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'the-password';

I ran this on MySQL 8.0.46 and then connected from PHP 8.3 (PDO MySQL) with the same credentials, and the connection worked. A PHP app or Laravel's mysql connection needs no other change for this. If you cannot change an account yet, such as one used by an old client library, add mysql_native_password=ON under [mysqld] as a temporary measure and plan to remove it, because the plugin is deprecated.

2. Settings in my.cnf that no longer exist

Removed options cause an error at startup rather than being ignored. Search your config and any systemd or Docker arguments for these:

grep -rniE 'default[-_]authentication[-_]plugin|expire[-_]logs[-_]days|skip[-_]ssl|^ *ssl *=|have_ssl|skip[-_]host[-_]cache|innodb *=|master[-_]info|relay[-_]log[-_]info|transaction[-_]write[-_]set' /etc/mysql /etc/my.cnf* 2>/dev/null

Removed	Use instead
`default_authentication_plugin`	`authentication_policy`
`expire_logs_days`	`binlog_expire_logs_seconds`
`--ssl`, `--skip-ssl`, `--admin-ssl`, `have_ssl`, `have_openssl`	`--tls-version`, `--admin-tls-version`
`--skip-host-cache`	`--host-cache-size=0`
`--innodb`, `--skip-innodb`	Nothing; InnoDB is always on
`--master-info-repository`, `--relay-log-info-repository`, `--master-info-file`, `--relay-log-info-file`, `transaction_write_set_extraction`	Remove them

This is not the full list; the release notes for 8.4.0 have the rest. The expire_logs_days removal date is worded inconsistently in the manual, but the 8.4 manual states it is removed and gives binlog_expire_logs_seconds as the replacement.

3. Old replication commands in scripts and monitoring

The "master/slave" statements are gone in 8.4. Anything that runs them, such as failover scripts, cron jobs, backup tooling and monitoring queries, fails with a syntax error:

Removed in 8.4	Replacement
`START SLAVE` / `STOP SLAVE`	`START REPLICA` / `STOP REPLICA`
`SHOW SLAVE STATUS`	`SHOW REPLICA STATUS`
`SHOW SLAVE HOSTS`	`SHOW REPLICAS`
`RESET SLAVE`	`RESET REPLICA`
`CHANGE MASTER TO ... MASTER_HOST ...`	`CHANGE REPLICATION SOURCE TO ... SOURCE_HOST ...`
`SHOW MASTER STATUS`	`SHOW BINARY LOG STATUS`
`RESET MASTER`	`RESET BINARY LOG AND GTIDS`
`PURGE MASTER LOGS`, `SHOW MASTER LOGS`	`PURGE BINARY LOGS`, `SHOW BINARY LOGS`

The options inside these statements are renamed as well, so MASTER_USER becomes SOURCE_USER and MASTER_LOG_FILE becomes SOURCE_LOG_FILE. The status counters Com_show_slave_status and Com_change_master are also removed (replaced by Com_show_replica_status and Com_change_replication_source), which matters if a dashboard reads them. Search your tooling:

grep -rniE 'start slave|stop slave|show slave|reset slave|change master|show master|reset master|purge master|master_(host|user|password|log_file|log_pos|auto_position)' /opt /usr/local/bin /etc/cron* 2>/dev/null

4. FLOAT or DOUBLE columns with AUTO_INCREMENT

8.4 no longer allows AUTO_INCREMENT on FLOAT or DOUBLE columns. The release notes say the upgrade requires altering such tables first. Find them:

SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE extra LIKE '%auto_increment%'
  AND data_type IN ('float', 'double');

On my test server this returned the one table I had created with id FLOAT AUTO_INCREMENT. Change those columns to an integer type before upgrading.

5. Foreign keys that point at non-unique columns

A foreign key that references a non-unique or partial key is nonstandard. In 8.4 the new setting restrict_fk_on_non_standard_key is ON by default, so creating one is rejected. The manual says upgrades from 8.0 are still supported when such keys exist, and the server logs warnings naming them. The practical risk is later: a CREATE TABLE or ALTER TABLE in your migrations that adds this kind of key will fail. Find existing ones with this query, which compares each foreign key's referenced columns with the unique indexes on the parent table:

WITH fk AS (
  SELECT CONSTRAINT_SCHEMA AS fk_schema, TABLE_NAME AS fk_table, CONSTRAINT_NAME AS fk_name,
         REFERENCED_TABLE_SCHEMA AS ref_schema, REFERENCED_TABLE_NAME AS ref_table,
         GROUP_CONCAT(REFERENCED_COLUMN_NAME ORDER BY ORDINAL_POSITION) AS ref_cols
  FROM information_schema.KEY_COLUMN_USAGE
  WHERE REFERENCED_TABLE_NAME IS NOT NULL
  GROUP BY CONSTRAINT_SCHEMA, TABLE_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_SCHEMA, REFERENCED_TABLE_NAME
), uq AS (
  SELECT TABLE_SCHEMA AS t_schema, TABLE_NAME AS t_table,
         GROUP_CONCAT(COLUMN_NAME ORDER BY SEQ_IN_INDEX) AS cols
  FROM information_schema.STATISTICS
  WHERE NON_UNIQUE = 0
  GROUP BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME
)
SELECT fk.fk_schema, fk.fk_table, fk.fk_name, fk.ref_table, fk.ref_cols
FROM fk
LEFT JOIN uq ON uq.t_schema = fk.ref_schema AND uq.t_table = fk.ref_table AND uq.cols = fk.ref_cols
WHERE uq.cols IS NULL;

On my test server it flagged a foreign key pointing at a non-unique index and another pointing at only the first column of a two-column unique index. A foreign key to a primary key, and one to the full two-column unique index, were not flagged. Fix flagged keys by pointing them at a unique key, or set restrict_fk_on_non_standard_key=OFF if you must keep them.

6. Changed InnoDB defaults

If you never set these in my.cnf, 8.4 behaves differently from 8.0 without any error. These come from the 8.4 manual's table of differing defaults. The "8.0 value" column is what I read from a running MySQL 8.0.46 server, and it matched the manual:

Variable	8.0 default	8.4 default
`innodb_adaptive_hash_index`	ON	OFF
`innodb_change_buffering`	all	none
`innodb_flush_method` (Linux)	fsync	O_DIRECT if supported, otherwise fsync
`innodb_io_capacity`	200	10000
`innodb_log_buffer_size`	16 MiB	64 MiB
`innodb_purge_threads`	4	1 if 16 or fewer logical CPUs, otherwise 4
`temptable_max_ram`	1 GiB	3% of RAM, within 1 to 4 GiB
`temptable_max_mmap`	1 GiB	0 (off)

The manual lists more (for example innodb_buffer_pool_instances, innodb_doublewrite_files and innodb_page_cleaners). Before upgrading, record what your server runs today, then compare after:

SELECT @@innodb_adaptive_hash_index, @@innodb_change_buffering, @@innodb_flush_method,
       @@innodb_io_capacity, @@innodb_log_buffer_size, @@innodb_purge_threads,
       @@temptable_max_ram, @@temptable_max_mmap;

If a workload depended on the old behaviour, such as the adaptive hash index for read-heavy lookups, set the value explicitly in my.cnf rather than relying on a default. Measure with your own workload instead of assuming either direction is faster.

7. Other removals worth a search

mysql_upgrade is removed. Scripts or Ansible roles that call it will fail. The server does that work at startup.
mysqlpump is removed, along with lz4_decompress and zlib_decompress. Use mysqldump or MySQL Shell's dump utilities.
FLUSH HOSTS is removed. Use TRUNCATE TABLE performance_schema.host_cache or mysqladmin flush-hosts.
LOCK TABLES ... LOW_PRIORITY WRITE is now a syntax error.
TheSET_USER_IDprivilege is removed. Grants that mention it fail; use SET_ANY_DEFINER and ALLOW_NONEXISTENT_DEFINER.
Keyring and FIDO plugins such as keyring_file, keyring_encrypted_file, keyring_oci and authentication_fido are removed in favour of the component_keyring_* components and authentication_webauthn. If you use encrypted tablespaces, read the keyring notes before upgrading.
Weak TLS ciphers are no longer supported in ssl_cipher and related settings.

Step 2: the in-place upgrade

The manual's procedure for package or binary installs, with my additions marked:

Back up first (my addition; the manual's in-place steps do not include it). Take a logical dump or a physical backup and confirm you can restore it.
If you use InnoDB XA transactions, run XA RECOVER; and commit or roll back anything it lists.
If you normally run with innodb_fast_shutdown=2, switch to a fast or slow shutdown:SET GLOBAL innodb_fast_shutdown = 0; -- slow shutdown (1 = fast)
Shut the server down cleanly: mysqladmin -u root -p shutdown.
Install the 8.4 packages or binaries.
Start MySQL 8.4 on the existing data directory. If you have encrypted InnoDB tablespaces, load the keyring with --early-plugin-load.

On first start the server upgrades the data dictionary, the mysql system database, and the Performance Schema, INFORMATION_SCHEMA and sys schemas. The manual says that if the dictionary step fails, the server reverts its changes, and you should start the old server again, fix the cause and retry. Read the error log during the first start (my addition), and do not put the service back into rotation until it has finished.

After the upgrade

Confirm the version: SELECT VERSION();
Re-run your account query and a connection from each application, including read replicas, cron jobs and reporting tools.
Check replication with SHOW REPLICA STATUS, using the new statement name.
Compare the variables you recorded earlier.
Time zone tables are not upgraded by the process. If you load them with mysql_tzinfo_to_sql, reload them as described in the time zone section of the manual.

Rollback

Plan to roll back by restoring your backup. The manual has a separate "Downgrading MySQL" section, which I did not review, so read it before relying on any downgrade path. Test the whole procedure on a copy of production data first, with the same config file.

Frequently asked questions

Can I upgrade from MySQL 8.0 directly to 8.4?

Yes. The manual lists "8.0.37 to 8.4.x LTS" as a supported path, with in-place upgrade, logical dump and load, or replication. From 5.7 you must go through 8.0 first.

Do I still need to run mysql_upgrade?

No. The utility was removed in 8.4.0. The server upgrades the data dictionary and system tables when it starts.

Will my Laravel or PHP app work with MySQL 8.4?

Generally yes, as long as the database user does not use mysql_native_password. I connected from PHP 8.3 with PDO MySQL to a caching_sha2_password account on 8.0 successfully. Check your migrations too, since a foreign key to a non-unique column will now be rejected.

Is MySQL 8.0 still safe to run?

Not for new deployments. It reached end of life in April 2026, so new vulnerabilities will not be patched in the community edition.

What about managed services like RDS or Aurora?

Their upgrade process and support dates are set by the provider. The incompatibilities in this article still apply to your accounts, configuration and SQL, so follow the provider's upgrade documentation as well.

Sources

Originally published on DEV Talk.

DEV Community: devTalk

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

The short answer

What developers actually use

Pricing as of November 2026

Claude Code: working examples

GitHub Copilot CLI: working examples

Cursor

Test all three on your own code

Which one should you choose?

Common mistakes

Alternatives

Related Dev Talk articles and tools

Frequently asked questions

Which is the cheapest?

Is Claude Code free?

Can I use more than one?

Which one is best for beginners?

Will my code be used for training?

AI Agents for Laravel: Boost Setup and a Safe Workflow

What goes wrong without setup

Step 1: Install Laravel Boost (development only)

What the agent can do through Boost

Step 2: Use a workflow, not one big prompt

Step 3: Set guardrails

Common mistakes

Agents inside your app are a different thing

Frequently asked questions

Which coding agent works best with Laravel?

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

Is it safe to let an agent run commands?

Will it write my whole application?

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

The short answer

What Docker does

What Kubernetes does

Do Kubernetes and Docker work together?

The middle step: Docker Compose

When to use which

Frequently asked questions

Is Kubernetes a replacement for Docker?

Do I need to learn Docker before Kubernetes?

Is Docker free?

What version of Kubernetes is current?

Can I run Kubernetes on my laptop?

Sources

What Developers Use and Search in 2026: Survey Data

Where developers look for answers has changed

The languages and databases in daily use

What GitHub's own data adds

AI tools in practice

What this means if you build or write for developers

What these numbers do not tell you

Frequently asked questions

What is the most popular programming language in 2026?

Is Stack Overflow still relevant?

What database do developers use most?

Are AI agents replacing developers?

10 Claude Code Commands Every Developer Should Know

The ten at a glance

1. /init: give Claude project knowledge

2. /memory: edit what Claude remembers

3. /clear: start clean

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

5. /context: see where the context goes

6. /plan: think before changing files

7. /rewind: undo to an earlier point

8. /resume: pick up where you left off

9. /permissions: decide what runs without asking

10. /usage: know what you are spending

Bonus: use Claude Code in scripts

Common mistakes

Frequently asked questions

How do I see all available commands?

What is the difference between /clear and /compact?

Do these commands work the same in an IDE?

Can I run slash commands in print mode?

Sources

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

What Herd is, and where it runs

Cause 1: The path is not in `paths`

Do not combine credentials with `'*'`