WordPress mueve una parte enorme de la web y, aun así, alojarlo bien en un servidor propio sigue siendo más artesanal de lo que debería. Quien sale del hosting compartido suele acabar en una de tres casillas: un panel clásico tipo cPanel o Plesk con licencia por cuenta, un panel gratuito generalista que no sabe nada de WordPress, o un servicio en la nube que gestiona tu VPS desde fuera y te cobra por servidor. WPL7 intenta ocupar una cuarta: un panel que solo hace WordPress, que vive entero en tu servidor y que no cuesta nada.
Lo hemos revisado leyendo el código y la documentación del repositorio, no solo la web comercial, porque en un proyecto con un mes de vida la diferencia entre lo que se promete y lo que está escrito importa.
El proyecto lo publica en GitHub un desarrollador que firma como Andy (andyfo), con una empresa detrás radicada en la República Checa, según se deduce de las condiciones de pago de su web. El repositorio nació el 4 de octubre de 2026, la primera beta pública salió el 8 y la última versión estable, la 0.3.2, el 21 de octubre. Existe además un canal edge que se reconstruye con cada cambio en la rama principal; el último, del 29 de octubre.
El código es mayoritariamente TypeScript (el panel: un proceso Node con una interfaz en React y una base de datos SQLite), con PHP para los plugins auxiliares que instala en los sitios y Shell para el aprovisionamiento. A la hora de escribir esto tiene siete estrellas y dos forks: es un proyecto que acaba de nacer, no uno con comunidad.
La licencia es AGPL-3.0-only, y el README la explica sin rodeos: puedes usarlo para ti o para tus clientes y modificarlo sin publicar los cambios. La obligación de publicar el código solo se dispara si ofreces el propio panel modificado como servicio a terceros. Alojar webs de clientes es usar WPL7, no ofrecerlo. El nombre y el logotipo quedan fuera de la licencia: un fork puede decir que está «basado en WPL7», pero no llamarse así.
La arquitectura es sencilla de contar y está bien pensada en los detalles que suelen fallar:
| Pieza | Qué es | Para qué |
|---|---|---|
| Traefik v3 | Proxy inverso en los puertos 80 y 443 | TLS con Let’s Encrypt y enrutado por etiquetas de Docker |
wp-<sitio> | Un contenedor por web, imagen oficial wordpress:php8.x-apache + msmtp + WP-CLI | El sitio, con su PHP y su configuración |
| MariaDB 11.4 | Una instancia por servidor, una base de datos y un usuario por sitio | Datos de WordPress |
| Postfix + DKIM | Relé de correo con una credencial por sitio | Que wp_mail() funcione y salga firmado |
| Panel | Node + SQLite, con acceso al socket de Docker y a /srv | Gestión, trabajos programados, API y MCP |
Lo interesante está en la red. Docker aísla entre redes, no dentro de ellas: si todos los sitios comparten un bridge, un WordPress comprometido puede abrir conexiones directas al Apache de sus vecinos, saltándose el proxy, y llegar al puerto del panel. WPL7 crea una red interna por sitio cuyos únicos otros miembros son Traefik, MariaDB y el relé de correo. La salida a Internet, que WordPress necesita para actualizarse, va por una red compartida creada con la comunicación entre contenedores desactivada, de modo que el núcleo descarta el tráfico de un sitio a otro y deja pasar el que sale fuera.
La documentación reconoce el precio de ese diseño: cada sitio consume un /24 del rango de direcciones de Docker y una interfaz en el proxy, la base de datos y el relé. Va holgado hasta unas decenas de sitios; pasados los cien por servidor hay que ampliar el rango y asumir tablas de iptables grandes. Es un dato honesto que pocas herramientas publican.
Otro detalle de los que delatan oficio: el cron de WordPress se desactiva y el panel ejecuta wp cron event run --due-now en cada sitio cada cinco minutos, en lugar de depender de que entre una visita.
Un sitio nuevo arranca en segundos en una dirección de desarrollo (<sitio>.dev.tudominio.com, cubierta por un certificado comodín) y el botón Go live lo pasa al dominio del cliente, con hasta diez dominios por sitio y sin corte. Hay acceso a wp-admin con un clic, gestor de archivos en el navegador, cuentas FTP y SFTP por sitio (a través de un contenedor que solo monta la carpeta de ese sitio), estadísticas de visitas sin cookies e importación desde otro hosting mediante un plugin de migración propio. Las webs alojadas en otro sitio pueden conectarse al panel con un plugin conector para gestionarlas desde el mismo sitio.
Es probablemente la función que más tiempo ahorra a una agencia. Una tabla reúne todos los plugins, temas y versiones de WordPress de todos los sitios, con cuántos sitios usan cada uno, si hay actualización y si tiene vulnerabilidades conocidas. Se puede filtrar por vulnerables, con actualización, inactivos o cerrados en wordpress.org, y lanzar la actualización en lote: un trabajo por sitio, servidores en paralelo, copia previa opcional y una comprobación de que cada web sigue respondiendo después.
Lo que todavía no hace, y la documentación lo lista: avisar por correo de una vulnerabilidad crítica nueva, posponer una actualización por sitio, instalar plugins en lote desde el catálogo o restaurar sola la copia cuando falla la comprobación de salud. Hoy eso último te lo indica y lo haces tú.
Las «recetas» resuelven una molestia muy concreta: los plugins premium que hay que activar con una licencia en cada sitio. Se introduce la clave una vez y el panel la activa en los sitios nuevos, la mueve cuando cambia el dominio y la libera al borrar la web. Sirven también para cualquier paso de WP-CLI o PHP, como vaciar la caché de un maquetador tras un cambio de dominio. Vienen recetas firmadas para ACF PRO y Breakdance, y se pueden escribir otras en un JSON.
Cada copia son ficheros normales: db.sql.gz (volcado con --single-transaction, sin bloqueos), files.tar.gz, un manifiesto y las sumas SHA-256, que se verifican antes de cada restauración. Por defecto hay copia diaria a las 03:00 (hora del servidor, normalmente UTC) y se guardan las diez últimas; además se toman copias automáticas antes de restaurar, antes de actualizar si se configura, al mover un sitio de servidor y al borrarlo.
Las copias externas usan rclone contra S3 y compatibles, SFTP, FTP o WebDAV, con cifrado opcional (apagado por defecto). Y hay una sección que nos gusta especialmente: cómo restaurar sin el panel, a mano, incluso desde un bucket cifrado. Un sistema de copias que solo sabe restaurar su propio software no es un sistema de copias.
wp_mail() funciona sin plugin SMTP. Cada sitio tiene su credencial contra un relé Postfix que firma con DKIM, y el relé rechaza cualquier remitente de un dominio que pertenezca a otro sitio: una web comprometida no puede mandar phishing firmado en nombre de otro cliente. Si un sitio supera un umbral de abuso, se le corta el envío y se avisa por correo. El panel incluye una guía que comprueba SPF, DKIM y DMARC contra el DNS real.
El propio proyecto pide configurar un smarthost (SMTP_RELAYHOST) antes de meter tráfico real, y tiene razón: el envío directo desde la IP de un VPS recién estrenado choca con los requisitos de Gmail, Outlook y compañía, algo que ya contamos en entregabilidad del correo desde servidor propio.
Tres capas, encendidas por defecto:
.htaccess, por ejemplo) desactiva una protección.La lista de límites conocidos es de lo más útil del proyecto, porque nadie la escribe: no inspecciona el cuerpo de las peticiones (un exploit por POST se para por su ruta o no se para), no busca malware en la base de datos (y una puerta trasera que se reescribe desde ella vuelve tras la cuarentena), los plugins premium no tienen sumas publicadas contra las que comparar, la detección tarda unos dos minutos y, si Docker no tiene IPv6 configurado, todos los visitantes por IPv6 llegan como una sola dirección privada y no se pueden limitar uno a uno.
Un panel puede gobernar varios servidores. El primero aloja el panel y sitios; los demás ejecutan la misma pila sin el panel, y se dan de alta desde la interfaz sobre un VPS en blanco, que el panel aprovisiona por SSH con la huella del host fijada en la primera conexión. Cada sitio es completamente local a su servidor (ficheros, base de datos, correo y certificados), así que si cae un servidor solo caen sus sitios, y si cae el panel solo se pierde la gestión. Los sitios se pueden mover entre servidores.
Dos límites a tener en cuenta: restaurar en otro servidor solo funciona a través de una copia externa, y como todos los servidores piden el mismo certificado comodín, Let’s Encrypt permite dar de alta como mucho cinco por semana.
Todo lo que hace el panel pasa por una API REST con claves de tres niveles (solo lectura, gestión y completo). Encima hay un servidor MCP en https://<panel>/mcp para que un asistente de IA (Claude, ChatGPT, Cursor, VS Code) opere el panel: listar la flota, crear sitios, actualizar plugins, restaurar una copia. Viene apagado, se conecta por OAuth o con una clave, el administrador elige el nivel de acceso y cada llamada pasa por la misma API, la misma cola de trabajos y los mismos registros. La web enseña el caso de uso que vende: una frase pide actualizar todos los sitios con un plugin vulnerable, y el panel comprueba 24, copia y actualiza los 8 afectados y verifica que responden.
Es cómodo y está bien acotado, pero conviene leerlo con frialdad: un asistente con nivel completo puede borrar y restaurar sitios en producción. El nivel de solo lectura es el punto de partida razonable.
El proyecto dedica una sección entera a qué pasa cuando se compromete un sitio, que es lo que de verdad le ocurre al WordPress autoalojado. El contenedor afectado:
NET_RAW y con no-new-privileges;Y lo que sigue compartiendo con sus vecinos, dicho por el propio proyecto: el núcleo del sistema, la instancia de MariaDB, el disco y la reputación de la IP. Un escape del contenedor o un compromiso de MariaDB afectan a todo el servidor. Entre servidores distintos no hay credenciales cruzadas.
La otra cara es el panel: tiene el socket de Docker y una clave SSH de root en los servidores de la flota. Es equivalente a root por diseño, y no hay roles menores para personas: todas las cuentas son de administrador completo, con segundo factor opcional. Eso descarta darle acceso al cliente final y obliga a tratar cada cuenta y cada clave de API como una shell de root.
| Requisito | Detalle |
|---|---|
| Sistema | Ubuntu 26.04 x86-64, recién instalado; el instalador se para en ARM |
| Memoria | 2 GB para empezar; por debajo de 4 GB añade 2 GB de swap |
| Red | IPv4 pública, puertos 80 y 443 abiertos (Let’s Encrypt valida por el 80) |
| DNS | Dos registros A: panel.tudominio y el comodín *.dev.tudominio |
| Salida a Internet | GitHub, ghcr.io, Docker Hub y los repositorios de Ubuntu y Docker |
| Exclusividad | Se queda con la máquina entera: instala Docker, UFW y una tabla de nftables |
La instalación es una línea con curl | sudo bash y tres parámetros (dominio del panel, dominio de desarrollo y correo para ACME). Nuestra recomendación es la de siempre: descargar install.sh, leerlo y fijar la versión antes de ejecutarlo como root, que es exactamente lo que la guía de instalación del proyecto también sugiere. Y aplicar antes la línea base de endurecimiento que se le exige a cualquier servidor expuesto.
Las actualizaciones del panel se hacen desde Ajustes → Actualizaciones, con comprobación de salud y vuelta atrás automática si la versión nueva no arranca bien. Aun así, el proyecto insiste en hacer copia antes de cada actualización y leer las notas: en la serie 0.x pueden cambiar la API y las claves del .env.
El software es gratuito, completo y sin clave de licencia: sin cobro por sitio ni por servidor. El proyecto vende dos servicios opcionales, con precios publicados en euros sin IVA:
| Servicio | Precio | Qué incluye |
|---|---|---|
| Código abierto | 0 € | Todo el panel, ayuda de la comunidad (documentación, issues, foro) |
| Instalación gestionada | 440 € una vez | Revisión del servidor, instalación, DNS, certificados, correo, copias con un destino externo y el primer sitio |
| Soporte prioritario | 84 €/mes u 840 €/año | Ayuda por correo con prioridad, actualizaciones, correcciones y recetas a medida; una suscripción por panel |
Es el modelo habitual del software libre con empresa detrás. La pregunta que hay que hacerse es la de siempre con un proyecto de un solo mantenedor: qué pasa si lo deja. Aquí la respuesta es razonable, porque las webs son contenedores con la imagen oficial de WordPress, la base de datos es MariaDB y las copias son ficheros normales que se restauran sin el panel.
El mercado de paneles es amplio y cada uno resuelve un problema distinto. Esta es la foto a 1 de noviembre de 2026, con licencias y versiones comprobadas en sus repositorios:
| Panel | Licencia | Enfoque | Aislamiento por sitio | Dónde vive el panel |
|---|---|---|---|---|
| WPL7 (0.3.2) | AGPL-3.0, gratuito | Solo WordPress, flota de servidores | Contenedor y red propios | En tu servidor |
| CloudPanel (2.5.4) | Gratuito, código no publicado | PHP, Node.js, Python y estáticos sobre NGINX | Usuario de sistema y PHP-FPM | En tu servidor |
| HestiaCP (1.10.5) | GPL-3.0 | Hosting clásico: web, correo, DNS, FTP | Usuario de sistema | En tu servidor |
| CyberPanel | GPL-3.0 | Hosting sobre OpenLiteSpeed, muy orientado a WordPress | Usuario de sistema | En tu servidor |
| WordOps (3.23.1) | MIT | WordPress con NGINX desde la línea de comandos | Usuario de sistema | Sin panel web |
| Coolify (4.5.3) / Dokploy (0.30.10) | Apache-2.0 (Dokploy con una parte propietaria) | PaaS genérico; WordPress es una plantilla más | Contenedor | En tu servidor |
| Enhance | Comercial, cobro por web al mes | Hosting multiservidor para proveedores | Contenedores | En tu servidor |
| SpinupWP, RunCloud, Ploi, GridPane | Comercial, suscripción | Gestión de WordPress o PHP en tu VPS | Varía | En la nube del fabricante |
Leída la tabla, el hueco de WPL7 está claro. Los paneles clásicos gratuitos (HestiaCP, CyberPanel, CloudPanel) separan los sitios por usuario del sistema y comparten servidor web y PHP; son más maduros, tienen años de uso y comunidad, y algunos cubren cosas que WPL7 no toca, como servidor de correo entrante o DNS propio. HestiaCP sigue siendo la opción natural si se necesita un hosting completo de toda la vida, con buzones incluidos.
Los PaaS como Coolify y Dokploy aíslan en contenedores igual que WPL7, y con muchísima más comunidad (decenas de miles de estrellas), pero WordPress es para ellos una plantilla entre cientos: no hay inventario de plugins, ni vulnerabilidades, ni escaneo contra las sumas de wordpress.org, ni recetas de licencias. Son la herramienta adecuada si en el mismo servidor conviven WordPress, una API en Node y un Postgres.
Los gestores en la nube (SpinupWP, RunCloud, Ploi, GridPane) son los que más se parecen a WPL7 en lo que ofrecen al usuario, y la diferencia es de arquitectura y de soberanía: el plano de control está en su nube, tienen acceso a tu servidor y dependes de su suscripción. WPL7 es lo mismo sin intermediario: ni cuota mensual ni un tercero con llaves de tus máquinas. Para una agencia europea con clientes sujetos al RGPD, que la herramienta de gestión no salga de su infraestructura no es un detalle menor.
Enhance es el pariente comercial más cercano en arquitectura (contenedores, multiservidor, herramientas de WordPress incluidas) y está pensado para proveedores de hosting con miles de webs y clientes con su propio acceso, que es justo lo que WPL7 no ofrece.
Encaja en una agencia o un profesional independiente que mantiene entre unas pocas y unas decenas de webs de clientes, quiere dejar de pagar por sitio, valora el aislamiento por contenedor y gestiona él mismo las webs. También en quien ya opera servidores Linux y quiere un panel que se lea en un fin de semana.
No encaja si se necesita que el cliente final entre en su propio panel (no hay roles), si se busca correo entrante o DNS autoritativo en la misma máquina, si la flota corre en ARM, si la empresa no puede asumir software en beta con un solo mantenedor o si no hay nadie en casa capaz de diagnosticar Docker y Traefik cuando algo se tuerza. En esos casos, un panel clásico maduro o un hosting gestionado siguen siendo mejor apuesta.
Si un cliente nos pidiera alojar sus webs con WPL7, lo plantearíamos así:
¿WPL7 es gratis de verdad? Sí. El panel completo es software libre AGPL-3.0, sin cobro por sitio ni por servidor. Solo se pagan, si se quieren, la instalación gestionada o el soporte prioritario.
¿Puedo usarlo para vender hosting a mis clientes? Puedes alojar sus webs sin ninguna obligación de licencia. Lo que no tiene es acceso para el cliente final: todas las cuentas del panel son de administrador completo, así que está pensado para que la agencia gestione, no para revender cuentas.
¿En qué se diferencia de Coolify o Dokploy? Los tres aíslan en contenedores, pero Coolify y Dokploy son plataformas genéricas para cualquier aplicación. WPL7 solo hace WordPress y a cambio sabe de plugins, temas, vulnerabilidades, licencias premium, correo de WordPress y malware.
¿Está listo para producción? El propio proyecto lo declara beta (0.x): aloja sitios reales y cada cambio pasa antes por el servidor del mantenedor, pero la API puede cambiar y solo se da soporte a la última versión. Para producción, con copias externas, instantánea previa a cada actualización y alguien que conozca Docker.
¿Funciona en un servidor ARM o en Debian? No por ahora. Solo admite Ubuntu 26.04 en x86-64 y el instalador se detiene en ARM.
docs/architecture.md, docs/security.md, docs/operations.md, docs/backup-restore.md, docs/mail.md, docs/multi-server.md, docs/mcp.md, docs/install.md, docs/updates.md) y TRADEMARK.md: github.com/andyfo/wpl7.¿Gestionas decenas de webs de clientes y quieres sacarlas del hosting compartido sin perder el control? En Cloud Privado desplegamos máquinas virtuales y servidores bare-metal en centros de datos en España, con copias en otra ubicación y servicios gestionados si prefieres que nos ocupemos de la capa de sistemas. Mira cómo trabajamos con agencias de marketing digital o hablemos de tu proyecto.
Hasta ahora, cuando Cloud DNS reenviaba consultas a un resolver de tu centro de datos o de otra nube, llegaban desde 35.199.192.0/19, un rango de Google que había que enrutar y abrir en el cortafuegos. Los nuevos Outbound Endpoints, en Preview, hacen que salgan de una subred privada que eliges tú. Qué cambia, qué no, cómo se compara con AWS y Azure y qué hay que tocar en el otro extremo.
ZFS es el mismo código en Linux y en FreeBSD, pero no llega igual al servidor. En FreeBSD forma parte del sistema base; en Linux es un módulo aparte que, por un choque de licencias, cada distribución integra a su manera. Contamos el origen del conflicto, cuánto tarda OpenZFS en soportar cada kernel nuevo (una mediana de 38 días) y qué hace cada plataforma para que la actualización no te deje sin sistema de ficheros.
Cuando una API o una web va lenta, la tentación es subir de plan: más vCPU, más RAM, discos más rápidos. Antes conviene saber qué está frenando de verdad al servidor. Repasamos las seis señales que lo delatan (CPU, memoria, disco, red, límites y latencia de la aplicación), con los comandos para medirlas, cómo leerlos sin engañarse y lo que hemos comprobado en Debian y Ubuntu.