Verniz runtime and deploy

Verniz can publish one sealed directory containing prerendered pages, browser assets, and a standalone Zolo server. The page does not import a hosting provider SDK: every runtime consumes the same Deploy Manifest v1.

Choose the product and backend¶

[project]
entry = "src/main.zolo"

[web]
output = "hybrid" # static | hybrid | server
out_dir = "dist"
base = "/"
trailing_slash = "always"

[web.runtime]
backend = "llvm" # llvm | native
profile = "release" # release | debug

llvm + release is the production default. native selects Cranelift and is useful when build latency matters more than the last production optimization. The command line can override the project without editing it:

zolo build --web=hybrid --runtime-backend=llvm --release
zolo build --web=hybrid --runtime-backend=native --debug

A purely static product never compiles or ships a server. Hybrid/server products compile the same entry program selected by the WebGraph.

Published layout¶

dist/
├── index.html
├── 404.html
├── _zolo/
│   ├── web-manifest.json
│   ├── deploy-manifest.json
│   └── runtime/
│       └── server.exe       # `server` on Linux/macOS
└── ... browser assets

WebManifest v14 and Deploy Manifest v1 agree on the runtime contract, backend, target, profile, relative file, byte length, and BLAKE3 digest. The standalone adapter rejects a changed manifest, binary, page, asset, route/action graph, capability set, path escape, or symlink before it opens the port.

The server binary is not a browser asset and does not count against JavaScript or route payload budgets. Its size and identity are printed separately in the build report.

Preview the complete product¶

zolo preview dist

For static, preview serves only the sealed files. For hybrid or server, it validates and starts _zolo/runtime/server[.exe]; prerendered routes and immutable assets win before runtime route matching. Closing preview also closes the child server, including on Windows.

The generated executable discovers _zolo/deploy-manifest.json beside itself, so the directory can be copied as a unit and launched directly:

$env:PORT = "8080"
dist\_zolo\runtime\server.exe

ZOLO_HTTP_PORT has priority over the conventional PORT. Supervisors may set ZOLO_DEPLOY_MANIFEST to an explicit manifest path; this is also how the VM parity tests consume the exact deployed product.

The transport removes [web].base before calling the authored router. For example, with base = "/docs/", public /docs/account/42 reaches the application as /account/42. Canonical slash redirects, HEAD, the sealed 404, actions, form bodies, and local 303 redirects keep the same behavior on VM, LLVM, and Cranelift.

Runtime cache¶

Compiled servers are cached under target/.zolo/web-runtime/<key>/. The key includes compiler identity, WebGraph program hash, backend, profile, target, plugins, and the exact runtime static library hash. A valid second build reports cache hit and reuses the executable; corrupted metadata or bytes are never reused.

Changing a static page without changing the runtime program can therefore keep the expensive AOT artifact. Changing the program, backend/profile, target, compiler, plugin set, or runtime library selects a different cache entry.

Adapters¶

Two provider-neutral adapters are available now:

• static-dir: deploy the validated directory to any file host when output = "static".
• standalone: run the declared server artifact and serve its sealed static/runtime product when output = "hybrid" | "server".

Provider adapters should translate Deploy Manifest v1 into host configuration. Pages and components must never import Cloudflare, Netlify, Vercel, or another deployment SDK to select their runtime behavior. Edge/WASM adapters remain a separate opt-in P11 capability.

The complete executable example is examples/features/36-web/24-hybrid-product.