Actualización de Plesk Obsidian: nuevas funciones para proveedores de alojamiento web

Separar claramente la versión y los componentes

La situación documentada a fecha de 2 de octubre de 2026 es la siguiente para el Producto estrella Plesk Obsidian 18.0.81, Actualización 2. Esta actualización se publicó el 29 de septiembre de 2026 y corrige un problema de seguridad crítico. Las nuevas funciones del panel descritas en este artículo forman parte de la versión Plesk Obsidian 18.0.81 del 15 de septiembre de 2026; por su parte, la Actualización 1 y la Actualización 2 incluyen correcciones documentadas de errores y de seguridad.

No obstante, puede haber actualizaciones posteriores que no modifiquen la versión principal 18.0.81, actualización 2: El registro de cambios recoge, por ejemplo, actualizaciones para extensiones como SSL It! y Let’s Encrypt del 29 de septiembre, así como actualizaciones de paquetes PHP del 30 de septiembre de 2026. Por lo tanto, quien se limite a hablar de un „Plesk actualizado“ omite una información importante para la planificación y la asistencia técnica.

Plesk distingue entre varios niveles de actualización. Los paquetes de Plesk constituyen el propio panel y sus funciones directamente asociadas. Además, existen paquetes de servicios y extensiones proporcionados por Plesk que ofrecen capacidades adicionales o permiten integrar servicios externos. Por lo tanto, un nuevo número de versión de una extensión no significa necesariamente que el núcleo de Plesk también esté actualizado, y viceversa.

Además, cada uno de ellos gestiona Panel de alojamiento Dentro de un sistema operativo existen otros niveles: paquetes del sistema operativo y componentes de terceros, como bases de datos, entornos de ejecución de PHP, servidores web y servicios de correo electrónico. Sus fuentes de paquetes, ciclos de soporte y dependencias no siguen necesariamente el ritmo de publicación de Plesk. Para un proveedor, esta separación tiene importancia práctica, ya que los tipos de error, las ventanas de mantenimiento y las responsabilidades pueden variar en función del componente afectado.

Por lo tanto, la documentación del estado actual debería incluir siempre la combinación concreta: versión de Plesk con número de actualización, versión de la extensión instalada, sistema operativo y paquetes de tiempo de ejecución relevantes. En el caso de las funciones de certificados o aplicaciones, también debe incluirse la integración utilizada. De este modo, se puede determinar, por ejemplo, si un cambio procede de SSL It!, de una integración de Let’s Encrypt o del núcleo del panel. Esto evita expectativas confusas en los comunicados a los clientes y facilita la localización del problema en el servicio de asistencia.

Cómo afectan las actualizaciones de Plesk a los proveedores

Dentro de la línea Obsidian 18.0, las actualizaciones se realizan de forma continua y secuencial instalado. No es posible saltarse actualizaciones intermedias concretas. Esto establece una ruta de actualización definida, pero no exime al proveedor de comprobar su propio entorno: cuantos más sitios web de clientes, dependencias de PHP específicas y extensiones albergue un servidor, más importante es determinar qué cambio afecta a qué clase de servicio.

Plesk describe las actualizaciones automáticas para sus propias actualizaciones y opciones independientes para los componentes de terceros incluidos, así como para los paquetes del sistema. Sin embargo, la página de documentación ofrece información contradictoria sobre la configuración predeterminada de la opción de componentes de terceros. Por lo tanto, los administradores no deben dar por sentado que existe un valor predeterminado válido de forma global, sino que deben comprobar las opciones realmente configuradas para cada servidor en Tools & Settings > Update Settings Comprobarlo. Hay que tener especial cuidado, ya que los componentes más recientes pueden ser incompatibles con los sitios web alojados.

Para el funcionamiento de muchas instancias de clientes, esta distinción supone una ventaja cuando se traduce en procesos. Las correcciones del panel y los cambios de seguridad pueden planificarse en función de su alcance; por el contrario, los cambios de componentes se someten a una evaluación de compatibilidad específica. Una oferta de alojamiento gestionado no tiene por qué incorporar de inmediato todas las versiones de paquetes disponibles. Lo decisivo es qué versiones se ajustan a la pila prometida, a la base de clientes probada y al modelo de asistencia previsto.

Las ventajas de las últimas versiones de Obsidian se distribuyen en varias áreas operativas: las funciones de diagnóstico permiten estructurar la asistencia de primer nivel; las nuevas herramientas de alojamiento de aplicaciones amplían las opciones de tarifas; y las funciones de certificación y asistencia abarcan la seguridad y la gestión de derechos. El artículo también repasa los fundamentos y la evolución anteriores de la línea de productos. Plesk Obsidian 2025: Innovaciones revolucionarias para el alojamiento web . Sin embargo, para el lanzamiento actual, lo que resulta determinante es el componente concreto, y no solo el nombre del producto.

Por lo tanto, la automatización no es una decisión de autorización general. Es recomendable establecer una distinción entre la instalación periódica de actualizaciones documentadas de Plesk y los cambios controlados de forma deliberada en la pila del cliente. Especialmente en el caso de los servidores compartidos, esta distinción evita que un cambio de componentes que pase desapercibido afecte al mismo tiempo a muchos sitios web independientes entre sí. No sustituye a las pruebas, pero hace que los riesgos sean visibles y se puedan identificar.

Nuevas funciones según el escenario de alojamiento

En el alojamiento compartido, una de las primeras aplicaciones es la detección más rápida de incidencias en los dominios. Las que se encuentran en Plesk Obsidian 18.0.81: el diagnóstico de DNS de uso general agrupa comprobaciones sobre la resolución, aspectos relacionados con los registros MX, DNSSEC, servidores de nombres y la caducidad del dominio. El informe de fácil lectura que aparece en el panel puede ayudar al personal de soporte técnico a analizar de forma estructurada los problemas relacionados con el DNS, el correo electrónico y la delegación antes de que se agraven.

Sin embargo, el informe es un Diagnóstico y no se aplica la corrección automática. En concreto, los alias de dominio no están cubiertos actualmente. Aunque un resultado indique una delegación o zona errónea, la corrección puede corresponder al registrador o a un operador de DNS externo. Por lo tanto, como herramienta de asistencia técnica, esta función resulta especialmente útil cuando se especifican claramente en el ticket las responsabilidades y el siguiente paso de escalación.

Un segundo ámbito es Alojamiento de aplicaciones Para agencias y desarrolladores. Node.js Toolkit 2.5.0 incorpora una vista general centralizada de las aplicaciones Node.js activadas y la configuración con un solo clic de los proyectos existentes. La detección automática puede identificar varios marcos de trabajo de servidor habituales, así como interfaces front-end estáticas. Además, la extensión pnpm solo es compatible con Plesk para Linux. Esto reduce los pasos repetitivos, pero no garantiza que cada implementación individual pueda adoptarse sin modificaciones.

La nueva extensión de Python 1.0.0 también está dirigida a sistemas Linux y ofrece compatibilidad con Python por dominio, entornos virtuales, dependencias, variables de entorno y secretos almacenados de forma cifrada. Las aplicaciones se ejecutan como aplicaciones WSGI a través de Phusion Passenger; el permiso „gestión de compatibilidad con Python“ se puede controlar mediante planes de servicio y suscripciones. Esto puede convertirse en una característica tarifaria controlada, pero no sustituye automáticamente a cualquier arquitectura de Python.

Un tercer ámbito abarca los certificados y las funciones de asistencia. En la versión 18.0.81, SSL It! admite la validación DNS como alternativa a la validación HTTP para las integraciones «ext-acme» y «ext-letsencrypt» mencionadas. Esto resulta relevante, por ejemplo, para dominios sin el puerto 80 abierto. Sigue siendo imprescindible disponer de una forma adecuada de configurar los registros DNS en la zona realmente competente; la mera visualización de un registro no otorga acceso de escritura.

MCP está desactivado por defecto en la versión 18.0.81 y se puede configurar a través de una cuenta de WebPros. Los administradores configuran en panel.ini los tipos de usuario que pueden conectarse a los clientes MCP. Por lo tanto, su idoneidad no solo depende de la función, sino también de los roles, los permisos y el registro de eventos. Las funciones de ampliación específicas de cada plataforma, la gestión externa del DNS y la arquitectura de la aplicación del cliente determinan, en conjunto, qué novedades corresponden a cada tarifa.

Comparativa de funciones para la planificación de productos

Para la planificación de productos, la denominación «Plesk Obsidian» no es suficiente: las funciones relevantes en este caso proceden, en parte, del producto principal y, en parte, de extensiones con versiones independientes. Por ello, un proveedor no debería evaluar las funciones únicamente en función de su utilidad, sino que debería incluir en su catálogo de tarifas el sistema operativo, el modelo de licencia y las dependencias técnicas de cada caso.

La tabla distingue de forma especialmente clara entre una función de la plataforma y un servicio de tarifa comercializable. El diagnóstico DNS puede estar disponible de forma generalizada como herramienta de soporte. Python, por el contrario, solo forma parte de las ofertas de Linux cuyos límites de soporte y gestión de derechos estén previstos para ello. En el caso de Node.js, el proveedor debe distinguir entre las distintas subfunciones: pnpm está documentado como exclusivo de Linux, mientras que el registro de cambios no limita en consecuencia la vista general central y la configuración automática.

Las funciones de certificados y MCP también requieren una decisión sobre el producto en lugar de una activación global. En el caso de DNS-01, la competencia sobre la zona determina su utilidad práctica. En el caso de MCP, la conexión técnica es solo una parte del proyecto; lo determinante es el grupo de personas autorizadas, los procesos trazables y el tratamiento de las acciones con efectos secundarios.

Diagnóstico de DNS y certificados en el servicio de asistencia

La versión de Plesk Obsidian 18.0.81, ya disponible para el público general Diagnóstico genético Es adecuado como primera evaluación técnica de un ticket de dominio. En el panel, la opción „Troubleshoot DNS“ abre un informe claro sobre la resolución de DNS, las comprobaciones relacionadas con los registros MX, el DNSSEC, los problemas con los servidores de nombres y la fecha de caducidad del dominio. Esto agiliza la comprobación preliminar, pero no sustituye ni al análisis de la zona autoritativa ni a la coordinación con el registrador o el operador de DNS externo.

Para garantizar un proceso de primer nivel repetible, el servicio de asistencia debería registrar en primer lugar el dominio principal afectado y el informe, y a continuación asignar la competencia y la naturaleza de la anomalía. Si el informe indica, por ejemplo, una delegación errónea, la corrección suele quedar fuera del ámbito de competencia del panel. También es importante tener en cuenta la limitación documentada: los alias de dominio no están incluidos actualmente en esta comprobación.

Para el diagnóstico desde la línea de comandos, el registro de cambios documenta la siguiente llamada con un dominio de ejemplo neutro. Antes de utilizarla, el administrador debe consultar la ayuda o la documentación de los comandos de la versión de Plesk realmente instalada. A partir de la sintaxis indicada en el registro de cambios no se puede deducir por sí sola ninguna garantía adicional sobre todas las repercusiones del comando.

plesk repair dns -n -j -check-resolution example.com

Ampliado en el caso de los certificados Validación DNS-01 El ámbito de aplicación posible: en Plesk Obsidian 18.0.81, puede utilizar SSL It! como alternativa a la validación HTTP para la emisión y la renovación. Esto resulta relevante, por ejemplo, para dominios de API o de correo electrónico en los que el puerto 80 no está abierto de forma deliberada. Plesk muestra los registros DNS necesarios y guarda el método seleccionado para cada dominio de cara a futuras renovaciones.

Sin embargo, el proceso no se completará automáticamente con éxito solo porque se muestre un registro. El administrador necesita acceso de escritura a la zona DNS realmente correspondiente o una vía de automatización configurada adecuadamente. Según el registro de cambios, la validación de DNS introducida con la versión 18.0.81 solo se aplica a las integraciones «ext-acme» y «ext-letsencrypt» de SSL It!, y no de forma generalizada a todos los proveedores de certificados.

Por otra parte, está la actualización de ampliación posterior SSL It! 1.24.0 del 29 de septiembre de 2026. Con esta versión, es posible proteger un dominio sin alojamiento mediante el panel de control o la línea de comandos con un certificado comodín; la renovación automática también se realiza con un certificado comodín. Esta incorporación no forma parte del conjunto de funciones original de Plesk Obsidian 18.0.81, sino que sigue su propio estado de versión y publicación de la extensión.

El alojamiento de aplicaciones como opción tarifaria controlada

Con las últimas ampliaciones, el alojamiento de aplicaciones se puede diferenciar mejor como opción de tarifa. El Node.js Toolkit 2.5.0 ofrece una vista general centralizada de las aplicaciones Node.js activadas y una configuración con un solo clic de los proyectos existentes. Además, la extensión es compatible con el gestor de paquetes pnpm en Plesk para Linux. De este modo, un proveedor puede estandarizar las tareas de configuración recurrentes sin tener que tratar cada aplicación del cliente como un servidor independiente.

Según el registro de cambios, la detección de proyectos incluye, entre otros, Express, Next.js, NestJS y Nuxt.js, así como interfaces estáticas basadas en React, Vue.js, Angular o Vite. Plesk puede crear un archivo de inicio compatible con Passenger, tener en cuenta los puertos codificados de forma fija y configurar la raíz de documentos, mostrando los cambios antes de su confirmación. Las interfaces front-end estáticas se compilan y se entregan sin necesidad de un proceso Node.js en ejecución permanente.

Esta automatización es útil, pero no sustituye a una revisión de la arquitectura. Varios procesos, colas de trabajadores, proxies inversos especiales, secretos externos o canalizaciones de compilación propias pueden requerir reglas de funcionamiento adicionales. Según el registro de cambios, la restricción de Linux se aplica expresamente a pnpm; en cuanto a la vista general centralizada de dominios y la configuración automática con un solo clic, no se indica allí ninguna restricción de plataforma correspondiente. Por lo tanto, las descripciones de las tarifas deberían mencionar estas subfunciones por separado.

La extensión de Python 1.0.0 ofrece en Linux una configuración gestionable de forma independiente por dominio. Los clientes pueden crear entornos virtuales, instalar dependencias a través de la interfaz, consultar metadatos de pyproject.toml y gestionar variables de entorno, así como secretos almacenados de forma cifrada. La activación se realiza a través del permiso „Gestión de soporte de Python“ en los planes de servicio y las suscripciones.

Técnicamente, estas aplicaciones se ejecutan como Aplicaciones WSGI a través de Phusion Passenger; Plesk genera automáticamente la configuración del servidor web. Por lo tanto, un plan „Python Web App“ puede incluir, por ejemplo, entornos virtuales, un marco de recursos definido y soporte para proyectos WSGI clásicos. Esto no implica que dicho plan cubra pilas ASGI complejas, trabajadores en ejecución permanente o arquitecturas especiales en contenedores.

Para conocer las funciones anteriores y los cambios en la interfaz, puede consultar el artículo Plesk Obsidian: resumen de las novedades y mejoras se pueden utilizar como complemento. En el caso de las nuevas tarifas, sigue siendo fundamental documentar conjuntamente la versión ampliada, los límites documentados de la plataforma, los permisos y el tipo de aplicación que se admite concretamente.

Implementar las actualizaciones de forma escalonada en el entorno de producción

En el entorno de un proveedor de alojamiento, la actualización del panel de control no debería iniciarse con el primer clic en el servidor principal en producción. Primero, crea un Inventario de las versiones de Plesk, las versiones del sistema operativo, las extensiones activadas y las aplicaciones de los clientes que se ejecutan en ellas. También son importantes las dependencias externas, como los proveedores de DNS, los servidores de retransmisión de correo, las copias de seguridad, los paquetes PHP propios y los procesos de implementación. De este modo, se puede ver qué sistemas tienen el mismo estado y qué casos especiales deben tratarse por separado.

A continuación, comprueba las dependencias según cada clase de servidor. Una actualización de un producto principal puede tener consecuencias diferentes a las de una actualización de una extensión o de un componente de terceros. Los paquetes proporcionados por el sistema operativo también constituyen un ámbito de mantenimiento independiente. Plesk distingue expresamente estas categorías; en particular, las actualizaciones de componentes de terceros pueden afectar a los sitios web si estos no están preparados para versiones modificadas o entornos de ejecución diferentes.

A continuación, se recomienda realizar una encuesta representativa Iniciativa piloto en lugar de cualquier servidor de pruebas. Debe reflejar las configuraciones típicas de las tarifas: por ejemplo, sitios web con CMS clásicos, dominios de correo electrónico, uso de bases de datos, así como aplicaciones activadas de Node.js o Python, en caso de que se ofrezcan. El objetivo no es simular una igualdad total con el entorno de producción, sino hacer visibles de antemano las combinaciones relevantes de sistema operativo, extensiones y aplicaciones de los clientes.

Establece una ventana de mantenimiento con un orden claro para la implementación en producción. Actualiza primero un grupo limitado de servidores, evalúa los resultados y solo entonces amplía la implementación. A continuación, comprueba la accesibilidad del panel de control, las copias de seguridad programadas, los servicios web y de correo electrónico, las renovaciones de certificados y los mensajes de error de las aplicaciones afectadas. Estas comprobaciones reducen la incertidumbre, pero no garantizan la ausencia de fallos ni la compatibilidad total de las aplicaciones.

Para la planificación de la capacidad, Plesk recomienda unos valores mínimos de 1 GB de RAM más 1 GB de espacio de intercambio en Linux y 2 GB de RAM en Windows. Para el alojamiento compartido, se recomienda, a título orientativo, 1 GB de RAM por cada 40 a 50 sitios web, siempre que como máximo el diez por ciento de todos los sitios web alojados tengan un número constante o regular de visitantes por semana o por mes. Dichos Valores de referencia de recursos No constituyen una garantía de capacidad ni sustituyen a una medición de la propia carga: la actividad de la base de datos, el volumen de correo electrónico, el software de seguridad y el tipo de aplicación pueden modificar considerablemente las necesidades.

Identificar fuentes de error y prioridades de seguridad

Los errores recurrentes suelen deberse a límites imprecisos de los productos. Por eso, en cada anuncio, documenta la versión concreta del producto principal o de la extensión. Una función de Node.js o Python no debe promocionarse de forma generalizada para los planes de Windows si solo está documentada para Plesk para Linux. Del mismo modo, el alojamiento de Python con WSGI a través de Passenger no equivale a la compatibilidad con cualquier arquitectura ASGI, de trabajadores o de contenedores.

• No incluya DNS-01 como característica de la tarifa hasta que disponga de acceso de escritura a la zona DNS autoritativa o de una vía de automatización adecuada.
• No hay que confundir las opciones de actualización automática de Plesk, de componentes de terceros y de paquetes del sistema; comprueba la configuración real de cada servidor en „Herramientas y configuración > Configuración de actualizaciones“.
• Comprueba las ampliaciones, los permisos y los sistemas operativos antes de activar nuevas funciones en cada línea de productos.
• Definir los grupos de usuarios permitidos, los procesos de autorización y el registro de acciones para MCP antes de la autorización de un rol.

El Prioridad de seguridad no depende únicamente de la conveniencia de la ventana de mantenimiento. A la fecha de publicación de este artículo, Plesk Obsidian 18.0.81 Update 2, del 29 de septiembre de 2026, es la versión actual documentada de esta línea de versiones principales; Plesk señala un problema de seguridad crítico al respecto y recomienda su instalación lo antes posible. La Actualización 1, del 21 de septiembre, también incluía una corrección de seguridad crítica que se menciona expresamente en el registro de cambios para Linux. Por lo tanto, en los sistemas Linux no se debe permanecer en la Actualización 1.

El registro de cambios también incluye, en septiembre, correcciones de seguridad críticas para Node.js Toolkit 2.5.0, del 14 de septiembre de 2026, y Site Import 1.12.2, del 23 de septiembre de 2026. Por lo tanto, comprueba siempre si el componente en cuestión está instalado y trata el núcleo del Panel, las extensiones, los paquetes PHP y otros complementos como rutas de actualización independientes. Una actualización posterior de una extensión o de PHP no sustituye a una actualización pendiente del producto principal.

MCP obtiene unos ingresos limitados Funcionamiento piloto en lugar de una activación inmediata y generalizada. La función está desactivada de forma predeterminada; los administradores pueden, en panel.ini Establece qué tipos de usuarios pueden conectarse a los clientes MCP. Define de antemano qué tareas deben ser compatibles, quién puede revisar los cambios y cómo se van a rastrear las acciones sospechosas o no deseadas. Una integración de IA no sustituye ni a los modelos de roles, ni a la gestión del cambio, ni a las revisiones técnicas.

Advertencia: los componentes de terceros no deben instalarse de forma incontrolada en todos los entornos de los clientes solo porque haya una versión más reciente disponible. Plesk advierte de posibles incompatibilidades con los sitios web alojados; al mismo tiempo, la página de documentación actual contiene información contradictoria sobre si la función automática correspondiente está activada de forma predeterminada. Por lo tanto, comprueba en cada servidor en Tools & Settings > Update Settings las opciones establecidas y planifica una implementación gradual para los plazos y complementos más habituales con un grupo piloto representativo.

Decidir entre una actualización o una transferencia de servidor

La elección entre Actualización in situ y la transferencia del servidor comienza con el estado actual, no con la versión deseada de Obsidian. Una actualización en el mismo servidor requiere que el sistema operativo y la versión inicial de Plesk instalada sean compatibles con la ruta prevista. Comprueba además las extensiones utilizadas, las personalizaciones propias y el espacio disponible para las copias de seguridad. El hecho de que una ruta de actualización sea técnicamente posible no garantiza que sea adecuada para todos los entornos de los clientes.

En la documentación sobre actualizaciones de Plesk Onyx se indican rutas directas a Obsidian para las versiones 17.0, 17.5 y 17.8. Los entornos de origen más antiguos o que no cuenten con la compatibilidad adecuada pueden requerir una transferencia a un nuevo servidor Obsidian, siempre que la versión de origen sea migrable. La transferencia permite preparar el sistema operativo, la distribución de recursos y el conjunto de extensiones de forma independiente del sistema antiguo.

Es especialmente recomendable evaluar un nuevo servidor de destino cuando el sistema operativo actual llega al final de su soporte técnico, la plataforma ha sido personalizada durante mucho tiempo o se producen varios saltos importantes de versión. Los requisitos del sistema de Plesk solo proporcionan el límite mínimo para la planificación. A la hora de determinar el tamaño del servidor de destino, también hay que tener en cuenta el número de sitios web, los buzones de correo, las bases de datos, los servicios de seguridad, el almacenamiento de copias de seguridad y la carga prevista tras la migración.

En Actualización mediante transferencia El entorno actual se trasladará a un servidor en el que esté instalado Plesk Obsidian. Según la documentación de actualización, es imprescindible que el sistema operativo del servidor de destino sea compatible y que la versión inicial instalada permita la migración a Obsidian. Por lo tanto, antes de planificar la actualización, conviene comprobar si esta opción está disponible en función de la versión de origen concreta.

Para contar con una instalación actualizada, compatible y fácil de gestionar, lo más habitual es aplicar los parches de forma oportuna tras realizar un inventario y una fase piloto. En el caso de nuevas ampliaciones o funciones específicas de Linux, resulta recomendable llevar a cabo una fase piloto específica. Si la compatibilidad del sistema operativo, la versión inicial o los problemas técnicos heredados limitan el proceso, se debería realizar primero una Preparado para la migración . La variante adecuada viene determinada por el estado del soporte técnico, la compatibilidad y el modelo operativo, y no por una autorización general para su uso en producción.