@hyperframes/studio-server is the backend used by Studio. It serves projects
and previews, applies source mutations, creates thumbnails, and starts render
jobs.
Most users do not need it. The CLI wires the server and Studio together when
you run npx hyperframes preview. Use this package only when your own
application must host the Studio backend.
Mount the API
createStudioApi() returns a Hono application. The adapter is the boundary
between Studio and your project storage, bundler, linter, and renderer.
localhost, 127.0.0.1 or [::1]), Studio
sends its API requests without cookies, so they don’t queue behind the
preview’s media. On any other origin it sends them as usual, so remote and
proxied setups (Codespaces, tunnels, an access proxy) keep their cookies by
default. A loopback host that authenticates its mounted API with same-origin
cookies sets VITE_STUDIO_API_SAME_ORIGIN_CREDENTIALS=true, at build time or at
runtime in window.__HF_STUDIO_ENV__; it costs that host the connection
speedup.
Studio reads the flag once, when its modules load, so set
window.__HF_STUDIO_ENV__ before loading Studio; the CLI injects it, but a host
that mounts the API itself must inject it too.
A StudioApiAdapter supplies:
- project listing and resolution;
- composition bundling and linting;
- render output storage and job startup;
- optional thumbnails, sessions, registry installation, and background removal.
bundle(projectDir, options) must pass options through to bundleToSingleHtml,
spread over your own options. The preview sets stampHfIds there so each element
is served with the id its source file mints. If a host drops it, a composition
the bundler inlines can be served with ids that a later save does not mint.
Other entry points
@hyperframes/core/studio-api remains a deprecated compatibility re-export.
New integrations should import from @hyperframes/studio-server.
Related topics
@hyperframes/studio
Embed lower-level Studio interface components.
Studio guide
Use the complete editor that ships with HyperFrames.