Pranay Prakash
2bc368c424
- decompress() now gates only on DecompressionStream (read path), not
CompressionStream — reads work in decompress-only runtimes (Copilot).
- Cross-deployment writes (start({deploymentId}), resumeHook) restrict to
the portable gzip codec via a new compressionPortableOnly flag. zstd
decode needs node:zlib >= 22.15, a property of the reader's runtime that
the SDK (engines: Node 18+) can't guarantee for a different deployment;
same-deployment writes still use zstd since reader == writer (vercel bot).
- Browser zstd WASM is now vendored into web-shared dist and referenced via
a relative new URL('./zstd.wasm', import.meta.url) — a bare package
specifier was left unrewritten by Vite and 404'd. Verified the Vite build
emits the asset (karthikscale3).
- hydrateResourceIOWithKey accepts an optional key and always registers the
zstd decoder, so unencrypted compressed payloads (e.g. local world) are
inflated; web no-key hydration paths now route through it (karthikscale3).
- Clarify the sync-decompress doc contract (best-effort via
process.getBuiltinModule, not "always on Node") (Copilot).
Tests: cross-deployment gzip fallback, unencrypted compressed web
hydration, and zstd WASM ↔ node:zlib compatibility.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@workflow/web
Observability Web UI Package bundled in the Workflow SDK.
Self-hosting
Security notice: The
@workflow/webpackage does not include authentication or authorization. All users who can reach the deployment share the same backend credentials configured via environment variables. If you self-host this UI, you must place it behind your own authentication layer (e.g. VPN, reverse proxy with auth, OAuth). Exposing it to untrusted users without authentication is at your own risk and may allow unauthorized access to your workflow data.
While this UI is bundled with the Workflow CLI, you can also self-host it.
There are multiple approaches:
- Run
npx workflow web --noBrowseron a server - Clone this repo and deploy as a normal Next.js app
- Deploy the published
@workflow/webpackage
All options require the environment to be configured with the right environment variables for the World you're using.
Option 1: Run with the CLI
npx workflow web --noBrowser
This will start the web UI on the default port 3456.
Option 2: Clone and deploy
- Build and deploy like any Next.js app.
- Configure the backend via environment variables (same variables the CLI writes).
Option 3: Deploy the published @workflow/web package
The published @workflow/web package contains a prebuilt .next directory and package.json.
You can install it and run next start from the package directory.
Example (Node server / container):
mkdir workflow-observability-ui
cd workflow-observability-ui
npm init -y
# You must provide React runtime dependencies in your host project.
npm i @workflow/web react react-dom
# Run Next.js from the installed package (it contains the .next output)
cd node_modules/@workflow/web
npx --yes next start -p "${PORT:-3456}"
If you prefer, you can set a start script in your host package.json like:
{
"scripts": {
"start": "cd node_modules/@workflow/web && next start -p $PORT"
}
}
Configuration (environment variables)
The UI reads configuration on the server via environment variables.
-
Vercel (remote observability):
WORKFLOW_TARGET_WORLD=vercelWORKFLOW_VERCEL_TEAMWORKFLOW_VERCEL_PROJECTWORKFLOW_VERCEL_ENV(optional; defaults toproduction)
-
Local (filesystem-backed observability):
WORKFLOW_TARGET_WORLD=localWORKFLOW_LOCAL_DATA_DIR(absolute path to the workflow data dir, e.g./path/to/project/.workflow-data)WORKFLOW_MANIFEST_PATH(optional; enables the Graph tab)
-
Postgres:
WORKFLOW_TARGET_WORLD=postgresWORKFLOW_POSTGRES_URL
For a complete list and CLI flags, see npx workflow inspect --help and npx workflow web --help.
If you're deploying this to Vercel, setting WORKFLOW_TARGET_WORLD to vercel is enough
for the server to infer your other project details at runtime. Note that observability will be scoped to the project and environment you're deploying to.