Dioxus en producción: 90 minutos por build en Rust

90 minutos es lo que tarda un build de release en un runner alojado de GitHub de 2 núcleos. Ese es el número que resume el primer año de SeggWat, una herramienta de feedback dentro del producto para SaaS, corriendo Dioxus fullstack en producción, según el balance que publicó su creador, Hauke, en el blog OXIDT.

Para cualquier founder, la lección no es sobre Rust ni sobre frameworks: el costo de una decisión de arquitectura no aparece en el código, aparece en la factura de CI y en las horas que nadie factura.

¿Qué es Dioxus fullstack y qué corre en producción?

Dioxus es un framework de Rust que compila la interfaz a WebAssembly y permite escribir frontend y backend en el mismo código base: renderiza en el servidor, ejecuta server functions como backend y compila el cliente al navegador para que la página sea interactiva. Su repositorio lo presenta como una sola base de código para web, escritorio y móvil, con integración directa con axum y apps web de menos de 50 kb, según la documentación del propio proyecto.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Con eso, Hauke construyó el dashboard de SeggWat. La arquitectura es un workspace de Cargo: un crate de backend con server functions, un crate de autenticación y cerca de diez crates de interfaz que cubren insights, feedback, ideas, boards, widgets y ajustes. Doce crates dependen de Dioxus y todo se apoya en PostgreSQL. infra.page corre sobre el mismo stack.

No es un experimento de fin de semana. El autor empezó este camino en su trabajo anterior y lo continuó en sus propios productos; en abril publicó por qué eligió Rust para un micro SaaS en producción, con una promesa simple: más lento al principio, más barato de mantener después. Un año más tarde escribió la factura.

Lo que sí funciona: un solo lenguaje de punta a punta

Un idioma en toda la pila. Consulta a base de datos, regla de negocio, server function y botón: todo Rust. Un solo toolchain, un solo formatter, un solo lugar donde mirar cuando algo se rompe.
Los mismos tipos a los dos lados. Una estructura se define una vez: la capa de datos la devuelve, la server function la envía y el componente la renderiza. Si renombras un campo, cargo check te da la lista de todo lo que se rompió, incluida la interfaz. Sin regenerar una especificación de OpenAPI ni interfaces de TypeScript desincronizadas.
La puerta a otras plataformas queda abierta. El mismo modelo de componentes puede apuntar a escritorio y móvil, incluido iOS. Ninguno de sus productos necesita hoy una app nativa, pero saber que no habría que reescribir todo pesó cuando decidió dónde invertir un año de trabajo.
Producción aburrida. Una vez que compila, en general corre. Toda la clase de errores tipo undefined is not a function no llega al usuario, así que los bugs que pasan son de lógica.

Para un founder en solitario con varios productos a la vez, el valor real está en el segundo punto: refactorizar sin miedo, de noche y sin nadie que revise el código.

La parte dolorosa: el dashboard se compila dos veces

El dashboard compila una vez para el servidor y otra a wasm32 para el navegador. Con una docena de crates de Dioxus y mucha interfaz con macros, el resultado en integración continua es este:

El build de WASM por sí solo tarda unos 22 minutos en 6 núcleos, y eso es un único crate hoja: el dashboard compilado para el navegador.
Una imagen de release tarda cerca de 90 minutos en un runner alojado de GitHub de 2 núcleos. En un runner propio sobre un VPS baja a unos 40 minutos.
cargo clippy --workspace --all-targets fue terminado por falta de memoria en el runner de 7 GB: salida 143 y ningún diagnóstico. La solución fue sumar un archivo de swap de 10 GB y CARGO_BUILD_JOBS=1 para bajar el pico de memoria. Su linter necesita swap.

Lo que probó y qué pasó con cada cosa: caché con Swatinem/rust-cache ayuda, pero un workflow solo puede restaurar cachés de su propia rama o de la rama por defecto, y GitHub elimina las cachés sin uso durante 7 días; cuando dejó de compilar en main, los releases arrancaban en frío, así que ahora dispara un build manual en main tras cada actualización de dependencias solo para mantener la caché caliente. También compilar y testear de una sola vez, para reutilizar artefactos. Y el linker mold: agradable, pero el enlace nunca fue el cuello de botella, compilar sí. La mayor ganancia fue un runner propio, que bajó el build de release de 90 a 40 minutos, a cambio de mantener un servidor de build.

La decisión operativa que tomó: dejó de construir imágenes en cada push a main. Ahora se construyen en tags de release o se disparan a mano. 90 minutos facturados por push es una forma cara de gastar dinero.

El asterisco del todo en Rust

La lógica de negocio es toda Rust. Los bordes no. Los gráficos del dashboard son Chart.js cargado desde un CDN y envuelto en unas 340 líneas de JavaScript que Dioxus llama desde Rust; el estilado es Tailwind, así que el CI instala Bun y corre la CLI de Tailwind antes de que Rust empiece. Si eliges Dioxus para escapar de JavaScript, conviene saber qué estás firmando: Rust, más pegamento en JS, más una toolchain de JS en tu pipeline.

¿Qué es Topcoat y por qué es la próxima apuesta?

El siguiente proyecto de Hauke usará Topcoat, un framework fullstack del org de tokio-rs anunciado el 22 de julio de 2026 en el blog de Tokio. La idea es la apuesta inversa a Dioxus: todo se renderiza en el servidor, los componentes son funciones asíncronas que pueden consultar la base de datos directamente y la reactividad se agrega traduciendo expresiones de Rust ya verificadas por tipos a JavaScript, con instrucciones de reactividad servidas como metadatos junto al HTML, en una línea similar a HTMX. No hay bundle de WebAssembly ni un segundo objetivo de compilación.

El anuncio de Tokio lo plantea sin vueltas: frameworks como Leptos y Dioxus son excelentes para aplicaciones muy interactivas en Rust compilando a WebAssembly, pero muchas aplicaciones no necesitan ese nivel de interactividad. Para ese segmento, compilar a un objetivo separado, cuidar el tamaño y el particionado del bundle y serializar datos entre cliente y servidor se vuelve una carga. El mismo post aclara que el sistema de reactividad del lado del cliente está en desarrollo temprano y tiene limitaciones, y que existen integraciones con HTMX y Alpine.js.

Hauke es explícito: esto es una apuesta, no un resultado. El README describe Topcoat como experimental y anticipa cambios que rompen compatibilidad, además de renunciar a la opción multiplataforma. Y todavía no midió ningún build. Prometió un seguimiento con números reales de compilación y minutos de CI.

¿Qué significa esto para tu startup?

Cinco cosas para llevarte antes de copiar este stack:

Presupuesta el CI como parte de la arquitectura, no como un detalle de DevOps. Si tu build de release tarda 90 minutos, cada push es una factura y cada release, media tarde. Calcula minutos por build multiplicado por builds semanales antes de comprometerte con una compilación pesada.
Separa lo pesado de lo frecuente. Mueve los builds de imagen a tags de release y deja que el día a día use chequeos y tests. El autor adoptó esa rutina porque compilar imágenes en cada push no le daba retorno.
Mide antes de migrar de stack, y mide tu caso real. Un spike de dos días que compile tu aplicación de verdad dice más que cualquier benchmark de terceros. El propio autor admite que, para algo genuinamente tipo app con mucho estado en el cliente u offline o móvil nativo, volvería a Dioxus.
Pregúntate qué interactividad estás pagando. Formularios, tablas, unos gráficos y algunos toggles rara vez justifican un bundle WASM por release. Si tu producto es un dashboard, evalúa un enfoque renderizado en el servidor y compara minutos de CI antes y después.
Trata el tiempo de compilación como un problema de proceso, no de lenguaje. Caché bien configurada, runner propio y menos builds atacaron el grueso del problema sin cambiar una línea de arquitectura. El backend en Rust, en palabras del autor, sigue siendo la parte que no cambiaría.

Conclusión

El balance de un año deja un veredicto incómodo y útil: el código es la parte aburrida del negocio, en el buen sentido, y el pipeline es la parte emocionante, en el mal sentido. Rust cumplió lo que prometía en el backend y en los tipos compartidos; lo que no cumplió fue la promesa implícita de que un solo lenguaje sería simple de operar.

La decisión para un founder no es Rust sí o Rust no. Es cuánta interactividad real necesita tu producto y cuántos minutos de compilación estás dispuesto a pagar por ella. Esa cuenta se hace antes, con un spike y una planilla de CI, no después de un año y de una migración.