PHP propone apagar PECL a fines de 2029: qué pasa con tu pecl install en Docker

PHP tiene un RFC nuevo, "Sunset PECL", que propone dejar pecl.php.net en solo lectura el 30 de junio de 2027 y apagarlo del todo el 31 de diciembre de 2029. Desde ese día, pecl install deja de funcionar y la única vía oficial para instalar extensiones es PIE. Si tu Dockerfile parte de la imagen oficial de PHP, el comando pecl desaparece mucho antes: la imagen de PHP 8.6 ya no lo trae.

El RFC está en discusión, no votado. Pero es la segunda mitad de una decisión que ya se tomó en 2025, y las imágenes oficiales de Docker se adelantaron a las dos. Abajo va qué dice el RFC, qué cambia para quien tiene RUN pecl install en un Dockerfile (Redis es el caso típico, pero vale igual para APCu, Xdebug, Imagick, MongoDB o cualquier extensión que no viene con PHP) y cómo se ve el mismo Dockerfile con PIE.

Qué propone el RFC Sunset PECL

El RFC Sunset PECL lo publicó James Titcumb (asgrim) el 5 de noviembre de 2026 y está en estado "Under Discussion". Para aprobarse necesita dos tercios de los votos. Parte de que PIE ya es estable y lo mantiene la PHP Foundation.

El calendario que propone es este:

Los apagones incluyen las descargas de Windows. La sección de cambios incompatibles del RFC cabe en dos frases: "PECL will stop working. PIE must be used going forward."

Los brownouts son lo mejor del plan. Un apagón de tres horas un lunes hace fallar el pipeline que nadie mira, y alguien termina encontrando el pecl install que ya nadie recordaba.

De dónde sale: PECL ya estaba deprecado desde 2025

PECL está deprecado desde septiembre de 2025, cuando se aprobó el RFC Recommend PIE and deprecate PECL, del mismo autor. Ese RFC cambió solo el mensaje: PIE pasó a ser la forma recomendada de instalar extensiones y PECL siguió funcionando igual. En su sección de alcance futuro dejaba escrito que haría falta un segundo RFC con fechas para retirar el sitio y la herramienta. Sunset PECL es ese segundo RFC.

En paralelo, el RFC End PEAR Project Endorsement, aceptado en 2026, saca el instalador de PEAR del código fuente de PHP a partir de PHP 8.7 y deja un archivo estático de pear.php.net disponible hasta el 31 de diciembre de 2027. Importa porque pecl es parte de ese instalador: el RFC de PECL aclara que su retiro de php-src ya quedó cubierto por el de PEAR. La implementación es el PR #20124 de php-src, "PECL and PEAR removal", que sigue abierto.

Por qué tu pecl install en Docker se rompe antes de 2029

El comando pecl de la imagen oficial php de Docker existe porque la imagen compila PHP con --with-pear. Ese flag se fue en PHP 8.6: el commit "Drop --with-pear with PHP 8.6", de junio de 2026, limita la instalación de PEAR y PECL a las versiones 8.2, 8.3, 8.4 y 8.5 en la plantilla del Dockerfile.

Traducido a un Dockerfile real:

FROM php:8.5-fpm
RUN pecl install redis-6.3.0 \
    && pecl install apcu-5.1.28 \
    && docker-php-ext-enable redis apcu

Esto funciona hoy. Cambia el FROM a php:8.6-fpm y el build falla en la segunda línea porque pecl ya no existe en la imagen. PHP 8.6 tiene su versión estable programada para el 19 de noviembre de 2026: para muchos equipos, la fecha que importa es el próximo bump de versión de PHP, no 2029.

Lo que no cambia: las extensiones que vienen con PHP (pdo_mysql, gd, intl, zip, bcmath) se siguen instalando con docker-php-ext-install, que las compila desde el código fuente que ya trae la imagen. El problema son solo las que la documentación de la imagen llama "PECL extensions": las que se descargan de pecl.php.net.

Qué pasa si te quedas en PHP 8.5 con pecl

Quedarse en una imagen con pecl compra tiempo, pero no mucho. Desde el 30 de junio de 2027 nadie puede publicar versiones nuevas en PECL, así que pecl install redis va a devolver para siempre la última versión que se subió antes de esa fecha. Si una extensión saca un parche de seguridad o soporte para una versión nueva de PHP después de junio de 2027, ese parche estará en Packagist para PIE y no en PECL.

Hay un agravante que la propia documentación de la imagen de Docker advierte: PECL no revisa la compatibilidad con tu versión de PHP al elegir qué versión de la extensión instalar, solo al instalarla. Por eso recomienda fijar siempre la versión (redis-6.3.0, no redis). Con un PECL congelado, ese consejo se vuelve obligatorio.

Y el 31 de diciembre de 2029 se acaba la discusión: cualquier pecl install falla, en cualquier versión de PHP, porque el servidor del que descarga ya no existe.

La lección: si sigues con pecl en PHP 8.5, fija la versión de cada extensión y deja la migración a PIE para el próximo cambio de imagen.

Herramientas que también dependen de pecl.php.net

El pecl de la imagen no es la única pieza que habla con pecl.php.net. Muchos Dockerfiles usan install-php-extensions, el script de mlocati que la documentación de la imagen oficial recomienda para resolver dependencias de sistema. En su versión actual, el script consulta la API REST de pecl.php.net para resolver versiones y llama a pecl channel-update. Si lo usas, revisa su repositorio antes de 2027: depende de lo que haga su mantenedor.

Pasa lo mismo con scripts de provisión, imágenes base internas de la empresa y pipelines de CI que compilan extensiones. Una búsqueda de pecl en tus repositorios cuesta un minuto y te dice cuánto trabajo tienes.

Qué es PIE y cómo instala extensiones

PIE (PHP Installer for Extensions) es el reemplazo oficial de PECL, mantenido por la PHP Foundation en github.com/php/pie. Funciona como Composer: las extensiones son paquetes de Packagist y se instalan por su nombre de paquete, no por el nombre corto que usaba PECL. La última versión estable es la 1.5.5, del 30 de octubre de 2026.

Según su documentación de uso, PIE necesita PHP 8.1 o superior para ejecutarse, pero puede instalar extensiones en otras versiones de PHP. Necesita también unzip (o la extensión zip) y las herramientas de compilación de siempre: phpize, autoconf, make, gcc.

Los nombres cambian. Estos son los equivalentes de algunas extensiones comunes, tal como aparecen en Packagist:

Para cualquier otra, pie search <término> busca entre los paquetes compatibles. Si tu extensión no aparece, su autor todavía no la publicó para PIE.

El mismo Dockerfile con PIE

PIE se publica como una imagen de Docker que solo contiene el binario, ghcr.io/php/pie:bin. La documentación de PIE recomienda montarla durante el build en lugar de copiarla, para que PIE no quede en la imagen final:

FROM php:8.6-fpm
 
RUN --mount=type=bind,from=ghcr.io/php/pie:bin,source=/pie,target=/usr/local/bin/pie \
    export DEBIAN_FRONTEND="noninteractive"; \
    set -eux; \
    apt-get update; \
    apt-get install -y --no-install-recommends unzip; \
    pie install --no-cache phpredis/phpredis:^6.3; \
    pie install --no-cache apcu/apcu:^5.1; \
    apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false unzip; \
    rm -rf /var/lib/apt/lists/*

Tres diferencias con la versión de PECL:

1. No hace falta docker-php-ext-enable: PIE activa la extensión solo, y en la imagen oficial lo hace llamando a ese mismo script.
2. Las versiones usan restricciones de Composer. phpredis/phpredis:^6.3 instala la última 6.x compatible con tu PHP, y PIE sí revisa esa compatibilidad al elegir.
3. El --mount necesita BuildKit, que es el builder por defecto en las versiones actuales de Docker.

Si la extensión depende de librerías del sistema (Imagick de ImageMagick, por ejemplo), las instalas con apt-get antes del pie install, igual que hacías con PECL. En un build no interactivo PIE no instala nada por su cuenta: para eso existen los flags --auto-install-build-tools y --auto-install-system-dependencies.

Lo que cambia para quien mantiene una extensión

Para los autores, el corte llega en 2027: desde el 30 de junio PECL no acepta versiones nuevas, así que una extensión que no esté en Packagist para esa fecha se queda sin canal para publicar. Y según el RFC, la que no haya migrado a PIE dejará de poder instalarse con PECL el 31 de diciembre de 2029.

Migrar consiste en agregar un composer.json de tipo php-ext (o php-ext-zend para extensiones Zend, como Xdebug) y publicarla en Packagist. Los pasos están en la guía para mantenedores de extensiones. Las extensiones grandes ya lo hicieron: las cinco de la tabla anterior están en Packagist con esos tipos. Las que preocupan son las pequeñas, con un solo mantenedor que quizá no lee la lista de internals.

El patrón: los Dockerfiles que nadie abre

PECL tiene tres años de avisos y apagones programados por delante. Lo que se va a romper son los Dockerfiles que nadie abre desde que funcionaron la primera vez, y muchos van a caer antes del apagón, el día que alguien suba la imagen a php:8.6.

Busca pecl en tus repositorios, apunta qué extensiones instalas y comprueba que cada una está en Packagist. Si lo están, migra el Dockerfile la próxima vez que lo toques. Si alguna no está, abre un issue en su repositorio ahora: es mejor que el autor se entere por ti en 2026 que por un build roto en 2029.

Si trabajas con Laravel en contenedores, también te puede interesar cómo correr Laravel con FrankenPHP y Octane, otra pieza del ecosistema que pasó a manos de la PHP Foundation, y qué cambia en PHP 9 para Laravel y Symfony.

Preguntas frecuentes

Fuentes

• PHP RFC: Sunset PECL (calendario, apagones e impacto en extensiones)
• PHP RFC: Recommend PIE and deprecate PECL (la deprecación de 2025)
• PHP RFC: End PEAR Project Endorsement (retiro de PEAR de php-src en PHP 8.7)
• php/php-src PR #20124: PECL and PEAR removal
• docker-library/php: Drop --with-pear with PHP 8.6 y la plantilla del Dockerfile
• Documentación de la imagen oficial de PHP en Docker (core extensions, PECL extensions y versiones fijas)
• PHP 8.6 release schedule
• PIE: Using PIE (requisitos, instalación en Docker y opciones de pie install)
• PIE: guía para mantenedores de extensiones
• Lista de extensiones en Packagist
• install-php-extensions