Hay una idea de Stormkit que encaja muy bien con cómo trabajan hoy muchos equipos de producto: conservar la comodidad de una plataforma de despliegue para frontends, pero sin entregar toda la operación a un proveedor externo. Su modo self-hosted permite instalar la plataforma sobre infraestructura propia y gestionar despliegues, logs, hosting, certificados TLS y escalado desde un entorno controlado, con Docker como base de ejecución.
Es un enfoque que tiene sentido para quien construye aplicaciones web modernas —sitios estáticos, proyectos Next.js, frontends de cliente— y al que le importa la velocidad de despliegue, pero también la soberanía del dato, el coste predecible, la ubicación de la infraestructura y poder decidir dónde corre cada carga de trabajo. En lugar de depender siempre de una plataforma SaaS cerrada, Stormkit puede vivir en una máquina dedicada, en un cloud privado o en un cloud público europeo.
La documentación oficial propone una instalación directa mediante un script que instala Docker y Stormkit en la máquina. El comando es sencillo:
curl -sSL https://www.stormkit.io/install.sh | shEl instalador está probado sobre Ubuntu 20, 22 y 24, Debian 11 y 12, Fedora 39 y 40, macOS Sonoma y Rocky Linux 10, y las imágenes Docker son multiplataforma para arquitecturas amd64 y arm64. El proyecto es open source y su código está en GitHub; el paso a paso completo está en su guía oficial de self-hosting.
Stormkit no pretende sustituir a una plataforma Kubernetes completa ni a una estrategia DevOps compleja. Su fuerza está en reducir el trabajo operativo de las aplicaciones frontend: despliegues, logs, hosting, certificados y gestión básica de publicación. Es una capa útil cuando el equipo quiere centrarse en el producto sin renunciar al control de la infraestructura.
El caso más simple es instalar Stormkit en una sola máquina con Docker Compose. La propia documentación recomienda esta opción para despliegues de un único servidor por su sencillez. Para escenarios con más necesidades de escalado o de clustering, Stormkit permite elegir Docker Swarm durante la instalación, o apoyarse en otra herramienta de orquestación si el equipo ya trabaja con una.
| Escenario | Opción recomendada | Motivo |
|---|---|---|
| Laboratorio o proyecto pequeño | Docker Compose en una VM | Instalación simple y operación directa |
| Web corporativa o SaaS pequeño | VM dedicada con backups | Control, coste predecible y despliegue rápido |
| Varios proyectos frontend | Cloud público con varias instancias | Flexibilidad para crecer con la demanda |
| Entorno que exige más control | Cloud privado | Recursos dedicados y aislamiento más fuerte |
| Producción con requisitos altos | Swarm u orquestación externa | Mejor reparto de carga y tolerancia a fallos |
En producción conviene evitar la idea ingenua de “instalar y olvidar”. Un script curl | sh es cómodo para probar, pero en entornos de empresa debería revisarse antes, ejecutarse sobre una máquina limpia, documentarse y acompañarse de políticas de backup, cortafuegos, monitorización, DNS, certificados y actualizaciones. El valor del self-hosting está en tener control, no en improvisar la operación. Esa misma disciplina la defendemos cuando hablamos de contenedores Docker sobre Proxmox: la comodidad no exime de operar con método.
Para empresas que quieren alojar Stormkit con recursos dedicados, aislamiento e infraestructura más predecible, la opción natural es desplegarlo sobre el cloud privado de cloudprivado.com: infraestructura europea con recursos dedicados para cada proyecto y un enfoque centrado en rendimiento, privacidad y control.
Nuestro cloud privado se apoya en Proxmox o VMware, una base ideal para equipos que quieren desplegar Stormkit sobre sus propias máquinas virtuales, controlar redes privadas, separar entornos y mantener una arquitectura cercana a la infraestructura empresarial tradicional. Es justo el terreno del que hablamos al explicar cómo llevar Proxmox a producción en cloud privado.
En un diseño típico, Stormkit correría sobre una o varias VMs Linux dentro del cloud privado. El equipo mantendría entornos separados para desarrollo, staging y producción, con snapshots, backups, cortafuegos, redes privadas y monitorización. Si la organización ya ejecuta cargas críticas en ese cloud privado, Stormkit se convierte en una pieza más de su plataforma interna de despliegue.
La ventaja no es solo rendimiento. Es también gobierno. Un equipo puede decidir dónde viven los proyectos, qué accesos tiene cada persona, qué dominios se publican, cómo se protegen los certificados, cómo se auditan los cambios y qué política de backup se aplica. Para empresas con requisitos de cumplimiento, clientes B2B o proyectos que no quieren quedar atrapados en una plataforma externa, ese control importa —y conecta directamente con por qué la soberanía del dato deja de ser marketing.
No todo proyecto necesita un cloud privado desde el primer día. Para equipos que buscan agilidad, capacidad de crecer rápido y un modelo más flexible, el cloud público soberano de cloudprivado.com encaja como alternativa para desplegar Stormkit en modo self-hosted sin tener que operar hardware ni diseñar una infraestructura totalmente dedicada.
Nuestro cloud público se apoya en OpenStack, la tecnología open source diseñada para gestionar recursos de cómputo, almacenamiento y red a través de APIs. Ese enfoque es útil para Stormkit porque permite crear máquinas virtuales, redes, almacenamiento y recursos de forma flexible: puedes empezar con una instancia para Docker Compose, escalar después a varias máquinas, separar entornos por proyecto o integrar la plataforma con otros servicios cloud. Es un modelo pensado para desplegar servicios digitales, e-commerce, SaaS y aplicaciones en evolución con rapidez.
La diferencia práctica entre elegir cloud privado o cloud público no debería plantearse como una simple competición. Son opciones para necesidades distintas:
Como asesor independiente de infraestructura, en cloudprivado.com no empujamos una tecnología concreta: analizamos tu caso y elegimos la combinación que mejor encaja, tema que desarrollamos al comparar cloud privado, público e híbrido.
Una arquitectura inicial razonable para Stormkit self-hosted puede ser simple: una VM Linux con Ubuntu Server o Debian, Docker instalado, almacenamiento persistente, backups diarios, un cortafuegos restringido, acceso SSH con claves, DNS bien configurado y monitorización básica. Sobre esa base, Stormkit se instala con Docker Compose y se conecta al repositorio o al flujo de despliegue elegido.
Para entornos más serios conviene separar componentes: una máquina para Stormkit, almacenamiento persistente con copia de seguridad, base de datos o servicios auxiliares protegidos, logs centralizados y un proxy frontal con TLS. También es recomendable configurar GitHub Actions si el equipo quiere más rendimiento o más control sobre la integración continua, ya que Stormkit puede apoyarse en ese flujo en lugar de ejecutarlo todo en la misma máquina donde vive el servicio worker.
| Capa | Recomendación |
|---|---|
| Sistema operativo | Versión soportada de Ubuntu Server o Debian |
| Contenedores | Docker Compose para empezar; Swarm si hay varios nodos |
| Red | Cortafuegos restrictivo, DNS correcto y SSH con claves |
| TLS | Certificados gestionados por la propia plataforma o por un proxy frontal |
| Backups | Copias de volúmenes, configuración y repositorios críticos |
| CI/CD | GitHub Actions si se necesita más control del pipeline |
| Monitorización | Métricas del servidor, logs y alertas básicas |
| Seguridad | Actualizaciones, mínimo privilegio y revisión del instalador |
Sobre cloud privado, esta arquitectura puede crecer hacia un modelo con varias VMs, redes internas, balanceo de carga, backups y separación por cliente o proyecto. Sobre cloud público OpenStack, puede empezar como una VM ágil y evolucionar hacia más instancias, entornos por proyecto y automatización mediante APIs. La parte de copias, en cualquiera de los dos casos, debería seguir la disciplina de la regla 3-2-1 de backup.
El atractivo de Stormkit self-hosted es claro: despliegues más cómodos, control de la infraestructura y menos dependencia de plataformas externas. Pero alojar tú mismo una herramienta de despliegue trae responsabilidad. Hay que proteger el panel, controlar los accesos, revisar las variables de entorno, asegurar los secretos, actualizar las imágenes, probar las restauraciones y vigilar el consumo de recursos.
Conviene además definir desde el principio qué cargas deberían ir a Stormkit y cuáles no. No todo proyecto debe desplegarse en la misma plataforma. Una web corporativa, documentación, un frontend de cliente o un panel interno pueden encajar muy bien. Una aplicación crítica con backend complejo, colas, bases de datos y alta disponibilidad puede necesitar una arquitectura más amplia —y ahí entran nuestros servicios gestionados y el diseño de alta disponibilidad.
Stormkit puede ser una pieza eficaz dentro de una estrategia de cloud europeo: desarrollo rápido, despliegue controlado y operación simple para frontends. Su valor crece cuando se combina con la infraestructura adecuada. La decisión no debería empezar por la herramienta, sino por la pregunta correcta: ¿qué nivel de control, aislamiento, coste y escalabilidad necesita el proyecto? Stormkit resuelve la capa de despliegue. El cloud privado y el cloud público pueden aportar el suelo donde corre.
¿Qué es Stormkit self-hosting? Es la opción de instalar Stormkit sobre tu propia infraestructura para desplegar aplicaciones frontend con control sobre el hosting, los logs, los certificados, el escalado y el entorno de ejecución.
¿Se puede instalar Stormkit en una sola máquina? Sí. La documentación recomienda Docker Compose para despliegues de una sola máquina por su sencillez.
¿Cuándo tiene sentido Docker Swarm? Cuando se necesitan varios nodos, mayor escalabilidad o una arquitectura con mejor reparto de carga. Stormkit permite elegir Docker Swarm durante la instalación.
¿Qué encaja mejor, cloud privado o cloud público? El cloud privado (sobre Proxmox o VMware) encaja mejor cuando el objetivo es recursos dedicados y mayor control. El cloud público soberano (sobre OpenStack) encaja mejor cuando se busca despliegue ágil, elasticidad y un modelo cloud. En cloudprivado.com ofrecemos ambos y te ayudamos a elegir.
¿Stormkit sustituye a Kubernetes? No necesariamente. Stormkit simplifica los despliegues de frontend y el hosting. Kubernetes sigue teniendo sentido en arquitecturas más complejas con muchos servicios, automatización avanzada y necesidades específicas de orquestación.
¿Quieres desplegar Stormkit sobre infraestructura europea que controles de verdad? En cloudprivado.com te ayudamos a elegir entre cloud privado con recursos dedicados o cloud público soberano, montamos la VM ya endurecida y con backups, y dejamos tu plataforma de despliegue lista para producción. Hablemos de tu proyecto.
Una sala puede tener Tier III, ISO 27001 y ISO 50001 y no servir para un clúster de GPU. Qué certifica exactamente cada estándar, dónde acaba su alcance y qué hay que verificar aparte: densidad real por rack, refrigeración líquida en producción, resiliencia desde la acometida hasta la GPU y variaciones bruscas de carga.
Tier sigue midiendo bien la resiliencia de un edificio, pero no responde a la pregunta que importa cuando vas a desplegar GPU: ¿puede esta sala recibir, alimentar, refrigerar y operar mi hardware en la fecha acordada? Qué certifica cada programa de Uptime, qué megavatios son reales y qué añaden EN 50600 y la normativa europea.
Racks de más de 100 kW, refrigeración líquida y campus diseñados para crecer una década. La inteligencia artificial ha cambiado las preguntas que se le hacen a un centro de datos, no los estándares que miden si es fiable. Qué mirar hoy antes de firmar con un proveedor.