Mago 1.0 Lands — A Rust-Powered PHP Toolchain Just Made composer require Embarrassed

For ten years the PHP toolchain has been a polite but slow committee meeting: PHP-CS-Fixer for formatting, PHPStan or Psalm for static analysis, PHP_CodeSniffer for linting — three separate processes, three configurations, three CI jobs, three pull-request comment bots. On May 2, 2026, carthage-software shipped Mago 1.0.0, and the committee has been replaced by a single 25 MB binary, written in Rust, that does all three in roughly the time PHPStan needs to warm up.

The numbers people are sharing on X this weekend are blunt. On a 250k-line Laravel monolith that was the canonical "PHPStan takes 90 seconds" case study, Mago analyzes the same tree in around 8 seconds with comparable rule coverage, and formats the entire repository in under 2 seconds. Memory peaks well below 1 GB. Because Mago is a single static binary with no PHP runtime dependency, it drops cleanly into Docker images, GitHub Actions, and pre-commit hooks without an autoloader, vendor directory, or PHP version mismatch in sight.

1. Why Rust, and Why Now

Mago is the first widely-adopted PHP tool whose authors decided that the bottleneck was not the language but the host. PHP is wonderful at running PHP applications and not so wonderful at parsing 500,000 lines of someone else's PHP every CI run. By moving the AST, type inference, and rule engine into Rust, Mago gets multi-core parallelism, zero-cost abstractions, and instantaneous startup. The same insight that produced Biome (JS), Ruff (Python), and Oxlint is now PHP's.

2. What Actually Changed in 1.0

The 1.0 milestone freezes the on-disk config format (mago.toml), guarantees rule-id stability so your PR comments don't churn, and ships a documented plugin API. There's a real LSP server, not a wrapped CLI, so PhpStorm and VS Code give sub-100 ms diagnostics. The formatter is opinionated à la gofmt: almost no flags, no "company style guide" debates. Static analysis covers the PHPStan level 8/9 territory plus a handful of Mago-specific lints around generics and template inference that PHPStan still gets wrong on union types.

3. What This Means for Your Database / Backend Stack

If you maintain a Laravel, Symfony, or vanilla PHP project that touches MySQL or PostgreSQL through PDO, the immediate win is enabling Mago's SQL string lint, which flags raw concatenation into query strings (the same class of bug that just took down LiteLLM — see today's security story). Combined with a strict declare(strict_types=1) rollout that Mago can scaffold automatically, most teams are seeing a measurable drop in "something accidentally injected" defects within the first week.

4. The CI Math

If your monorepo runs CS-Fixer + PHPStan + PHPCS in series and burns ~3 minutes per push, replacing all three with Mago tends to land at ~20 seconds. On a team pushing 60 PRs a day, that is ~3 developer-hours reclaimed per day. The cost is a single binary in your tools/ folder.

My Take

I've been a PHPStan loyalist for years and I'm switching this week. The lesson here is bigger than PHP: any time your language ecosystem's core dev tools are still written in the host language — and Python, Ruby, and PHP all were — that's an arbitrage opportunity for someone with a Rust compiler and a weekend. PHP just got 10x faster CI, the floor on code quality just rose, and the next argument in your team's code review is going to stop being "why didn't the analyzer catch this?" and start being "why didn't we run it as a save-action?"