PHPStan: Static Analysis for PHP Without Running the Code

The gap PHPStan fills in a PHP project

PHP is interpreted, so a typo in a method name or a null passed where a string is required surfaces when that line executes, which in production may be after deployment and under a specific request. PHPStan reads the source instead. The README states the tool "focuses on finding errors in your code without actually running it" and that it "catches whole classes of bugs even before you write tests for the code." The target audience is PHP teams that already run a test suite but want a second, cheaper layer: tests cover the paths you thought to write, while static analysis covers the paths you did not. It is also useful in code review, because a reported type mismatch is a concrete line to discuss rather than a style preference. The repository is a PHP project under the MIT licence, with the default branch named 2.3.x and the latest release listed as 2.2.14 from 2026-09-12. The last push to the repository was on 2026-09-21.

How the analyzer reads your code and where the config lives

PHPStan needs to know which files to inspect and at what strictness. That is what the configuration file is for, and the config format is Neon, which is why "phpstan neon" is a common search. A config declares the paths to analyze and the level. The levels are numbered and the documentation on phpstan.org describes them as increasing in strictness: a low level reports obvious problems such as unknown classes and unknown functions, and higher levels add checks about types, nullability and dead code. Raising the level is not a rewrite; it is a change to one key, after which the analyzer reports more. The analyzer resolves types from your code and from PHPDoc annotations, so the PHPDoc Types page in the documentation is the reference for describing array shapes, generics and union types that PHP itself cannot express. For a codebase with many existing errors, the baseline is the escape hatch: it records the current errors in a file so that only new errors fail the run, letting a team adopt the tool without fixing everything first.

Installing PHPStan and running it the first time

The README does not carry installation steps of its own. It points to the Getting Started page on phpstan.org for the user guide, and the package is distributed through Composer under the name phpstan/phpstan, which the README references through its Packagist badge. The documentation also lists a Config Reference page for the configuration keys and a PHPDoc Basics page for annotations. Because the repository README gives no command line and no example config file, this article does not print one; copying a command from anywhere other than the project's own documentation risks inventing a flag or a key that does not exist. The practical path is to open the Getting Started page, follow its install instructions for your project, and then read the Config Reference before writing the configuration file. The one thing worth knowing up front is that the analyzer is driven by a configuration file, conventionally a Neon file, that names the paths to analyze and the level of strictness. If the first run on an existing codebase produces more errors than you can fix now, the baseline mechanism described in the documentation is how teams adopt the tool incrementally rather than all at once.

Where PHPStan stops being the right tool

PHPStan does not execute your code, and that single design decision defines its limits. It cannot tell you that a query returns the wrong rows, that a queue message is malformed, or that two services disagree about a date format at runtime. Those are integration and data problems, and a test suite or a staging environment is the instrument for them. The analyzer also depends on the type information available to it. Dynamically constructed calls, magic methods and heavy use of string-based dispatch reduce what it can prove, and the practical answer is usually PHPDoc annotations, which means the accuracy of the report tracks the accuracy of your annotations. A third limit is the cost of adoption on an existing codebase: a large project at a high level can produce a long error list, and the baseline mechanism manages that list rather than removing it. The baseline file also needs maintenance, because entries for code that has since been fixed or deleted can linger and hide new problems in the same location.

PHPStan against Psalm and the framework extensions

The natural comparison is Psalm, another PHP static analyzer, which is why "phpstan vs psalm" appears in search data. Both read source without running it and both support levels of strictness and baseline-style suppression. The difference that matters in day-to-day use is the configuration and extension surface: PHPStan's configuration is Neon, and its ecosystem is organised as an extension library documented on phpstan.org, with separate packages for frameworks and libraries. The related search data names phpstan/phpstan-doctrine, which is the pattern: a package that teaches the analyzer about a library's types so that its objects are not treated as unknown. Laravel users search for "phpstan laravel" for the same reason. If your project leans on a framework with heavy magic, the extension is not optional decoration; without it the analyzer sees dynamic calls it cannot resolve. Choosing between the two analyzers is less about which is stricter in the abstract and more about which one already has the extension for the libraries you depend on.

Licence, releases and the cost of staying current

PHPStan is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the licence text, not legal advice; if your organisation has a policy on third-party dependencies, the LICENSE file in the repository is the document to review. The open-source analyzer and the paid PHPStan Pro add-on are separate products: the README describes Pro as a paid add-on with a web UI for browsing errors and a continuous watch mode, enabled with the --pro option, with a 30-day free trial and pricing of 7 EUR monthly for individuals and 70 EUR for teams up to 25 members. The core tool does not require Pro. On upgrades, the repository keeps an UPGRADING.md file at the top level and a CHANGELOG.md, and the default branch is 2.3.x while the most recent listed release is 2.2.14. Major-version upgrades of a static analyzer commonly change reported errors, so a version bump can surface new findings in code that has not changed; pinning the version in composer.json and reading UPGRADING.md before bumping is the cheaper path.

Editorial conclusion

Adopt PHPStan if you maintain a PHP codebase where type mistakes reach production, and especially if you can start at a low level and raise it as the baseline shrinks. Skip it if your project is a short-lived script, or if you expect it to replace runtime tests and integration checks; it never executes the code. Before committing, verify which PHP version your CI image runs, confirm the level you pick matches the errors you are willing to fix now, and check that any framework-specific extension you plan to add is listed in the extension library on phpstan.org.

Frequently asked questions

Official sources

1. License: MIT
2. phpstan/phpstan on GitHub
3. Project website
4. README
5. Releases