Cloud live · Local post-GA

One engine. Two runtimes.

Run FastYoke as Managed Cloud — fully hosted, multi-tenant, production-ready today — or on your machine with FastYoke Runtime for local development and single-node deployments. The FSM engine, schemas, and app packages are identical across both.

Choose your runtime

Two ways to run the same engine

Managed Cloud for production workloads today. Local Runtime for offline dev, demos, and single-node — free forever, shipping post-GA.

Managed Cloud

Fully hosted multi-tenant FastYoke. Sign up, install marketplace apps, and run production workloads today — migrations, managed backups, and WebSocket fanout included.

Local single-node

The full engine on your machine. Free forever for development and single-node. No cloud account, no outbound traffic — join the waitlist on /download until post-GA.

::cta-button{to="/getting-started" variant="primary" size="md"} Start on Managed Cloud :: ::cta-button{to="/download" variant="secondary" size="md"} Local Runtime waitlist ::

Available post-GA release

Who it's for

Three developer profiles

The Runtime tier is free for all three of these cases. You don't need to pick one — the same binary handles all of them.

Evaluating FastYoke

You want to understand what the FSM engine can do before signing up for Cloud SaaS. Run the full engine locally, build a real app, and make the decision with data — not a sandbox with artificial limits.

ISV building an embedded app

Your product ships inside a customer's firewall. FastYoke Runtime is the right local dev and CI target. The same app package that runs locally deploys to the customer's On-Prem install without modification.

Consultant prototyping

You're building a client demo or a vertical-specific app for a sales conversation. Runtime boots in three minutes on your laptop, runs offline during the pitch, and hands off to a Cloud SaaS tenant when the client is ready to go live.

What's included

Every engine primitive, free

The Runtime tier does not gate features — it gates topology. The engine you get is identical to Cloud SaaS and On-Prem:

Finite State Machine engine. Multi-board FSMs with guards, self-loop transitions, and the admin cancel override. The same JSON-logic predicates that run in production evaluate locally.
Forms + PDF rendering. Public forms collect submissions into the local SQLite database. PDF export (typst-based) renders on your machine with no cloud call.
WASM scripting tier. TypeScript on QuickJS in wasmtime. The same fuel + memory caps apply — behavior is deterministic across Runtime and Cloud SaaS. Related reading: Running your code — safely, at native speed: why FastYoke chose WebAssembly.
Typed SDK. @fastyoke/sdk-local is the Runtime sidecar client. It is API-compatible with @fastyoke/sdk-next (Cloud SaaS) — swap the import, swap the env var, the same application code runs.
Event log. The append-only event log writes locally. Every FSM transition is recorded. The audit trail survives a restart.
Marketplace app schemas. CRM Suite, Yoke Ledger, Inventory, Field Service — all the app schemas are available locally. You can seed a full multi-app tenant and develop against it offline.

What changes at the topology boundary is replication, HA, and WebSocket fanout to multiple nodes. Those require Cloud SaaS or On-Prem.

The upgrade path

Runtime → Cloud SaaS is one config swap

This is the point of the Runtime tier: you build once and it runs everywhere.

The only difference between a Runtime app and a Cloud SaaS app is the SDK client import and the environment variable that points at the API:

// Runtime (local sidecar)
import { createClient } from '@fastyoke/sdk-local'
const client = createClient({ baseUrl: 'http://localhost:3001' })

// Cloud SaaS (same app, new import)
import { createClient } from '@fastyoke/sdk-next'
const client = createClient({ apiKey: process.env.FASTYOKE_API_KEY })

The FSM schemas, entity definitions, form configs, and WASM scripts are identical. The migrations directory is identical. The app package you export from the Runtime Studio installs on a Cloud SaaS tenant or an On-Prem deployment without modification.

There is no "Runtime version" of the schema and a "Cloud version." There is one schema.

Honest tradeoffs

What Runtime isn't for

Not a production multi-user server. Single-node means no write-ahead log replication, no failover, and no WebSocket fanout to multiple app servers. For production workloads with more than one operator or any HA requirement, use Cloud SaaS or On-Prem.
No marketplace app auto-update. Cloud SaaS tenants receive marketplace app updates automatically. Runtime operators pull updates via npx fastyoke upgrade.
No managed backups. The SQLite file is yours — back it up yourself. Cloud SaaS and On-Prem 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 the restart; in-flight HTTP requests do not.
Single tenant per sidecar. The Runtime sidecar serves one tenant at a time. Multi-tenant development (e.g. simulating two isolated customer tenants) requires two sidecar processes on different ports.

Get started

# Requires Node 18+ for the CLI runner
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.

Read the getting-started guide

FastYoke for developers & ISVs

For ISVs embedding Runtime inside a client's firewall, see the On-Prem deployment guide — the same single binary runs in both modes.