Un recorrido visual por la arquitectura de esta web: Next.js, Payload CMS, PostgreSQL, Cloudflare R2, Docker, Dokploy y GitHub, y cómo colaboran para servir páginas y publicar contenido.
Antes de nada, me gustaría introducir el motivo de la existencia de esta web, aprovechando que este será el primero de muchos artículos relacionados con el mundo del desarrollo de software.
Hace aproximadamente cinco años, durante la etapa final de mi carrera universitaria en Ingeniería Informática, recuerdo haber desarrollado complejos sistemas distribuidos, inmensos diseños de bases de datos y haberme peleado por comprender términos como la complejidad algorítmica, el funcionamiento de la red y muchos otros conceptos que conforman el día a día de la mayoría de los desarrolladores.
Sin embargo, aunque todo eso estaba muy bien, al final del día seguía sin tener claro algo fundamental:
*Por solución compleja entenderemos aplicaciones basadas en sistemas distribuidos donde varias piezas, en principio no interconectadas entre sí, deben interactuar de forma sincronizada.
Para resolver esta incógnita me propuse desarrollar una web que me sirviese tanto de caso de estudio como de portfolio y, de ahí, nació esta web. Bueno, no exactamente esta, sino una versión anterior compuesta por una SPA en Vue cuya complejidad provenía más del desarrollo de las animaciones que de la propia arquitectura.
¿Después? Compré el dominio, me hice una cuenta en Netlify, lo conecté con mi repositorio de GitHub, configuré las DNS y listo.
Había sido sencillo: un puñado de documentaciones leídas, algunos vídeos de YouTube, unas decenas de horas para desarrollar la web y listo.
Durante estos cuatro años no he tenido ningún problema con ella.
Hasta hace seis meses.
— "Me gustaría compartir mis experiencias con otros desarrolladores".
— ¿Lo hago en posts de LinkedIn?
— "¡Ni de coña!"
La opción obvia entonces era redactar los artículos en la página que ya tenía. ¿Qué problema podía haber?
Por supuesto, los requisitos habían cambiado completamente.
Tras evaluar la capacidad de mi antigua web para crecer, eché en falta varios elementos fundamentales que deberían asentarse mucho antes de empezar a desarrollar.
Como conclusión, la antigua web no solo tenía problemas de escalabilidad técnica. También estaba fuertemente acoplada a su implementación, era difícilmente reutilizable y había acumulado conocimiento que solo existía en mi cabeza.
En ese momento lo vi claro: no necesitaba simplemente una aplicación más grande; necesitaba una base sobre la que poder seguir construyendo.
Os mentiría si digo que tenía claro hasta donde iba a llegar este proyecto, pero el hilo conductor de todo ello estaba claro:
Hay que tener en cuenta que a diferencia del desarrollo corporativo la publicación de proyectos personales requiere de otro factor común, cuantas menos suscripciones y servicios pagues mejor. Cada plataforma a la que te acoples está 'opinionando' TU solución, por lo que bajo mi experiencia os recomiendo buscar alternativas de código abierto que os ayuden a reducir costes y ser dueños de todo el proceso CI/CD, además esto es permitirá ganar mucha más experiencia en labores de DevOps, es un win-win.
Entonces, ¿cuál es el diseño por el que aposté? Aquí lo tenéis:
En este artículo no voy a entrar en detalles sobre el por qué de las tecnologías escogidas ni de otros servicios externos pero como veis el sistema se conforma por:
Una entrada de blog tiene una ruta con idioma y slug, esto lo diseñé de esta forma ya que como veremos en blogs posteriores el uso de IDs o cadenas alfa-numéricas penaliza en el SEO de las páginas expuestas en internet, por lo que la URI tiene esta distribución:
De este modo que la página sabe qué versión del contenido solicitar. Cuando alguien abre una entrada, el cliente obtiene el contenido desde la API del CMS y genera la página del artículo. El contenido enriquecido se representa en la interfaz con componentes para títulos, párrafos, enlaces, listas, citas, imágenes y bloques de código.
De forma similar pasa con las páginas 'Portfolio' y 'Acerca De', en vez de almacenar cada uno de los texto en archivos i18n que deberían estar versionados junto con el resto de nuestro código e impedirían una fácil gestión de nuevo contenido esta información se controla desde el CMS con entradas diferenciadas para cada uno de los idiomas.
Payload CMS es el sistema de gestión de contenidos de esta aplicación. Desde su panel de administración se pueden crear y editar entradas de blog, gestionar imágenes y organizar otros datos del sitio, como proyectos, categorías, habilidades y experiencia.
El editor de texto utiliza Lexical. El contenido no se guarda como una página HTML hecha a mano, sino como una estructura de datos que describe sus diferentes elementos: párrafos, títulos, enlaces, listas, citas, imágenes y bloques de código. El frontend interpreta posteriormente esa estructura y la convierte en elementos visuales.
Pero Payload no se limita a proporcionar una interfaz para editar contenido. También define el modelo de datos de la aplicación y se encarga de persistirlo, además de exponer la API que consume el frontend.
Es aquí donde entra PostgreSQL.
Las diferentes colecciones que definimos en Payload —entradas de blog, proyectos, categorías, habilidades, experiencia profesional, etc.— terminan representándose como datos persistidos en nuestra base de datos relacional. Payload se encarga de gestionar esta capa y de exponer una interfaz mediante la que la aplicación web puede consultar esos datos sin tener que conocer directamente cómo están almacenados.
A día de la redacción de este artículo, el esquema entidad-relación de la base de datos es similar al siguiente:
El diagrama permite ver algo que desde el panel de Payload puede resultar menos evidente: detrás de las colecciones y relaciones que gestionamos desde el CMS existe un modelo de datos que define cómo se relacionan las diferentes piezas de contenido.
Esta separación es importante para la arquitectura. La web no necesita conocer el esquema interno de PostgreSQL; se comunica con Payload a través de su API, que actúa como frontera entre la presentación y los datos.
A cambio, esta frontera convierte a la API en un contrato entre las dos aplicaciones: los cambios en los datos, en las relaciones o en las respuestas pueden afectar a la web pública aunque cada servicio se construya por separado.
En otras palabras, Payload no es simplemente «el lugar donde escribo los artículos». Es la pieza que conecta la gestión del contenido, el modelo de datos y la API que consume el frontend.
El despliegue parte del monorepo en GitHub y se apoya en una imagen Docker independiente para cada aplicación. Los Dockerfiles codifican cómo construir el frontend y el CMS; Dokploy coordina esa construcción y ejecuta cada imagen como un servicio. Así, el despliegue no depende de preparar manualmente cada servidor: el código y su proceso de empaquetado avanzan juntos.
El flujo permite llevar un cambio desde el repositorio hasta producción en cuestión de minutos. Antes, los entornos de preproducción ofrecen una etapa de validación equivalente a UAT: se comprueba la aplicación desplegada en condiciones similares a las reales antes de exponer el cambio a los usuarios.
GitHub conserva el código; Docker hace reproducible el artefacto; Dokploy automatiza su construcción y ejecución. El resultado es un ciclo de entrega corto, con una etapa previa para validar cambios y límites explícitos entre los servicios.
Por último, Cloudflare es una pieza central de la infraestructura. Gestiona el DNS y, como el proxy está activado, los dominios públicos resuelven hacia la red de Cloudflare, no directamente hacia la IP del VPS. Cloudflare recibe las peticiones y las reenvía al servidor de origen, que permanece detrás de esa capa.
Este recorrido permite aplicar reglas de seguridad y mitigar ataques de denegación de servicio antes de que el tráfico llegue al VPS. También permite cachear las respuestas y los recursos que determinen las reglas configuradas, reduciendo peticiones al origen y mejorando la entrega. El alcance de la caché depende de esas reglas: no todo el tráfico se cachea necesariamente.
Cloudflare también proporciona R2 para los archivos multimedia. Payload sube los archivos al bucket y conserva sus metadatos y relaciones en PostgreSQL; el navegador solicita los archivos mediante sus URL públicas. Así, las páginas llegan a través del frontend, mientras que los medios se sirven desde R2, con Cloudflare como parte de la infraestructura de entrada y entrega.
Como conclusión, la arquitectura no se domina desde la teoría, sino al tomar decisiones, ponerlas a prueba y aprender de sus consecuencias. Cada proyecto es una oportunidad para ampliar lo que creemos posible y convertir la incertidumbre en experiencia. Como dijo Linus Torvalds:
«Talk is cheap. Show me the code».
En definitiva, elige un reto, construye algo y aprende en el camino.
Última actualización: 23 de octubre de 2026
