Monitorizar excepciones en un VPS de 5 dólares con dos contenedores

Montar el seguimiento de errores de producción en un VPS de la gama de 5 a 12 dólares al mes es viable si se acepta recortar el alcance: solo excepciones, dos contenedores y los SDK oficiales de Sentry apuntando a un DSN propio. Lo describe el autor de Epure, que además es quien desarrolla esa herramienta, así que conviene leerlo sabiendo de dónde viene.

La premisa es que el Sentry autoalojado completo no es la unidad de despliegue adecuada para este trabajo. Hablamos de una flota de decenas de contenedores (Kafka, ClickHouse, Redis, workers) que solo tiene sentido en una máquina dedicada. La otra opción clásica, pagar un SaaS solo para ingest de errores, funciona, pero añade una factura y un proveedor por medio que para un proyecto lateral o una ruta de ingest sensible a privacidad puede no compensar. Entre medias queda GlitchTip, más ligero y compatible con el protocolo de Sentry, que el autor menciona y descarta porque prefiere Rust y RLS de Postgres.

Dos contenedores y nada más

El stack real son dos servicios: la aplicación y Postgres 16. El resto es criterio operativo. La base de datos no se publica nunca al host, se queda en la red interna de Docker accesible como postgres:5432. Hay un healthcheck con pg_isready para que la app espere a que la base esté lista, las contraseñas van por .env y el puerto 8080 de la app se publica o se deja en la red para que lo alcance un proxy.

El modelo mental que propone es corto: internet entra por un edge TLS en el 443, que reenvía a la app en el 8080, y esta habla con Postgres dentro de la red de Docker. Sin APM, sin replay, sin profiling, sin suite móvil. Si el checklist incluye algo de eso, la recomendación es irse a un producto que lo traiga de serie.

Los fallos que se repiten al montarlo

El autor recopila los tropiezos que se encontró al cablearlo, y son de manual:

• Publicar 5432:5432 "solo para depurar". Los escáneres lo encuentran en minutos.
• Llevar a producción el compose del portátil, con contraseñas de ejemplo y URLs a localhost.
• Saltarse el TLS y pasar media hora depurando por qué se caen las cookies de sesión.
• Tener el health en verde pero el host del DSN mal puesto: el origen público no es el mismo que el localhost donde consultas.
• Olvidar el origen del SPA en la lista de CORS y culpar al SDK.
• Quedarse sin memoria al intentar levantar el Sentry completo en esa misma caja.

Sobre el consumo, el autor no da cifras medidas de RAM ni CPU y dice que las publicará cuando las tenga sobre un plan concreto. La propuesta es defendible sobre el papel, pero el peso real de un Postgres más el ingest de excepciones sobre una o dos vCPU es justo lo que decide si la máquina de cinco dólares aguanta un pico de errores. Los pasos de instalación y el overlay de producción están en la guía de autoalojamiento del proyecto.