Zephir emits C rather than running itself, and its PHP version badge reads a different project

Zephir compiles to C and hands the result to your compiler

The mechanism is a source-to-source compiler, and the README states it in three sentences. Zephir is a high level programming language that eases the creation and maintainability of extensions for PHP. Zephir extensions are exported to C code, which can then be compiled and optimised by major C compilers such as gcc, clang or vc++. Functionality is exposed to the PHP language. There is no Zephir runtime and no interpreter, which is the whole point: what ships is ordinary C that any of those three toolchains can build, and what you maintain afterwards is a PHP extension rather than a bespoke native module. The trade is that the C in between is generated, so debugging a problem inside your extension means reading generated code as well as your own.

Every badge points at phalcon, and one at another package

The repository lives under zephir-lang, and almost nothing in the README agrees. The Packagist links point at phalcon/zephir, so the composer package name is not the repository name. The version badge is served from poser.pugx.org for phalcon/zephir, the download count and statistics links are the same, the logo asset is hosted at assets.phalcon.io, and the Discord invite is phalcon.io/discord. The sponsor and backer sections both point at opencollective.com/phalcon, and both of their image anchors point at the same contributors URL. One badge is simply wrong in a different way: the PHP from Packagist badge reads phalcon/migrations, a separate package, so the PHP version it displays has nothing to do with Zephir.

The development matrix is six PHP versions in six containers

docker-compose.yml defines six services for local development and says so in its first line. zephir-8.0 through zephir-8.5 each build from a matching directory under .docker, so the PHP major and minor version is chosen by which container you start rather than by a flag. Every service shares the same shape: a working directory of /srv, the repository mounted at that path, and a single environment variable, USER=Zephir. The container names keep the dotted version, zephir-8.0, while the hostnames flatten it to zephir-80, since container naming rules do not allow dots. Nothing in the README mentions this matrix, so the range of PHP versions the compiler is exercised against is only visible in the compose file.

The default branch is development, and releases are frequent

The repository's default branch is named development rather than main or master, which tells you where work lands and also means the common git clone and cd into master pattern does not apply here. The release history is close and recent. Version 1.5.0 was published on 2026-09-18, 1.6.0 on 2026-10-01, and 1.6.1 on 2026-10-02, a minor followed by a patch three days later. The last push to the default branch is dated 2026-10-04, two days after the newest tag. The README links a Packagist stable version badge rather than naming a version, so the tag list is where the current release has to be confirmed.

Two PHPUnit configs, two Codecov configs, one committed lint report

The root of the repository is the toolchain of a PHP project, and some of it is duplicated. There are two PHPUnit configurations, phpunit.xml.dist and phpunit.ext.xml, which reads as one suite for the compiler's own code and one for the extension it produces. There are also two Codecov files, .codecov.yml and codecov.yml. Static analysis is layered: psalm.xml, phpcs.xml.dist, phpmd.xml.dist and .php-cs-fixer.dist.php sit side by side, and JetBrains Qodana has both a qodana.yaml configuration and a qodana.sarif.json report committed at the root, so a lint result is versioned alongside the code. Benchmarks have their own file in phpbench.json, and box.json.dist points at Box, the PHAR packager.

The README contains no installation command

There is no composer require line, no build step, no version requirement and no platform list anywhere in the file. What it does contain is a set of links: the project site, the documentation at docs.zephir-lang.com, the GitHub repository, a Facebook group, a Discord server and GitHub discussions, a Code of Conduct, and CONTRIBUTING.md. The three things you need to get started, the package name, the PHP version and the command that builds an extension, are all one click away rather than in the readme. The executables that would do that work are visible at the repository root instead, named zephir, zephir-autocomplete and zephir.bat for Windows, with WINDOWS.md as a separate document for that platform.

The compiler's own parts are all visible from the root

Because Zephir is itself a PHP program, its source layout is exposed. src/ holds the implementation, config/ and a config.json hold its settings, templates/ holds what it emits, stub/ and prototypes/ hold the definitions used to generate stubs for the language's own API, kernel/ and ext/ are separate pieces of the build, and .ci/ and .docker/ hold the two automation setups. Two of those names will confuse anyone arriving from another language: kernel/ is not a Linux kernel and ext/ is not a browser extension, both are directories in a compiler. There is also a .dir-locals.el at the root, which is an Emacs file rather than a PHP one.

Editorial conclusion

Zephir is worth considering if you want PHP extension performance and syntax without writing C, and the case for it is narrow and clear: the source you write is exported to C, compiled by an ordinary toolchain and exposed to PHP, which keeps the extension maintainable in a way raw C is not. Two things to check before you commit. There is no installation command anywhere in the README, so start from the documentation site and the Packagist page rather than the readme, and note that the published package name is phalcon/zephir while the repository lives under zephir-lang. And the compiler itself is a PHP program with two separate PHPUnit suites and a six-version development matrix, so if you intend to modify Zephir rather than use it, expect a project with a real build and test apparatus behind the language.

Frequently asked questions

Official sources

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