Static routes are not currently supported on WASM32 server t

Error message

Static routes are not currently supported on WASM32 server targets.

What it means

Within render_route_with_context's WASM32 server target handling, static-route regeneration is only implemented when the 'default' feature is enabled; otherwise the code panics. It means you are trying to serve static routes on a wasm32 server build without the required feature, which is unsupported.

Source

Thrown at integrations/axum/src/lib.rs:737

        match listing.mode() {
            SsrMode::OutOfOrder => ooo(req),
            SsrMode::PartiallyBlocked => pb(req),
            SsrMode::InOrder => io(req),
            SsrMode::Async => asyn(req),
            SsrMode::Static(_) => {
                #[cfg(feature = "default")]
                {
                    let regenerate = listing.regenerate.clone();
                    handle_static_route(
                        additional_context.clone(),
                        app_fn.clone(),
                        regenerate,
                    )(state, req)
                }
                #[cfg(not(feature = "default"))]
                {
                    _ = state;
                    panic!(
                        "Static routes are not currently supported on WASM32 \
                         server targets."
                    );
                }
            }
        }
    }
}

/// Returns an Axum [Handler](axum::handler::Handler) that listens for a `GET` request and tries
/// to route it using [leptos_router], serving an HTML stream of your application.
///
/// This version allows us to pass Axum State/Extension/Extractor or other info from Axum or network
/// layers above Leptos itself. To use it, you'll need to write your own handler function that provides
/// the data to leptos in a closure.
///
/// `replace_blocks` additionally lets you specify whether `<Suspense/>` fragments that read
/// from blocking resources should be retrojected into the HTML that's initially served, rather

View on GitHub (pinned to 32d20f6c9d)

Solutions

Enable the crate's 'default' feature (or the specific feature it gates) for the wasm32 server build.
Avoid static routes on wasm32 server targets: use dynamic SSR routes instead.
If the wasm32 target was chosen by mistake, switch the server to a native target (e.g. x86_64/aarch64) where full support exists.

Example fix

// before
axum = { version = "0.7", default-features = false, features = ["http1"] }
// after
leptos_axum = { version = "0.7", features = ["default"] } // keep default features for wasm32 static routes

Defensive patterns

Strategy: validation

Validate before calling

// fail fast at startup instead of at request time
#[cfg(all(target_arch = "wasm32", not(feature = "default")))]
compile_error!("wasm32 server static routes require the 'default' feature");

Prevention

Enable the crate's default features on wasm32 server builds.
Add a compile_error! or build.rs check for wasm32 + missing feature.
Prefer dynamic SSR routes when targeting wasm32 servers.

When it happens

Trigger: Calling render_route (→ render_route_with_context) for a static route on a wasm32 server target compiled with #[cfg(not(feature = "default"))] — i.e. the default feature set was disabled.

Common situations: Building a wasm32-unknown-unknown server with default-features = false; custom minimal feature sets for axum integration that dropped 'default'; CI builds that prune features for size.

Related errors

AI-assisted analysis of leptos-rs/leptos@32d20f6c9d (2026-09-01). Data as JSON: /api/errors/6a5dff9d9c2a19ba. Report an issue: GitHub.