One engine. Three ways to run it.

The light npx runtime is deliberately a subset — it covers the FSM / forms / entities core so you can build and iterate in seconds. When your app needs PDF, scripting, extensions, e-signature, or marketplace apps, that's the full engine — self-hosted with Docker or On-Prem, or hosted on Managed Cloud.

The light runtime: three minutes to a running app

# Requires Node 18+
npx fastyoke init    # scaffold .fastyoke/ + a seed.json you can edit
npx fastyoke dev     # boot the local sidecar on :8787

Your entities are there, your FSM transitions fire, your public forms collect submissions — all in a SQLite file on your own disk. No account, no API key, no outbound traffic. fastyoke is the sidecar itself (the local server, not a client library), so it speaks the same REST + WebSocket contract as the full engine.

For the full walkthrough — provisioning an FSM and wiring a React app to it with the SDK — see the developer quick start.

The full engine, self-hosted

Run the complete engine locally as a single container — the same binary On-Prem deploys, in sandbox mode against a plain SQLite database:

docker run -p 8080:8080 -e DEPLOY_ENV=sandbox \
  ghcr.io/fastyoke/backend:sandbox

This is the full feature set — PDF rendering, the WASM scripting tier, extensions, e-signature, and the marketplace app schemas — with no cloud account. In sandbox mode, third-party integrations (payments, email, external SSO) run against local stubs so nothing leaves your machine. For production self-hosting with multi-tenancy, replication, and managed backups, see On-Prem.

The developer quick start walks through this Docker path end-to-end, from container boot to a working SDK-backed app.

Related reading: Running your code — safely, at native speed: why FastYoke chose WebAssembly — the sandbox model behind the WASM scripting tier the runtime ships.

Build on the shared primitives and your app moves between modes by changing a base URL — not code. The FSM schemas, entity definitions, form configs, and migrations are identical; the full engine simply adds features (PDF, scripting, extensions, e-sign, marketplace apps) on top of the same core.

The @fastyoke/sdk-core client points at whichever mode you're running:

import { createFastYokeClient } from '@fastyoke/sdk-core'

const client = createFastYokeClient({
  tenantId: 'local',
  fetcher: fetch,
  // npx runtime:            http://127.0.0.1:8787
  // self-hosted full engine: http://127.0.0.1:8080
  // Managed Cloud:           https://api.fastyoke.com
  baseUrl: process.env.FASTYOKE_API_BASE,
})

Server-side (Next.js / Vercel Functions), @fastyoke/next swaps the same way — one class, credentials resolved from the environment:

import { FastYoke } from '@fastyoke/next'

// Local: point FASTYOKE_API_BASE at the runtime or the container.
// Managed Cloud: point it at api.fastyoke.com and set FASTYOKE_API_KEY.
const yoke = new FastYoke({ baseUrl: process.env.FASTYOKE_API_BASE })

There is no "Runtime version" of a schema and a "Cloud version." There is one schema. The only caveat: an app that uses full-engine features (PDF, scripting, extensions, e-sign, marketplace apps) needs the full engine — those aren't in the light runtime.

• It's a subset, on purpose. No PDF rendering, WASM scripting, extensions, e-signature, or marketplace apps. Those live in the full engine — run it with Docker or On-Prem when you need them.
• Single tenant per sidecar. The npx runtime serves one tenant at a time. Simulating two isolated tenants means two sidecar processes on different ports.
• Single-node, no HA. No write-ahead-log replication, no failover, no multi-node WebSocket fanout. For production with more than one operator or any HA requirement, use On-Prem or Managed Cloud.
• No managed backups. The SQLite file is yours — back it up. On-Prem and Managed Cloud include operator-managed backup pipelines (Litestream to S3-compatible storage).
• No zero-downtime deploys. Upgrading the runtime binary requires a restart. The event log and tenant database survive it; in-flight HTTP requests do not.

Get started

# Light runtime — Node 18+, no Docker
npx fastyoke init
npx fastyoke dev

The CLI bootstraps a .fastyoke/ directory with a local.db SQLite file, a seed.json you can edit, and a token file your frontend reads for authenticated API calls.

For ISVs embedding the full engine inside a client's firewall, see the On-Prem deployment guide.