Deploying
Choose a runtime that matches the route contract, inspect generated output, and verify the real hosting boundary.
Choose the runtime from application behavior
Static hosting can serve client-rendered assets and prerendered routes. Request-time features need a server runtime that can execute Tavo.js's 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.
Build once and inspect the artifacts
tavo build produces provider-neutral static and Node outputs. Do not edit generated files by hand or deploy stale artifacts.
Inspect Generated output
text.tavo/build/client/ static assets and prerendered HTML
.tavo/build/server/start.mjs generated Node production serverRun the Node output
Start the generated server directly when request-time behavior is required. Static-only applications can publish the client directory to any static host.
Keep authentication, loaders, actions, and business rules in application modules.
Rebuild after every application change.
Run in Terminal
bashnpx tavo build
PORT=4174 node .tavo/build/server/start.mjsVerify the production boundary
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.
Protect runtime monitoring with TAVO_MONITOR_TOKEN and send the token through the Authorization header. Use tavo monitor against the deployed URL to inspect a snapshot or watch the application after release.
Run in Terminal
bashnpx tavo monitor --url https://app.example.com --token $MONITOR_TOKEN --once