Files
Pranay Prakash 11dc036854 ci: stop deploying changeset-release/main, run its e2e against production (#3243)
* ci: stop deploying changeset-release/main, run its e2e against production

The changesets action force-pushes `changeset-release/main`, and it can
point at exactly main's HEAD SHA. Vercel keeps one commit status per
project per SHA, so when both a production deployment (from main) and a
preview deployment (from changeset-release/main) are built for the same
commit, whichever finishes last owns the status. On 2026-07-30 the
preview finished last, so `vercel/wait-for-deployment-action` — which
reads the deployment ID out of that status — handed production e2e runs
a preview deployment ID and forked runs across environments.

Disable git deployments for that branch in every Vercel project rooted
in this repo, and give the changeset PR's Vercel e2e lanes a deployment
to test that actually exists: main's production deployment for the PR's
base SHA, resolved by SHA so a mid-flight production build is waited out
rather than silently replaced by an older one.

Signed-off-by: Pranay Prakash <pranay.gp@gmail.com>

* ci: resolve changeset-release e2e deployments with the wait action, tokenless

Per review: with changeset-release/main no longer deployed, main SHAs
can never again be deployed to a second environment of these projects,
so the per-SHA commit status the action reads is unambiguous for
exactly this lane. Reuse vercel/wait-for-deployment-action with
environment: production and sha pinned to the PR base SHA instead of
the Vercel-API polling script, drop the script and its VERCEL_TOKEN
usage, and inherit the action's inactive/skipped-build handling.

Signed-off-by: Pranay Prakash <pranay.gp@gmail.com>

---------

Signed-off-by: Pranay Prakash <pranay.gp@gmail.com>
2026-07-31 10:09:36 -07:00
..
2026-07-30 08:40:06 -07:00
2025-10-23 12:07:52 +03:00
2026-07-30 08:40:06 -07:00

@workflow/web

Observability Web UI Package bundled in the Workflow SDK.

Self-hosting

Security notice: The @workflow/web package 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:

  1. Run npx workflow web --noBrowser on a server
  2. Clone this repo and deploy as a normal Next.js app
  3. Deploy the published @workflow/web package

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=vercel
    • WORKFLOW_VERCEL_TEAM
    • WORKFLOW_VERCEL_PROJECT
    • WORKFLOW_VERCEL_ENV (optional; defaults to production)
  • Local (filesystem-backed observability):

    • WORKFLOW_TARGET_WORLD=local
    • WORKFLOW_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=postgres
    • WORKFLOW_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.