# PHP version support on fortrabbit (old platform)

> 

<call-out :alert="true">

This is for the old platform. It's kept here for reference.

</call-out>

PHP versions move fast, security support sunsets two years after release, and your code needs a clear runway to keep up. Our [update policies](/legal/update-policies) define the formal commitment; this page is the practical reference.

## PHP compatibility matrix

This is the canonical view of which PHP versions you can select for a fortrabbit app today.

<table>
<thead>
  <tr>
    <th>
      PHP version
    </th>
    
    <th>
      Available on the old platform
    </th>
    
    <th>
      Upstream status
    </th>
    
    <th>
      php.net EOL
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      8.3
    </td>
    
    <td>
      yes (default for new Apps)
    </td>
    
    <td>
      Security support
    </td>
    
    <td>
      2027-12-31
    </td>
  </tr>
  
  <tr>
    <td>
      8.2
    </td>
    
    <td>
      yes
    </td>
    
    <td>
      Security support
    </td>
    
    <td>
      2026-12-31
    </td>
  </tr>
  
  <tr>
    <td>
      8.1
    </td>
    
    <td>
      yes
    </td>
    
    <td>
      EOL
    </td>
    
    <td>
      2025-12-31
    </td>
  </tr>
</tbody>
</table>

PHP 8.4 and 8.5 are only available on the [new platform](https://dash.fortrabbit.com/) — see the <content-link prefix="blog" text="PHP 8.5 update" href="/php-85-update">



</content-link>

 for the rationale. Older runtimes (8.0, 7.4) have been phased off the old platform as their upstream security support ended.

Patch releases (8.3.18 → 8.3.19 → 8.3.20) are applied automatically on our side. Minor upgrades stay yours to schedule.

## PHP EOL roadmap

These are the dates that drive every conversation about when to upgrade. They come from the [official php.net support schedule](https://www.php.net/supported-versions.php).

<table>
<thead>
  <tr>
    <th>
      Version
    </th>
    
    <th>
      Released
    </th>
    
    <th>
      Active support ends
    </th>
    
    <th>
      Security support ends
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      8.5
    </td>
    
    <td>
      Nov 2025
    </td>
    
    <td>
      2027-12-31
    </td>
    
    <td>
      2029-12-31
    </td>
  </tr>
  
  <tr>
    <td>
      8.4
    </td>
    
    <td>
      Nov 2024
    </td>
    
    <td>
      2026-12-31
    </td>
    
    <td>
      2028-12-31
    </td>
  </tr>
  
  <tr>
    <td>
      8.3
    </td>
    
    <td>
      Nov 2023
    </td>
    
    <td>
      2025-12-31
    </td>
    
    <td>
      2027-12-31
    </td>
  </tr>
  
  <tr>
    <td>
      8.2
    </td>
    
    <td>
      Dec 2022
    </td>
    
    <td>
      2024-12-31
    </td>
    
    <td>
      2026-12-31
    </td>
  </tr>
  
  <tr>
    <td>
      8.1
    </td>
    
    <td>
      Nov 2021
    </td>
    
    <td>
      2023-11-25
    </td>
    
    <td>
      2025-12-31 (passed)
    </td>
  </tr>
  
  <tr>
    <td>
      8.0
    </td>
    
    <td>
      Nov 2020
    </td>
    
    <td>
      2022-11-26
    </td>
    
    <td>
      2023-11-26 (passed)
    </td>
  </tr>
  
  <tr>
    <td>
      7.4
    </td>
    
    <td>
      Nov 2019
    </td>
    
    <td>
      2021-11-28
    </td>
    
    <td>
      2022-11-28 (passed)
    </td>
  </tr>
</tbody>
</table>

A version in **active support** still gets bug fixes. A version in **security support** only gets security patches — no new fixes for normal bugs. Once a version passes its security date, the PHP team stops fixing anything, and "best effort" is what every managed host can offer.

Most fortrabbit clients should aim to be at most one minor version behind the upstream active release. That is the path of least surprise.

## How fortrabbit handles PHP versions

The old platform is a managed PHP host. You pick the runtime; we keep the runtime running. There is nothing to compile, nothing to lock in a Dockerfile, and no proprietary auto-install wrapper sitting between your code and PHP.

### Per-App selection

PHP version is set per App. Each App on the old platform runs one runtime at a time. To test a new version safely, create a second App for staging and validate there before flipping the production App.

### Dashboard control

The PHP version lives in the PHP settings for each App. Pick a version from the dropdown, save. The new runtime is in place within about two minutes, with no redeploy required — your existing build keeps running.

If a new version breaks something you did not anticipate, switching back is the same flow in reverse. There is no "PHP version migration" to roll forward through; the runtime is another setting on the App.

### CLI access

For day-to-day work via SSH, the CLI PHP follows the App's PHP version. `ssh you@your-app.eu1.frbit.com php -v` reports whatever you have selected in the dashboard. Composer, `artisan`, `craft`, `wp-cli` — all of these run against the same version as your web requests, which keeps `composer.lock` and runtime behavior in sync.

### From upstream release to availability on fortrabbit

Two clocks run in parallel — when PHP itself releases a version, and when that version becomes selectable on fortrabbit. They are not the same date.

**Upstream:** the PHP project ships a new minor version roughly every November. Two years later, that version drops into security-only support; another year after that, upstream support ends entirely. The exact dates are in the EOL roadmap above.

**On fortrabbit:** per our [update policies](/legal/update-policies), a new PHP version becomes selectable "some time after the final version is released — usually after the first important patch release has come out and once all essential extensions are updated." We typically offer two or three PHP minor versions at any time. The old platform receives PHP updates less often than the new platform; if you need the latest minor sooner than the old platform delivers, the new platform is where it lands first — see the <content-link prefix="blog" text="PHP 8.5 update" href="/php-85-update">



</content-link>

 for a recent example.

When a new PHP version lands, we publish a release post on the blog listing exact version pins and any extension changes.

### Patch releases and extensions

PHP patch releases on the old platform are applied in the same maintenance windows as the minor updates. PHP extensions — apcu, redis, imagick, mongodb, blackfire — are upgraded as part of those windows, with version pins listed in each release post. See the [update policies](/legal/update-policies) for the formal commitment. If an extension you need is not part of the default set, ask us — the catalog grows when client demand justifies it.

### Composer-first, your code stays your code

fortrabbit deploys whatever you push from Git. There are no 1-click installers, no vendor-managed app templates, no autogenerated wrappers that lag behind a framework release. Your `composer.json` is the source of truth for what runs.

The practical upshot for PHP versions: when you change the platform's PHP runtime, you are changing what executes against an unchanged codebase. Nothing on our side gets rewritten or downgraded behind your back.

## Plan a PHP version upgrade

Three starting points cover most upgrades on the old platform today.

### From PHP 5.6 or 7.0

You are looking at three or four major-version boundaries. The hard breaks are mcrypt (removed in 7.2), `each()` (gone in 8.0), and the strictness of type coercion across the 7 → 8 transition. The safe path:

1. Pin your local development to the same version your App runs today.
2. Bring dependencies up to date. Anything older than 2020 will fight you; expect framework upgrades to be the bulk of the work.
3. Move one minor version at a time locally — 5.6 → 7.0 → 7.1 → 7.2 — and run the test suite at each step. The <content-link prefix="blog" text="PHP 7.2 upgrade path" href="/php-upgrade-path">



</content-link>

 post walks through the original mechanics; they still apply.
4. Once your code runs cleanly on PHP 7.x, flip the dashboard to the target version and verify under production conditions. From there, the 7.x → 8.x guidance below applies.

Skipping minors works for some projects, but you lose the ability to bisect when something breaks. For projects this old, the slow walk is usually faster than three days of debugging.

### From PHP 7.x to 8.x

This is the upgrade that catches most older Apps. Backward-incompatible changes cluster at the 7.4 → 8.0 boundary and again at 8.1 → 8.2. The well-known traps:

- Internal function signatures got stricter — code that silently coerced `null` into a string now throws.
- `each()`, `create_function()`, and the `{}` string-offset syntax are gone.
- Resource types for several extensions became proper objects.
- PHP 8.1 deprecated many implicit nullable parameter declarations.
- PHP 8.2 turned dynamic properties into a deprecation warning; PHP 9.0 will make it an error.

For an active codebase, run static analysis before you flip the runtime. PHPStan, Psalm, and Rector each ship rule sets keyed to a target PHP version, and they will catch most of the breaks before CI does.

If you maintain a framework or CMS — Laravel, Symfony, Craft CMS, WordPress, Statamic — upgrade the framework first, then PHP. Frameworks publish PHP-version support matrices for every release; matching the framework to the runtime is the path most of their changelogs assume.

### From PHP 8.x to the next 8.x

Minor-to-minor 8.x upgrades are the easiest case. There are deprecations to clean up but rarely hard breaks. Read the migration guide on php.net — for example, [PHP 8.3](https://www.php.net/manual/en/migration83.php) — and skim "backward incompatible changes". Run your test suite locally against the target version, then flip the runtime in the dashboard and watch logs for `Deprecated` notices for a few days.

If the upstream migration guide is short and your test suite is green, the dashboard flip usually takes less time than reading this paragraph.

## Choosing the right PHP version

Pick the newest release the platform offers that your codebase still runs cleanly on, and never let an App sit past its upstream security-support EOL date without a plan. Once a version is removed from the old platform, remaining Apps are force-upgraded to the next available one — fixing things in advance is always cheaper than fixing them under pressure.

Schedule the next upgrade as soon as the current one lands. The longer the gap between PHP versions, the harder each jump gets — and the more likely you will hit a framework or CMS deprecation that forces a coordinated migration instead of a one-line setting change.

If you need PHP 8.4, PHP 8.5, or per-environment runtime selection, that is what the new platform offers. See <content-link prefix="dash" text="dash">



</content-link>

 to start a new App there.

For the per-release detail behind any version in the table above, see the changelog posts on the blog:

- <content-link prefix="blog" text="PHP 8.5" href="/php-85-update">



</content-link>

 (new platform only)
- <content-link prefix="blog" text="PHP 8.4" href="/php-84-update">



</content-link>

 (new platform only)
- <content-link prefix="blog" text="PHP 8.3" href="/php-83-update">



</content-link>
- <content-link prefix="blog" text="PHP 8.2" href="/php-82-update">



</content-link>
- <content-link prefix="blog" text="PHP 8.1" href="/php-81-update">



</content-link>
- <content-link prefix="blog" text="PHP 8.0" href="/php-8-update">



</content-link>

For the older history — PHP 7.4 EOL, PHP 7.1 fade-out, the 5.6 deadline — see <content-link prefix="blog" text="On PHP deadlines" href="/on-php-deadlines">



</content-link>

 and the <content-link prefix="blog" text="PHP EOL FAQ" href="/php-eol-faq">



</content-link>

.

If you are not sure which version your App is on or which target makes sense, the dashboard's PHP settings is the source of truth, and our support chat is open for the rest.