Mage-OS 3: qué trae, y qué rompe

Mage-OS 3.0 llegó el 18 de mayo de 2026, construido sobre la base de Magento Open Source 2.4.9. Desde entonces le han seguido cuatro versiones: 3.1 por estabilidad, y después 3.2, 3.3 y 3.4 con el contenido de seguridad de Adobe de julio y agosto. Si está aquí por esa última, 3.4.0 es el boletín de secuestro de cuentas de agosto, y debería estar desplegándola en lugar de leyendo notas de versión.

Antes de cualquier detalle, hay una distinción que hace mucho más fácil leer las notas de la versión. Parte de lo que verá atribuido a Mage-OS 3 es trabajo propio de Mage-OS, y parte llega con la base 2.4.9 y le caería exactamente igual si se quedara en Magento. Esas dos categorías tienen implicaciones muy distintas para su plan de actualización, y la mayoría de los artículos las mezclan.

El instalador

bin/magento install es ahora un asistente guiado que cubre la base de datos, la cuenta de admin, la configuración de la tienda, los servicios, los datos de ejemplo y la selección del tema.

Dos detalles lo convierten en algo más que un capricho. Detecta automáticamente MySQL/MariaDB, Redis, OpenSearch/Elasticsearch y RabbitMQ en los puertos estándar, así que el fallo habitual de la primera ejecución —una errata en un host o un puerto que tardará veinte minutos en encontrar— en su mayor parte deja de ocurrir. Y guarda la configuración sobre la marcha, así que una ejecución fallida se reanuda donde se quedó en lugar de empezar de cero, volviendo a pedir las contraseñas.

También pregunta por Hyvä durante la instalación y configura los paquetes de Composer y el tema si dice que sí. Hyvä sigue teniendo licencia comercial; el instalador le ahorra la configuración, no la tarifa.

El antiguo setup:install no cambia, así que el aprovisionamiento por script y la CI siguen funcionando exactamente igual que ahora.

La Minimal Distribution

El paquete opcional mage-os/product-minimal-edition instala unos 98 paquetes del núcleo. Page Builder, Inventory, GraphQL y componentes similares pasan a ser paquetes de Composer individuales que añade cuando los quiere, y Mage-OS ha publicado un navegador de paquetes para encontrarlos.

El argumento a favor es la superficie de ataque y la claridad sobre lo que está ejecutando de verdad. El código que nunca activó sigue en el disco, sigue cargándose en el autoloader y sigue siendo suyo para parchearlo: la misma razón por la que decimos a los clientes que eliminen las extensiones que no usan en lugar de desactivarlas.

Dos salvedades. La distribución completa sigue siendo la opción por defecto, así que nada cambia salvo que la elija. Y es una decisión para instalaciones nuevas: reconvertir una tienda existente a la edición mínima significa demostrar que nada en su tema, sus integraciones o su conjunto de extensiones depende de un módulo que acaba de quitar. Eso es una auditoría, no un comando de Composer.

Devoluciones y el registro de actividad del admin

Dos módulos orientados al comerciante vienen incluidos. mage-os/module-rma da a los clientes una solicitud de devolución en su cuenta y a los comerciantes un flujo de revisión y aprobación. mage-os/module-admin-activity-log registra quién cambió qué y cuándo.

Los dos hay que activarlos en la configuración después de actualizar. El registro de actividad está basado en la extensión de código abierto de KiwiCommerce, modernizada por Mage-OS en lugar de escrita desde cero.

Son las dos cosas más interesantes de la versión, porque la propia documentación de Adobe marca ambas capacidades como disponibles solo en Adobe Commerce. Hemos escrito aparte sobre lo que eso hace con la comparación.

Cuatro herramientas que instalaba de todos modos

Incluidas por defecto: la CLI n98-magerun2 (vendor/bin/n98-magerun2), las páginas de error de Ignition con stack traces y enlaces directos al editor, Varnish Extended y un branding del admin configurable. Las cuatro son paquetes de código abierto de terceros ya existentes que Mage-OS fija en el metapaquete —de Swissup, Elgentos, element119 y n98 respectivamente—, así que lo que recibe es la selección y la integración.

Dos notas para la propia actualización. Ignition se desactiva solo en producción, que es el valor por defecto correcto y que de todos modos conviene confirmar en el primer deploy. Varnish Extended significa regenerar su VCL después de actualizar, así que póngalo en el runbook.

Dos cosas que la gente espera encontrar en 3.0 y no encuentra. El módulo de optimización del tema —caché de avance/retroceso, precarga especulativa, view transitions— y las políticas de admin de PCI DSS 4.0 llegaron antes, en Mage-OS 2.0, en octubre de 2025, así que una tienda 2.x existente ya los tiene. Y el tema de admin M137 nunca ha venido incluido; es un paquete de Mage-OS Lab que instala usted mismo. Hemos cubierto qué hace cada uno de ellos de verdad aparte.

Qué rompe

PHP 8.2 queda fuera. El mínimo es 8.3, se recomienda 8.4, 8.5 funciona, y Composer se niega en redondo a instalar sobre nada más antiguo, así que esto es una tarea de hosting antes que una tarea de actualización. Tampoco es una decisión de Mage-OS; Magento Open Source 2.4.9 traza la misma línea.

Symfony pasó a 7.4 LTS, así que las extensiones que extienden clases de Symfony 6.x necesitan actualizarse, y los comandos CLI son donde lo notará primero. Comprobé las notas de la versión 2.4.9 de Adobe en este punto, porque se reporta mal constantemente: la actualización de Symfony es upstream. Le va a llegar también en Magento, y no es una razón para evitar Mage-OS.

Los módulos de analítica de Adobe desaparecen, y eso sí es obra de Mage-OS: module-analytics más los módulos de analítica de catálogo, cliente, quote, reseñas, ventas y lista de deseos, y con ellos el módulo de Marketplace. Salvo que algo de lo que ejecuta dependa de la recopilación de datos de Adobe —y en la mayoría de las tiendas nada depende—, no lo notará.

setup:backup desaparece junto con el módulo Magento_Backup. Use las herramientas de sistema de archivos y base de datos adecuadas para su entorno, que es lo que hacía de todos modos cualquiera con un proceso de copias de seguridad de verdad. Las notas de la versión de Mage-OS lo listan entre las eliminaciones, y no pude confirmar en las notas de 2.4.9 de Adobe si la eliminación es upstream o suya, así que trate la atribución como abierta. El efecto para usted es idéntico en cualquier caso.

ext-ftp ya no es obligatorio, lo que elimina una dependencia y no rompe nada.

La carga lazy de objetos está activada —el trabajo de DI propio de Mage-OS—, con vías de escape: ponga lazy_object_loading_disabled a true en app/etc/env.php, o marque una sola clase con el atributo #[Magento\Framework\ObjectManager\Attribute\NonLazy]. Conviene saberlo antes de pasar un día depurando una extensión que da por hecha la construcción con avidez.

La política de soporte merece una línea propia

Mage-OS soporta solo su última versión para parches de seguridad y soporte de la comunidad.

Compárelo con Adobe, donde cada línea de versión recibe una ventana de soporte estándar de tres años. No es un defecto —es el compromiso de mantenimiento que una asociación financiada por voluntarios puede cumplir de verdad—, pero sí cambia lo que ejecutar Mage-OS le exige. Aparcarse en una versión dos años y recibir parches no es el trato. Actualiza a su cadencia, que son aproximadamente dos versiones con funciones al año, en abril y octubre, más versiones de seguridad a los pocos días de los parches del segundo martes de Adobe.

Para una tienda con un pipeline de deploy que funciona, eso es rutina. Para una que actualiza a regañadientes, es una razón para arreglar el pipeline antes de cambiar de distribución.

Adoptarlo

Actualizando desde un Mage-OS anterior:

composer require mage-os/product-community-edition=^3.0 --no-update
composer update
bin/magento setup:upgrade

Una instalación nueva:

composer create-project --repository-url=https://repo.mage-os.org/ \
  mage-os/project-community-edition=3.0.0 <install-directory>
cd <install-directory>
bin/magento install

Compruebe la versión actual antes de ejecutar cualquiera de los dos: 3.4.0 es la última a mediados de agosto de 2026, y fijar 3.0.0 en una instalación nueva instalaría una versión a la que le faltan dos meses de parches de seguridad.

El orden que mantiene esto aburrido: confirme PHP 8.3 o superior en su hosting, tome una copia de staging, ejecute la actualización ahí, someta cada extensión de pago a una prueba real, regenere el VCL de Varnish y después despliegue con la release anterior lista para restaurar. En una tienda que conozco bien esperaría un par de días, la mayor parte dedicados a probar las extensiones y no a la actualización. Si viene de Magento y no de un Mage-OS anterior, el cambio de distribución es un ejercicio aparte, y hacer las dos cosas a la vez significa que no sabrá qué cambio causó una regresión.

Emyrix lleva actualizaciones de Magento, Adobe Commerce y Mage-OS, incluidas las pruebas de extensiones que deciden cuánto dura una. No tenemos ninguna relación comercial con la Mage-OS Association. Si quiere que definamos la suya, escríbanos.

El contenido de las versiones, las fechas, los nombres de paquetes y la política de soporte proceden de mage-os.org; la atribución de Symfony 7.4 se comprobó contra las notas de la versión 2.4.9 de Magento Open Source de Adobe. Las versiones se mueven rápido, así que confirme la versión actual antes de planificar sobre una concreta.