MyTechDailyNews Software: Dioxus Rust Build Budgets, Hosted CI Costs, and a Topcoat Experiment

This MyTechDailyNews Software review asks what a year of production use actually reveals about a stack. The example is SeggWat, an in-app feedback tool for SaaS products, and the earlier April note argued that Rust was the right foundation for a production micro SaaS. Here the focus is the bill that came due: the application itself remains calm while release automation gets expensive.

The dashboard is a Dioxus 0.7 Fullstack application placed inside a Cargo workspace. The workspace has a backend crate, an auth crate, and about ten UI crates covering insights, feedback, ideas, boards, widgets, and settings. Twelve crates depend on Dioxus, and the data layer sits on PostgreSQL. The infra.page product uses the same stack, so the pattern is not limited to one UI surface.

Fullstack here means one Rust codebase doing three jobs: server rendering, server functions acting as backend, and client compilation to WebAssembly. That sentence sounds compact until a build log explains the cost.

Why the application layer stays calm

• Database to button, one toolchain. Queries, business rules, server functions, and UI components are all Rust. That leaves a single formatter, a single package manager, and one place to investigate when behavior changes. For solo work, it avoids warming a frontend brain before writing UI and a backend brain before writing services.
• Shared types remove drift. A struct can be defined once, returned by the database layer, passed through a server function, and rendered by a component. When a field changes, cargo check can surface the broken call sites, including UI code. There is no OpenAPI specification to regenerate and no TypeScript interface quietly disagreeing with the backend. The practical value is not typing speed; it is refactoring late at night when nobody can review the change.
• Multi-target options remain open. Dioxus can target desktop and mobile, including iOS. Today neither product needs a native app, but the option reduced the risk of putting a year into a UI stack that might become a dead end.
• Production behavior is dull in the useful way. Once the code compiles, it tends to run. That keeps a whole class of undefined is not a function failures away from users, so the bugs left are logic bugs. The boring in production argument held up when it met traffic.

The CI numbers that decide the release experience

The interesting pressure is on compile and test time. The dashboard compiles twice: once for the server target and once for wasm32. A dozen Dioxus crates plus a macro-heavy UI create a workload that is manageable on a local machine and expensive in CI.

Reported work	Environment	Observed cost	Operational note
WASM dashboard build	6 cores	about 22 minutes	One leaf crate for the browser target.
Release image	GitHub-hosted 2-core runner	about 90 minutes	That is also 90 billed minutes per push if the workflow triggers there.
Release image	self-hosted runner	around 40	The biggest measured improvement in the account.
Workspace Clippy	7 GB hosted runner	exit code 143 with no diagnostics	Fixed later with a 10 GB swapfile and CARGO_BUILD_JOBS=1.

The release path is often described as 90 minutes on a hosted runner, and that number is the baseline being argued against.

Build-time mitigations and their limits

• Swatinem/rust-cache is useful, but it has a trap: a run can restore caches from its own ref or the default branch, and GitHub evicts caches unused for 7 days. If main builds are no longer automatic, release builds can start cold. The workaround is to trigger a build on main after dependency bumps just to warm the cache.
• Combining build and test lets the test step reuse compiled artifacts instead of compiling the world again.
• The mold linker helped linking, but linking was not the bottleneck; compiling was.
• Heavy builds moved to a self-hosted runner, cutting the release image from 90 minutes on GitHub-hosted 2-core infrastructure to around 40 on the VPS runner.

Each mitigation helped, but none changed the underlying math: two compile targets, a large dependency graph, and many macros still mean a lot of compiling.

Where All Rust stops being literal

The business logic is All Rust in the sense that product rules, server functions, and data transformations live in the same language. The edges are not pure. The insights page uses Chart.js because a production-trustworthy Rust charting library was not found. Chart.js is loaded from a CDN and wrapped in about 340 lines of JavaScript, and Dioxus calls through dioxus-use-js. The UI also uses Tailwind, so the pipeline installs Bun and runs Tailwind CLI before Rust compilation begins.

That trade-off is reasonable. The warning is simple: choosing Dioxus to escape JavaScript may still require JS glue, plus a JavaScript toolchain in CI.

How the next choice changed

The better decision question is not What helps me ship fastest? It is What helps me keep shipping without hating my life? For the backend, Rust remains the easy answer. For the frontend, the answer depends on product type.

If the product is truly app-like, with heavy client state, offline support, or a real mobile target, Dioxus is still attractive. Most current work, however, is dashboard work: forms, tables, a few charts, and some toggles. For that, the release process pays a 22-minute WASM tax to deliver interactivity that is barely used.

The next experiment is Topcoat, a new Fullstack framework from the tokio-rs org announced in July. It makes the opposite bet: everything renders on the server, components are async functions that can query the database directly, and interactivity uses $(...) expressions in type-checked Rust. The same expressions are evaluated for the first render and translated to JavaScript for instant browser behavior. There is no WASM bundle and no second compile target.

Step-by-step: how to decide whether this stack fits your team

1. Count how many crates depend on Dioxus and how many UI crates are in the Cargo workspace; the example has Twelve crates and about ten UI crates, so a large surface predicts long compile work.
2. Separate the two cost centers: server compilation and wasm32/WebAssembly compilation. If the dashboard compiles twice, budget for both in CI.
3. Measure one leaf WASM crate and a full release image, not just local builds; the reported numbers are about 22 minutes and about 90 minutes.
4. Test Clippy on the smallest runner first; if it exits with 143, raise memory or use a 10 GB swapfile with CARGO_BUILD_JOBS=1.
5. Decide whether caching warms by default; if main builds stop, GitHub cache eviction after 7 days can force cold release builds.

Common misconceptions

• It is not true that the UI code is always free of JavaScript; Chart.js, about 340 lines of JavaScript, and JS tooling may be present.
• It is not true that Rust alone solves CI cost; the same code can take 90 minutes on a GitHub-hosted 2-core runner and around 40 on a self-hosted runner.
• It is not true that Dioxus is only a web tool; the component model can target desktop and iOS, but that option must be worth the compile cost.
• It is not true that shared types make production boring automatically; the boring in production benefit appears after the pipeline can build often enough to test.

FAQ

Is the backend still Rust?

Yes. The account says Rust is still the backend answer, and it is not close.

Why is the WASM build so expensive?

The dashboard compiles twice, and the browser target needs wasm32 output. A dozen Dioxus crates plus macros make the WASM layer take about 22 minutes on 6 cores.

What changed the runner choice?

The release image took about 90 minutes on GitHub-hosted 2-core infrastructure and around 40 on a self-hosted runner, turning 90 billed minutes into a scheduling problem.

What is the next framework trying to avoid?

Topcoat avoids the 22-minute WASM second target, but it is early-stage, from tokio-rs, and announced in July.

Action advice for software teams

• If you evaluate Dioxus for a SaaS dashboard, make a build-budget table before adopting: WASM on 6 cores, hosted release on GitHub-hosted 2-core runners, self-hosted runner around 40, and Clippy on 7 GB.
• If you need boring in production, shared types, and cargo check coverage across UI, the stack has a real payoff.
• If every release is a 90 minutes wait, move the heavy build off the default hosted runner before judging the language.

What to watch next

Topcoat is still a bet, not a result: the README calls it early-stage and experimental, breaking changes are expected, and no build has been measured. The follow-up will compare the current around 40 self-hosted build with any Topcoat build time; if 40 minutes drops to 10 minutes, that is news. If it does not, that is also news.