Self-hosting

Cynario’s Builder and Player are a static browser application. There is no required application backend, account database, or result service.

The default deployment

• Static host or CDN: zero runtime containers. Run the production build and publish only dist/. Your provider must apply Cynario’s security headers and route behavior.
• Dockerfile platform or your own server: one app container. The repository’s Dockerfile serves the same static build through nginx on container port 80; /health is the health endpoint.
• Additional services are optional. Add an SSO proxy only when access must require sign-in. Add a room relay, signaling tracker, or TURN server only for a collaboration/network requirement you can name.

A public website does not require a public source repository. A deployment platform can read a private repository through scoped provider access and expose only the built site or container. Changing repository visibility is a separate disclosure decision that requires current-tree and full Git-history review.

Build or run it locally

# Use an authenticated checkout when the repository remains private.
git clone https://github.com/cybersader/cynario.git
cd cynario
bun install --frozen-lockfile
bun run dev      # local development server
bun run build    # production build → dist/
bun run preview  # preview the production build

Or run the default app container:

docker compose up -d --build

The Compose default exposes the app at http://localhost:8080. For a public deployment, attach a trusted TLS domain through your hosting platform or reverse proxy; do not expose a second unmanaged application port.

Production platform settings

For a Dockerfile platform such as Dokploy, use the same provider-neutral shape:

Build type: Dockerfile
Build context: .
Dockerfile: Dockerfile
Container port: 80
Health path: /health
Environment variables: none
Config mount: none for the default app

Keep provider credentials, application identifiers, hostnames, certificate paths, and private route topology in the deployment platform—not in Git or public documentation.

Configuration and optional services

A missing /config.json is normal. If you mount one, the browser can read it, so it is not a server-side secret store. Use it for organization defaults, pinned content sources, public publisher keys, and collaboration endpoints; never place private signing keys or protected-source passwords in it.

Public Marketplace sources and protected packages are static files, not application services. They can share the app origin or live on another correctly configured static origin. Portable result review remains file-based; there is no central result-ingestion container.

Verify the real deployment

Do not stop at a green hosting dashboard. Against the final trusted HTTPS origin, verify:

• /, /builder/, and /marketplace/ return successfully; for the nginx container, /health also returns successfully;
• the CSP, HSTS, framing, referrer, permissions, and opener headers are present;
• /config.json returns the intended public config or a real 404 when none is mounted;
• the browser console is clean and no page has horizontal overflow at desktop or 375px;
• the deployed revision matches the reviewed commit;
• no configuration, password, private key, or unrelated service was exposed.

See Security & trust for the runtime boundary and Architecture for the static-app model. The repository’s Starlight operator guides contain the full production, Docker, deployment-map, content-distribution, relay, TURN, and SSO recipes; automatic public Pages publication is currently paused.