Introducción

Antes de comenzar este blog, pasaron por mi mente muchas ideas de proyectos que quería desarrollar. Sin embargo, siempre terminaba encontrándome con el mismo problema: en mi máquina local todo funcionaba bien, pero ¿cómo podía hacer para que otras personas pudieran ver esos proyectos sin depender de mi propio equipo?

Muchos dirán que la respuesta es bastante obvia: desplegar la aplicación en internet. Y sí, lo es. Pero mi duda iba más allá de eso. Me preocupaban temas como el costo, cuánto tendría que pagar por alojar proyectos personales y si terminaría usando una solución más cara o más compleja de lo que realmente necesitaba.

Después de investigar un poco descubrí que muchos servicios de hosting ofrecen capas gratuitas bastante completas. De hecho, este mismo blog estuvo alojado en Vercel desde el inicio y, siendo honesto, no tengo ninguna queja. El despliegue era sencillo, tenía métricas y no necesitaba preocuparme demasiado por la infraestructura.

Sin embargo, desde hace un tiempo ha estado rondando en mi cabeza la idea de tener mi propio servidor. No necesariamente porque las plataformas actuales no funcionen bien, sino porque quería tener un poco más de control sobre cómo se despliegan mis aplicaciones y poder alojar varios proyectos desde un mismo lugar.

La razón por la que no lo había hecho antes era simple: miedo a equivocarme. Miedo a configurar mal el servidor, dejarlo expuesto o no saber qué hacer cuando algo fallara. Aun así, sigo pensando que equivocarse forma parte del aprendizaje. Hay que tomar precauciones, claro, pero quedarse quieto por miedo tampoco ayuda mucho.

Después de varias semanas dándole vueltas al tema, finalmente decidí dar el primer paso y comenzar a migrar mis proyectos hacia un VPS↗ (abre en una pestaña nueva) .

Primer paso: centralizar el dominio en Cloudflare

Como la migración tiene varias piezas, decidí hacerla poco a poco para no dejar el sitio fuera de línea durante el proceso.

Lo primero que hice fue mover mi dominio a Cloudflare↗ (abre en una pestaña nueva) . Desde ahí puedo administrar los registros DNS↗ (abre en una pestaña nueva) , además de aprovechar varias de las características de seguridad y rendimiento que ofrece la plataforma.

Con los registros configurados como proxy, Cloudflare también puede quedar entre los usuarios y mi servidor. En la práctica, las solicitudes pasan primero por su red antes de llegar a mi infraestructura. Esto me da varias ventajas:

• •
  Gestión centralizada del dominio: Puedo administrar registros DNS y mantener el control del tráfico desde un solo lugar.
• •
  Protección adicional: La IP de origen no aparece directamente en los registros DNS cuando Cloudflare actúa como proxy. Aun así, también tengo que evitar exponerla por otras vías.
• •
  HTTPS y rendimiento: También ofrece características que ayudan con certificados, caché y optimización del tráfico.

Otro paso importante fue migrar temporalmente el sitio a Cloudflare Pages↗ (abre en una pestaña nueva) , principalmente para tener todo más centralizado mientras termino de preparar el entorno del VPS.

¿Por qué migrar a un VPS?

Para un blog personal como este, migrar a un VPS puede parecer excesivo. Y probablemente lo sea.

Pero la idea no es alojar únicamente este sitio. Quiero desplegar varias aplicaciones desde un mismo servidor y dejar de depender de una plataforma distinta para cada proyecto personal.

También hay un motivo de aprendizaje. Tener un VPS significa encargarme de cosas que una plataforma administrada normalmente oculta: el sistema, la red, la seguridad, el servidor web y el despliegue de cada aplicación.

Sé que la infraestructura de muchos entornos reales va bastante más allá de un VPS. Hay contenedores orquestados con Kubernetes, servicios administrados y plataformas que esconden casi todas estas piezas. Justamente por eso quiero empezar por lo básico: un servidor Linux, DNS, tráfico HTTP, un servidor web y una aplicación expuesta en internet.

No busco demostrar que un VPS sea mejor que Vercel o Cloudflare Pages. Quiero tener un lugar para varios proyectos y entender un poco mejor qué hacen por mí esas plataformas cuando despliego una aplicación.

El papel del servidor web

Para lograr esto hay una pieza importante dentro de la arquitectura que tengo en mente: el servidor web que actuará como reverse proxy↗ (abre en una pestaña nueva) .

Hay varias opciones para hacerlo. Apache HTTP Server↗ (abre en una pestaña nueva) sigue siendo una alternativa válida, pero en este proyecto prefiero usar Nginx↗ (abre en una pestaña nueva) .

Me resulta cómodo como reverse proxy para varios servicios dentro del mismo servidor y encaja bien con los despliegues en contenedores que tengo en mente.

Con este enfoque, el servidor expone únicamente los puertos de entrada habituales, como HTTP y HTTPS, y Nginx se encarga de analizar el dominio o subdominio solicitado para redirigir la petición al servicio correspondiente.

Arquitectura que tengo en mente

De forma simplificada, la arquitectura que quiero implementar es la siguiente:

Un cliente hace una solicitud a alguno de mis dominios o subdominios, por ejemplo mrodriguez.tech , api.mrodriguez.tech o un proyecto bajo otro dominio como sideproject.com .

La solicitud llega primero a Cloudflare y después continúa hacia mi VPS.

En el servidor, Nginx escucha en los puertos HTTP (80) y HTTPS (443). Según el dominio solicitado, envía el tráfico al servicio correspondiente.

Cada servicio correrá dentro de un contenedor Docker conectado a una red interna.

En resumen, la idea sería algo así:

1. 1. Cliente: Realiza la solicitud al dominio o subdominio correspondiente.
2. 2. Cloudflare: Recibe la petición primero, protege el acceso y reenvía el tráfico hacia el VPS.
3. 3. Nginx: Escucha en los puertos públicos y decide a qué servicio enviar cada solicitud.
4. 4. Docker: Aloja las aplicaciones dentro del servidor de forma aislada y organizada.

Este enfoque me permitiría alojar varias aplicaciones al mismo tiempo, cada una bajo su propio dominio o subdominio, pero todas dentro del mismo VPS.

Practicando antes de hacerlo en producción

Antes de configurar todo esto en un servidor real, decidí practicar primero en un entorno local.

Para eso preparé una máquina virtual con Ubuntu Server↗ (abre en una pestaña nueva) . Ahí puedo equivocarme, volver atrás y probar cada configuración antes de repetirla en un VPS real.

También configuré su red en modo bridge↗ (abre en una pestaña nueva) para que el router le asigne una dirección IP dentro de mi red local. Así puedo tratar la máquina virtual como otro equipo conectado a la red.

En esa máquina virtual he estado practicando varias configuraciones iniciales, entre ellas:

• •
  Creación de un usuario distinto de root.
• •
  Deshabilitar el acceso SSH como usuario root.
• •
  Configurar autenticación mediante llaves SSH.
• •
  Activar un firewall y cerrar puertos innecesarios.
• •
  Implementar Fail2Ban para proteger el acceso SSH.

La intención es darle al servidor una base de seguridad razonable antes de exponer cualquier servicio a internet. No pretendo convertir esta lista en una garantía de seguridad.

Lo que viene después

Este artículo es un punto de partida, no una guía paso a paso. Quería dejar escrita la motivación y la arquitectura inicial antes de comenzar a configurarla.

En los próximos artículos quiero ir documentando el resto del proceso: primero cómo estoy preparando el entorno del servidor en una máquina virtual local y luego cómo pienso configurar Nginx como reverse proxy para comenzar a desplegar proyectos dentro de contenedores Docker.

Mi idea es documentar lo que realmente me vaya encontrando: lo que funcione, lo que tenga que corregir y las decisiones que cambien durante el camino.

Conclusión

Migrar un blog personal a un VPS no era una necesidad urgente. En mi caso, la decisión tiene más que ver con los proyectos que quiero desplegar después y con entender la infraestructura que normalmente no veo.

Sé que muchas arquitecturas de producción van mucho más allá de un VPS aislado. Aun así, empezar por lo básico me parece valioso. Entender cómo se configura un servidor, cómo se enruta el tráfico y cómo se expone una aplicación sigue siendo útil cuando más adelante aparecen herramientas más complejas.

Así que este artículo no es el final de una migración, sino más bien el inicio de un proceso que quiero ir construyendo y documentando paso a paso.