Rustrak pasa a un solo contenedor de 34 MiB y mantiene el protocolo de Sentry
El rastreador de errores autoalojado escrito en Rust elimina el dashboard de Next.js y lo sustituye por ficheros estáticos servidos por el propio binario. Llega como release candidate con la etiqueta next.
Rustrak, un rastreador de errores autoalojado escrito en Rust, ya funciona con un único contenedor de 34 MiB. Su autor ha eliminado el dashboard de Next.js que acompañaba al servidor y lo ha reemplazado por ficheros estáticos que sirve el propio proceso. Se publica como release candidate, con la etiqueta de imagen next, y no hay cambios de esquema, así que se puede volver a la versión anterior sin tocar la base de datos.
De dos contenedores a uno
El detalle de por qué ha cambiado esto viene de hace un mes. Cuando el autor lo presentó en r/selfhosted, el comentario más votado señalaba que el servidor en Rust era ligero pero el dashboard de Next.js no lo era en absoluto. Tenía razón, y el arreglo ha sido quitar Next.js de la ecuación: el panel son ahora archivos estáticos que entrega el mismo binario que atiende la API. Un compose file, un contenedor, SQLite por defecto.
La parte que interesa a quien ya tiene algo montado es la compatibilidad. Rustrak habla el protocolo de Sentry, así que si la aplicación ya lleva un SDK de Sentry integrado no hay que tocar código: se cambia el DSN y todo lo demás sigue igual, incluidas las llamadas que ya estén instrumentadas. Para un stack con error tracking en casa o en una infraestructura pequeña, la diferencia entre levantar varios servicios y levantar uno es la diferencia entre algo que mantienes y algo que acabas apagando.
El proyecto está en el repositorio. Ahí están las instrucciones de despliegue y las etiquetas de imagen disponibles.
Lo que aún no está cerrado
Hay que ponerlo en contexto: es un proyecto de una sola persona, distribuido como release candidate, y la cifra de 34 MiB la da su propio autor, no una medición independiente. Tampoco hay datos de comportamiento bajo carga real ni de cuánto aguanta la ingestión de eventos cuando el volumen sube, que es justo donde este tipo de herramientas se rompen.
Aun así, el movimiento es el correcto: menos superficie que operar y menos piezas que actualizar. Quien tenga un Sentry self-hosted sobredimensionado para cuatro servicios internos tiene aquí algo que probar, y la vuelta atrás está cubierta al no haber migración de esquema. Lo que falta por ver es si el proyecto aguanta el ritmo de mantenimiento que exige ser el único responsable de los errores de otros.
