# vercel-php: PHP Runtime for Vercel Serverless Functions

> vercel-community/php packages PHP for Vercel Serverless Functions, with support for PHP 7.4 through 8.5 and Node.js 22.x. It is aimed at developers who want to deploy small PHP APIs or framework applications through Vercel's serverless deployment model, but it adds a runtime dependency and has a narrower platform integration than a conventional PHP host.

**vercel-community/php** — 🐘 PHP Runtime for ▲ Vercel Serverless Functions (support 7.4-8.5)

- Repository: https://github.com/vercel-community/php
- Website: https://php.vercel.app
- Stars: 1,471 · Forks: 326
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/vercel-community-php

## Why vercel-php Exists on Vercel

vercel-php solves a specific deployment gap: running PHP entrypoints as Vercel functions rather than treating a PHP application as a conventional long-running web server. The target user is a developer with a small PHP project who already wants to use Vercel and is willing to describe PHP files through the `functions` section of `vercel.json`.

The README identifies PHP projects, APIs, Composer-based applications, and several frameworks as supported use cases. Its examples include Laravel, Lumen, Nette, Phalcon, Slim, and Symfony Microservice. That does not mean every PHP application can be moved unchanged. It means the runtime provides a PHP execution path for projects whose deployment shape can fit Vercel functions.

The alternative is not another PHP runtime with an identical interface. A conventional PHP host would place the application behind a web server such as PHP-FPM or Apache, with the operating system and PHP process managed by the host. Vercel uses function-style deployment, so this project has to connect PHP entrypoints to that model. That distinction matters for applications that depend on long-running workers, local writable state, background jobs, or a server that remains continuously available.

## Function Configuration and Request Flow

The deployment contract starts with a PHP file under `api`. A minimal project contains `api/index.php` and `vercel.json`. Vercel maps PHP files in that directory to functions, while `vercel.json` selects the runtime package and version.

The basic configuration assigns `api/*.php` to `vercel-php@0.9.0`. The wildcard means that PHP files directly matching the `api` directory can be exposed as functions according to the mapping. If every request should go to one entrypoint, the README adds a `routes` rule that sends `(.*)` to `/api/index.php`. This is useful for a front controller, but it also means the project must handle its own URL dispatch rather than relying on the web server's conventional rewrite behavior.

The repository is written primarily in TypeScript and exposes `dist/index.js` as its package entrypoint. Its dependency list includes `@libphp/almalinux-9-v85`, while the package publishes `dist` and `conf`. Those files indicate a build artifact and runtime configuration are part of the distribution, but the README does not describe the internal request bridge in enough detail to make claims about process startup, buffering, or error handling. The documented contract is therefore the Vercel function mapping plus the PHP process itself.

The package supports several runtime versions, each paired with a PHP release. The README describes Node autodetection for these versions, and the current feature list names Node.js 22.x.

## Installing vercel-php and Deploying a First Endpoint

The fastest documented first use is a PHP entrypoint plus a `vercel.json` file. Create `api/index.php` with the following contents. The page calls `phpinfo()`, which makes the deployment's PHP configuration visible through the browser.

```php
<?php
phpinfo();
```

Create `vercel.json` at the project root. This configuration tells Vercel that the PHP files under `api` should use the documented runtime version.

```json
{
  "functions": {
    "api/*.php": {
      "runtime": "vercel-php@0.9.0"
    }
  }
}
```

The README then documents these Vercel CLI steps. The first command installs the CLI globally, the second authenticates the local account, and the final command starts the deployment flow.

```bash
npm i -g vercel
vercel login
vercel
```

For a front-controller application, the routing configuration is:

```json
{
  "functions": {
    "api/*.php": {
      "runtime": "vercel-php@0.9.0"
    }
  },
  "routes": [
    { "src": "/(.*)",  "dest": "/api/index.php" }
  ]
}
```

The README says that `vercel dev` requires PHP installed locally. It gives the PHP built-in development server as a local option for a single entrypoint.

```bash
php -S localhost:8000 api/index.php
```

This local command serves `api/index.php` at port 8000. It does not reproduce Vercel's routing, function packaging, or deployment behavior, so it is useful for checking PHP code but not sufficient for validating the complete hosted application.

## PHP Versions, Extensions, and Framework Use

The runtime offers explicit version choices rather than relying on an unspecified PHP version. The README maps `vercel-php@0.9.0` to PHP 8.5.x, `0.8.0` to PHP 8.4.x, `0.7.4` to PHP 8.3.x, `0.6.2` to PHP 8.2.x, `0.5.5` to PHP 8.1.x, `0.4.5` to PHP 8.0.x, and `0.3.8` to PHP 7.4.x. This is useful when an application has a known PHP compatibility range, but it also puts the choice in `vercel.json`.

The README lists many extensions, including `curl`, `intl`, `mbstring`, `mongodb`, `mysqli`, `PDO`, `pdo_mysql`, `pdo_pgsql`, `pdo_sqlite`, `pgsql`, `redis`, `soap`, `sodium`, `swoole`, `xml`, `zip`, and `Zend OPcache`. The extension list is a capability claim, not proof that every extension is enabled in every runtime version or suitable for every deployment. The README links to the PECL extension RPM status page for the complete installable extension list, so projects with uncommon extension requirements should verify that list before depending on them.

Composer and framework support are documented through linked examples, including Laravel, Lumen, Nette, Phalcon, Slim, and Symfony Microservice. The presence of an example does not describe production configuration, dependency installation, environment variables, or framework-specific Vercel requirements. A framework migration therefore requires checking its own build and runtime assumptions against the function configuration.

## Cold Starts, Memory, and the Serverless Trade-off

The README reports approximately 250 ms for a cold start, 5 ms for a warm request, and 90 MB of memory. These are project-provided figures, not a benchmark reproduced here, and they should be treated as a starting point for capacity planning rather than a guarantee for every application. A PHP framework can add startup work, dependency loading, database connections, and initialization beyond the runtime baseline.

The serverless model can suit intermittent APIs because the project does not require a traditional PHP web server in the project repository. It also changes operational assumptions. Execution is tied to Vercel functions, local state is not the same as a persistent host filesystem, and an application that depends on continuous process behavior may not fit the deployment model.

The listed `swoole` extension deserves particular attention. Its presence in the extension list does not establish that long-running Swoole services can be hosted as an ordinary Vercel function. The README does not document a separate worker model, persistent connection strategy, or operational workflow for Swoole. Treat extension availability and serverless deployment compatibility as separate questions.

The architecture description calls the runtime a PHP development server and says it is fast enough, but it does not explain whether this means a local development server, a Vercel function launcher, or both. The documented usage path is still enough to configure and deploy a PHP entrypoint, while deeper runtime behavior should be confirmed against the project source or deployment logs.

## Maintenance, Releases, and Upgrade Work

The repository is now archived and read-only. Its recorded last push was on 2026-05-01; check current compatibility with Vercel before using this runtime. The repository has no GitHub releases according to the repository record. Version selection is therefore driven by the version table in the README and by the runtime string in `vercel.json`, not by a documented stream of GitHub release notes.

The package version in `package.json` is `0.9.0`, and its scripts include `npm run build`, `npm run test`, and `npm run watch`. The Makefile provides corresponding `build`, `test`, `build-watch`, and `test-watch` targets, plus `install` and `publish` targets. Those files show a TypeScript build and Jest test setup, but the README does not describe the test cases or deployment guarantees. Contributors would need to inspect the source and test directory for implementation-specific assurance.

Upgrading means checking more than the package version. A project should compare its selected PHP runtime, required extensions, framework dependencies, Node.js assumptions, and Vercel configuration. The README lists distinct runtime versions, so changing the package version can change the PHP generation associated with it. The MIT license permits use and modification under its terms, but application owners still need to review dependency licenses separately. No legal interpretation of those terms is required for this evaluation.

## Choosing Between vercel-php and Conventional PHP Hosting

The practical alternative is a conventional PHP hosting platform with an always-running PHP process. That approach suits applications that need process-managed workers, persistent local services, unrestricted server configuration, or a deployment model that does not depend on Vercel's function packaging. It also gives the operator direct control over PHP versions, web-server behavior, and filesystem layout.

vercel-php takes a different route. It adapts PHP to Vercel's function interface and keeps the deployment description close to the repository: PHP files live under `api`, `vercel.json` maps them to a runtime, and the Vercel CLI performs deployment. That is a better fit for a small endpoint, an occasional microservice, or a PHP application already organized around a front controller.

The choice should be based on execution requirements rather than language familiarity. The README's function model and route example are useful for HTTP-oriented applications. It does not document a separate process manager, persistent worker deployment, or general server configuration, so those requirements point toward conventional hosting. Conversely, if the goal is Vercel deployment and the application is limited to PHP entrypoints, the runtime removes the need to find a separate PHP hosting platform.

## Conclusion

Adopt vercel-php for a small PHP endpoint that should deploy through Vercel and that you are prepared to operate through Vercel's function configuration. Do not choose it merely because the application is written in PHP if it needs a conventional PHP process, extensive system control, or deployment outside Vercel. Verify PHP version, required extensions, Composer or framework setup, routing behavior, and local `vercel dev` prerequisites before moving production traffic. The repository is now archived and read-only. The README pins runtime examples to specific `vercel-php` versions, so version selection remains an explicit deployment choice.

## FAQ

### How do I install and deploy a PHP project with vercel-php?

Create `api/index.php`, configure `api/*.php` to use a documented runtime version in `vercel.json`, then install the Vercel CLI with `npm i -g vercel`. Run `vercel login` followed by `vercel` to start deployment.

### Which PHP versions does vercel-php support?

The README lists `vercel-php@0.9.0` for PHP 8.5.x, `0.8.0` for PHP 8.4.x, `0.7.4` for PHP 8.3.x, `0.6.2` for PHP 8.2.x, `0.5.5` for PHP 8.1.x, `0.4.5` for PHP 8.0.x, and `0.3.8` for PHP 7.4.x.

### Can I run a PHP framework application on Vercel with vercel-php?

The README links examples for Laravel, Lumen, Nette, Phalcon, Slim, and Symfony Microservice. It does not provide one universal framework configuration, so framework dependencies, build steps, environment variables, and entrypoints still need to be checked.

## Sources

- [Issues](https://github.com/vercel-community/php/issues)
- [License: MIT](https://github.com/vercel-community/php/blob/master/LICENSE)
- [Project website](https://php.vercel.app)
- [README](https://github.com/vercel-community/php/blob/master/README.md)
- [vercel-community/php on GitHub](https://github.com/vercel-community/php)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vercel-community-php