Deploying

Static hosting can serve client-rendered assets and prerendered routes. Request-time features need a server runtime that can execute Tavo.js generated handler.

• Use static hosting for CSR and fully prerendered output that has no request-time loader, action, session, or middleware work.

• Use the generated Node production server for SSR, server loaders, route actions, sessions, and server routes.

• Treat revalidation and shared cache invalidation as deployment capabilities; the process-local default is neither durable nor coordinated across replicas.

tavo build produces provider-neutral static and Node outputs. Do not edit generated files by hand or deploy stale artifacts.

text.tavo/build/client/              static assets and prerendered HTML
.tavo/build/server/start.mjs       generated Node production server

Start the generated server directly when request-time behavior is required. Preserve the client and server output directories and install the production dependencies from the lockfile in the deployment environment. Start with the application root as the working directory, then verify a direct request before routing public traffic to it. Static-only applications publish the client directory.

• Keep authentication, loaders, actions, and business rules in application modules.

• Rebuild after every application change.

bashnpx tavo build
PORT=4174 node .tavo/build/server/start.mjs

Configure the host to serve generated files first. For a client-rendered application, unmatched application URLs must fall back to index.html so a direct visit to /projects/42 can start the browser router. Keep asset requests outside that fallback so a missing JavaScript file does not receive HTML.

For prerendered routes, preserve the generated HTML and route-data files. Decide how the host serves its 404 document and status. Dynamic parameters outside generateStaticParams() have no prebuilt HTML; support them through client routing and browser-safe data, use an SSR server, or intentionally return 404.

Configure secrets, trusted hosts, canonical origin, request limits, cookies, CSP, remote image allowlists, and cache storage in the actual platform. Then smoke-test a direct SSR request, client navigation, mutation, error response, and static or revalidated route as applicable.

Set TAVO_MONITOR_TOKEN in the server environment to protect runtime monitoring, and set the local MONITOR_TOKEN variable used by the command below to that same value. The CLI sends it through the Authorization header. Use tavo monitor against the deployed URL to inspect a snapshot or watch the application after release.

bashnpx tavo monitor --url https://app.example.com --token $MONITOR_TOKEN --once