Medusa, Strapi, Next.js y MinIO en un VPS con despliegues GitOps desde el CMS
Un usuario de r/selfhosted detalla un stack de comercio electrónico completo sobre un único VPS de 4 vCPU y 8 GB, donde los editores cambian el aspecto de la tienda desde Strapi y GitHub Actions recompila el frontal.
Alguien de r/selfhosted ha publicado la arquitectura de una tienda de comercio electrónico autoalojada al completo, corriendo sobre un único VPS Linux y orquestada con Docker Compose. El backend es Medusa v2 con PostgreSQL y Redis, el CMS es Strapi 5, el frontal es Next.js 16 con App Router y PWA, la búsqueda va con Meilisearch, el almacenamiento con MinIO en modo compatible con S3 y el proxy inverso con Caddy, que resuelve los certificados solo. Encima hay observabilidad con Vector y OpenObserve para métricas de contenedor y logs en vivo.
El interés no está en la lista de piezas, que es razonable y conocida. Está en cómo despliega. Hay un vídeo con la demo del sistema funcionando y el autor enlaza la página del proyecto, aunque no hay repositorio público donde mirar el Compose.
Del panel del CMS a docker compose
El objetivo era que un editor sin conocimientos técnicos pudiera cambiar estilos de componentes visuales sin pedir SSH ni esperar a que un desarrollador desplegara. El circuito que montaron es este: dentro de Strapi, el editor elige los estilos desde un panel propio y pulsa "Update Storefront". Eso lanza un repository_dispatch contra GitHub Actions, que recoge los componentes, hace commit, compila la imagen Docker de Next.js y la sube a GHCR. Un webhook avisa al VPS y allí se ejecuta docker compose up -d --no-deps storefront, de modo que solo se recrea el contenedor del frontal y el resto del stack sigue en pie.
El flag --no-deps es la parte que más conviene mirar con lupa si alguien quiere copiar el patrón: evita que Compose levante dependencias, así que la actualización es rápida, pero también deja el contenedor nuevo hablando con el resto de servicios tal y como estuvieran. Los problemas clásicos de este tipo de montajes aparecen ahí, en CORS entre los tres servicios (frontal, CMS y backend de comercio) y en la configuración del proxy inverso, que es justo lo que el autor se ofrece a comentar en los comentarios del hilo.
Todo esto corre en una máquina modesta: 4 vCPU, 8 GB de RAM, con swap de Linux y compilaciones Docker multi-etapa para que las imágenes no se coman el disco. No hay cifras de rendimiento ni de carga soportada, solo la afirmación de que el conjunto va fluido. La cifra de recursos es suya, no de un tercero.
Qué se puede reutilizar
El patrón es trasladable a otros escenarios donde el contenido manda sobre el código: cualquier CMS headless que necesite reconstruir un frontal estático o semiestático encaja en el mismo esquema de dispatch, compilación de imagen y recreación selectiva del contenedor. La contrapartida es doble. Por un lado, el pipeline depende de dos servicios externos, GitHub Actions y GHCR, que quedan fuera del "todo autoalojado" del titular. Por otro, un único VPS sin réplica es un punto único de fallo para base de datos, almacenamiento y frontal a la vez.
Queda por ver si el autor publica el Compose completo y los workflows, que es lo que convertiría la demo en algo replicable sin ingeniería inversa.
