Hace un tiempo me encontré con una pregunta que no podía sacarme de la cabeza: ¿y si armo mi propio hosting de WordPress? No uno genérico, no uno sobrecargado con cPanel y mil opciones que nadie usa, sino algo simple, veloz, barato y que esté realmente optimizado para gente que quiere empezar su blog, su sitio, su tienda. Así nació SenseiPress.
No soy bueno con las ideas creativas, no se me ocurren cosas que me apasionen y sean únicas, pero ¿un hosting de WordPress? Es algo que me resultaría útil a mí, algo que armándolo voy a aprender un montón, y algo que potencialmente a alguien le pueda resultar útil.
🧪 La idea y el primer prototipo
La realidad es que mucho de hostings de WordPress en particular no sé, pero sí he migrado varios sitios, propios y ajenos, y siempre tuve buenos resultados. La receta: Linux, PHP-FPM y Nginx. Hace poco metí un ingrediente nuevo, Docker.
Entonces, dije, ¿por qué no automatizo mis procesos de deployments, que funcionan rápido y armo un hosting encima? Seguro se puede. Además, puedo cobrarlo una fracción de lo que sale la VPS, sería barato y va a tener buen performance. Así que decidí armar un pequeño prototipo.
Arranqué con dos VPS. Uno hace de load balancer, y la otra es la primera de varios pools de WordPress, cada uno capaz de correr hasta 5 instancias en Docker, todas aisladas y usando una base de datos MariaDB compartida.
Para no exponer puertos innecesarios, toda la comunicación entre instancias se da dentro de una intranet privada. Cada usuario recibe su subdominio y el load balancer se encarga de redirigir todo como corresponde. El load balancer, no es más que un server en Caddy que redirige según subdominios a distintas IPs internas. ¿Por qué Caddy y no Nginx? Porque Caddy tiene una API REST, con lo cual con un poco de configuración desde un servidor puedo agregar y quitar reglas. Además tiene provisión automática de SSL, con lo cual me olvido de Certbot. Un alivio.
⚙️ Lo que hay debajo del capó
Toda la infra corre en contenedores Docker, obviamente con sus adecuados volúmenes para poder particionar el espacio y también la persistencia de datos. En la VPS principal, tenemos 4 piezas fundamentales.
- El server Caddy (responsable de dirigir el tráfico externo hacia el interno - pensá tusub.senseipress.com -> el sitio WordPress)
- El dashboard en Next.js, la cara visible de la página senseipress.com, el admin panel de los usuarios y todo lo relacionado a manejo de la página. Esto tiene su propia base de datos en SQLite.
- Una pequeña API en Go, que con validaciones y seguridad permite exponer ciertos endpoints controlados al backend de Next para delegar subdominios y manejar las reglas de tráfico interno
- Una instancia de HAProxy para, según el puerto que se elija, redirigir tráfico SFTP hacia el WordPress necesario. Esencialmente, me permite entrar por SFTP en la VPS_1 y llegar a la instancia correspondiente por la intranet.
En las VPS_Pools como le llamo yo, vamos a tener
- Instancias de WordPress, la cantidad va a depender del tier. Cada instancia está particionada en volumen y es su propia imagen de Docker con su propio puerto.
- Base de datos en MariaDB
- Una API en Go que permite a través de HTTP manejar de forma fina distintas acciones sobre los contenedores de Docker. Desde migrar sitios, hacer backups, cambiar contraseñas del admin, reset de fábrica y demás.
Y no mucho más que eso. Así y todo parece poco, pero son líneas y líneas de código en scripts, endpoints y automatizaciones para poder crear el siguiente flujo:
- Usuario elige subdominio (en app Next.js, se guarda en SQLite)
- El subdominio se registra en Caddy gracias a la API Go
- Se le asigna un WordPress libre (en alguna de las intranet, esta instancia es virgen y está lista para usar). Si no hay instancias libres, se despliega una nueva VPS, se instala todo de 0 y luego se asigna. Si pasa esto, como mucho hay una demora de 2 minutos. Si no pasa esto, asignar un sitio es algo de 2 segundos. Se puede optimizar (adelantarse para nunca tener instancias llenas, pero esto sería un NTH)
- Listo en realidad - no queda más para hacer. Desde el dashboard de SenseiPress, podés asignar tu dominio si ya tenés uno, solo necesitás un CNAME (la regla más fácil) en el dashboard de tu proveedor y ya.
🖥 El dashboard de SenseiPress
Como mencioné, el frontend lo armé con Next.js y una base SQLite (mejor rendimiento y más simple para este MVP). Incluye:
- Páginas de marketing.
- Paneles de usuario para ver sus sitios, hacer backups, y más.
- Panel de admin para gestionar despliegues, recursos y copias de seguridad.
Todas las acciones:
Son en realidad comunicaciones vía HTTP a la API en Go que vive en la misma VPS de los WordPress. Y esto se ejecuta a través del server de Next.js - no es una comunicación directa entre el front de Sensei y la pool asociada.
💸 Planes y precios
Para el lanzamiento, tengo pensado:
- Plan base a $3999 pesos por mes.
- 10 cuentas gratuitas para testear y recibir feedback.
- Un plan avanzado a $9999/mes con más recursos.
- Precios anuales con descuento.
🧠 Lo que estoy mejorando ahora
- Monitoreo de recursos: expandiendo
docker-memory-apipara que sea más detallado. - Backups confiables: de la data del WordPress y también de las configs de Caddy.
- Mejoras al dashboard: sobre todo en facturación y descarga de backups.
- Alertas por mail: para eventos críticos o notificaciones automáticas.
El desafío más grande
Lo que más me cuesta ahora es cambiar el chip de programador a marketing, empezar a armar una buena landing y preparar todo para la venta. Tengo muchas cosas para hacer ahí, mucho que publicitar, leads que buscar. Pero el producto base está, funciona, lo que aprendí no tiene nombre.
Seguime en x.com para más updates
