Deploy FrameKit

FrameKit’s supported initial deployment is one long-lived Node.js process per container, with HTTPS and request throttling provided by an external reverse proxy or load balancer. The process hosts Studio and synchronous server-side PNG rendering; the access API is enabled only when FRAMEKIT_AUTH_ENABLED=true.

Caution

Authentication is opt-in. Missing or false means open mode, where /editor and /brand work without login, /login redirects to /editor, /settings and the access API are absent, and image rendering is credential-free. Before exposing production to an untrusted network, explicitly set FRAMEKIT_AUTH_ENABLED=true.

Runtime and configurationNode, Chromium, environment variables, render capacity, and process-local state.

Docker and persistenceThe canonical standalone image, /data, SQLite persistence, and restart behavior.

Security and reverse proxiesCredentials, same-origin cookies, Bearer tokens, image restrictions, HTTPS, and public exposure.

Deployment sequence

1. Choose the auth mode explicitly. Set FRAMEKIT_AUTH_ENABLED=true before exposing the process to an untrusted network; only then set a strong FRAMEKIT_ADMIN_PASSWORD for first-user bootstrap.
2. If authentication is enabled, provide a writable, durable location for SQLite so users, sessions, and API tokens survive restarts.
3. Install the Playwright Chromium browser and Linux dependencies, or use the canonical Dockerfile that does so during the image build.
4. Run a successful production build with pnpm framekit build.
5. Start the built application with pnpm framekit start.
6. Put HTTPS and request throttling in front of the process before public exposure. In authenticated mode, throttle login traffic as well.

Note

framekit start is read-only with respect to the generated registry. It expects a successful build and does not regenerate templates for you.

State boundaries

When authentication is enabled, SQLite stores users, sessions, and API-token metadata. Open mode does not initialize SQLite and does not create an anonymous administrator. Render jobs are different: they live in a process-local globalThis map, expire after 120 seconds, and disappear when the process restarts. A durable SQLite volume therefore does not make an in-flight render job durable.

The renderer reuses one Chromium browser during the process lifetime, but gives each render an isolated context and page. Capacity is bounded per request. The timeout aborts or cancels render work; page and context cleanup is attempted in finally, and that cleanup wait has no separate documented limit. The supported topology is not a serverless function or a set of replicas that expects process-local render jobs and browser state to be shared.