Yoke.sh
Deployment

Compile & deploy

Compile a TypeScript package into a CLI binary crate or an embeddable library crate — TypeScript is baked into Rust.

Yoke separates authoring from embedding:

ModeCommandUse when
Devyoke dev / yoke startIterating on the internal package from source
Compile (CLI)yoke compile -o dist/cliBinary crate: run / control-plane / worker with TS baked into Rust
Compile (library)yoke compile --crate -o crates/yokeLibrary crate for your CLI/server workspace — no binary
Runyoke runDev colocated host from a source tree without compiling

Both compile modes embed the TypeScript package with include_dir. The generated crate does not take a path to yoke.ts. It still depends on yoke-runtime / yoke-core.

yoke compile (CLI binary)

Emit a binary crate you cargo build and run as a Yoke CLI (worker, control-plane, colocated run):

yoke compile ./your-package -o dist/my-app
cd dist/my-app && cargo build --release
./target/release/my_app run
./target/release/my_app control-plane --database "$DATABASE_URL"
./target/release/my_app worker --database "$DATABASE_URL" --tenant-id default
FlagPurpose
-o, --outputOutput directory for the generated crate
--no-bundleCopy source only; skip deno bundle

When Deno is available, compile attempts deno bundle and embeds bundle.js. Otherwise it embeds the copied yoke.ts tree (format: source). Either way the files live inside the Rust crate (package/ + include_dir!).

Output layout (CLI)

dist/my-app/
  Cargo.toml           # [[bin]] only — no [lib]
  src/main.rs          # run / control-plane / worker
  package/             # baked in via include_dir
  README.md

yoke compile --crate (library)

Emit a library crate for a product workspace. No binary. Other crates (server, cli, …) depend on it. TypeScript is baked in; those crates never receive a yoke.ts path.

yoke compile ./packages/runtime -o ./crates/yoke --crate
crates/yoke/
  Cargo.toml             # [lib] only — no [[bin]]
  src/lib.rs             # start_colocated, start_worker, materialize_package
  package/               # include_dir
  README.md
# crates/server/Cargo.toml
my_product_yoke = { path = "../yoke" }
let rt = my_product_yoke::start_colocated(database, data_dir, "default", 8090).await?;

When format is bundle, the host does not need the TypeScript source tree. With format: source, Deno/npm resolution still runs inside the embedded libdeno worker after the crate materializes the baked-in files to a temp dir.

yoke dev

Hot path for package authors — loads source directly, same as yoke start:

export DATABASE_URL=postgres://yoke:yoke@localhost:5432/yoke
export YOKE_STORAGE=pg_sqlite

yoke dev ./your-package --database "$DATABASE_URL"

Boots a single tenant executor with portal HTTP on port 8080. No control plane scheduler — use this while editing yoke.ts and actor definitions.

yoke run

Colocated single-tenant — control plane and worker in one process, from a source tree (not a compiled crate):

export DATABASE_URL=postgres://...

yoke run \
  --package ./your-package \
  --database "$DATABASE_URL" \
  --cp-port 8090

Sets automatically:

VariableValue
YOKE_DEPLOYMENTcolocated
YOKE_SANDBOXin_process
YOKE_SCALE_TO_ZERO0

For a shippable CLI, use yoke compile (no --crate) and run the generated binary. For a product workspace, use yoke compile --crate and call start_colocated from your crates.

Deployment models

yoke compile ./packages/runtime -o ./crates/yoke --crate

Depend on crates/yoke from crates/server and crates/cli. Intended production path — embed.

Rust embedding

The intended production path is yoke compile --crate plus a dependency from your crates. Full walkthrough: Embed Yoke in your product.

// your server crate — depends on the generated library, not on a yoke.ts path
let rt = my_package::start_colocated(database, data_dir, "default", 8090).await?;
let yoke = /* Worker::runtime() after start_worker, or conversation_ops via control plane */;

The generated library re-exports YokeRuntime, Worker, EventInput, and start_colocated / start_worker. Product crates should not pass package_path to a source checkout.

See CLI for authoring subcommands and Environment for variables.

On this page