Skip to main content

Manage Projects with Server Web

Server Web is Workflow Server's browser-based console. After you publish from Desktop, use it to find Workflow, Conversation, and Kanban projects; run executable versions, preview Kanban, manage access and configuration, and inspect run logs.

From Sign-in to a Run​

Open Server Web

Open your Workflow Server URL. Without a valid session, Server Web opens the sign-in page.

Sign in

Sign in with email and password. The browser session can also complete CLI and Desktop device-flow authorization.

Find a project

Search the project list by project ID, name, latest version, uploader, or type. Only projects you can access appear.

Open project details

For a project declared as server or both, project details include Overview, Settings, Members, Knowledge Base, Run Logs, Versions, Scheduled Tasks, KV Data, Environment Variables, and Webhooks. Workflow also includes an MCP connection page. Embed appears only after the project has published at least one version. A local or undeclared project exposes only the read-only storage explanation in Settings.

Run or troubleshoot a workflow

Select an entry point from a Workflow's latest version and run it directly. Conversation has one session interface. After execution, open replay or detailed logs from Run Logs to inspect results and diagnostics.

What the Project List Provides​

Use the project list to find published workflows quickly:

  • Search by project ID, default/Chinese/English name, latest version, uploader, and type.
  • Filter by all, runnable, preparing, Webhook, Embed, and other states.
  • Sort by update time descending by default, placing recently updated projects first.
  • Inspect the current-locale name, project icon, manual declarations, display platforms, latest version, update time, and integration state.
  • Open details or run logs; projects with at least one published version can also open or configure Embed.

A project that has only been created and registered remains in the Server Web project list so it can be managed and published, but its table row, detail navigation, and Settings page do not show an Embed entry. Opening that project's Embed management URL directly returns to Project Overview without requesting Embed configuration.

The uploaded package.json supplies default and localized names, manual declarations, display platforms, and the data-storage declaration through the root name and workflowCode.projectInfo, with purely visual card metadata in workflowCode.projectCard. Names, ordinary declarations, and macOS/Windows/Web platforms remain display-only; dataStorage.mode is an enforced execution and data-access gate. Server Web supports only server and both. A local or undeclared project blocks every project-detail surface except the read-only Settings explanation. Project and version views still separately mark a release as Server runnable, Local only, or Static Web, and run surfaces require both a complete Server runtime and an allowed storage declaration. Workflow and Conversation types derive from executor projectType; Kanban derives from package.json.workflowCode.projectType.

Common Project Actions​

Run and inspect logs

Run a published workflow and inspect status, replay, stdout, stderr, and reports.

View run logsManage members and run controls

Configure owner, manager, runner, and viewer roles, invitations, and the run-block list.

View project managementConfigure server environment variables

Configure secrets and runtime parameters for remote runs, Embed, Webhooks, and External API.

View environment variablesExpose Embed or Webhooks

Enable a public page or external event trigger and configure tokens, mappings, and filters.

View integrations

The MCP page in Workflow project details selects draft, latest, or an exact version; copies the Streamable HTTP URL, Bearer template, and client JSON; and lists the fixed entrypoint/tool catalog. See Server MCP for connection and file-upload instructions.

Sign-in States​

The sign-in page always shows an explicit state while submission is in progress, fails, or the session expires. On failure, check the email and password, server address, and network connection.

Console Runtime Environment​

Workflow and Conversation runs started on Server report workflow.getRuntimePlatform() as "web". Normal, streaming, Debug, parameter-resolution, resume, and scheduled entry points all check dataStorage.mode before executing user code and continue only for server or both. Kanban is static HTML and does not start workflow runtime, but its static preview, KV, Knowledge, PersistentValue, management APIs, and Bridge use the same server-storage gate. The management client first obtains a short-lived preview capability scoped to project, user, target version, and expiration. The sandboxed iframe uses only that capability to load static resources and never inherits management login credentials. Related-project KV resolves an alias from the fixed version, then rereads both current declarations and the target project's read/write grant to the current project; callers cannot supply a target UUID.

Multiple Workflow entry points belong to one project's run catalog. Permission, queueing, members, KV, and PersistentValue remain project-scoped. A request selects exactly one entry point and creates an independent run. A business flow calls another workflow only when its source explicitly uses workflow.runWorkflow(). Server's External API concurrency is not limited by the Desktop or Embed UI's one-live-run focus.

Workflow schedules are pinned to an exact published version and entry point. They continue while the Server process runs. Server neither replays a fire missed during downtime nor queues a later fire while the previous run for the same plan remains unfinished. Managing schedules requires separate schedule.manage permission and project access. Each fire continues to use the creator's run permission and quota.

Console, Embed, and External streaming runs finish authentication, storage-declaration, request-field, exact-version, and entry-point validation before sending NDJSON or SSE response headers. An unknown entry point, forbidden server storage, missing declaration, an entry point supplied to Conversation, or another immediately recognizable invalid request returns HTTP 4xx JSON without creating a run. An execution error after streaming begins arrives as the corresponding NDJSON or SSE error event.

Server Web connects only to Server and never reads a local workspace, Electron project, or arbitrary local directory. It manages server projects, versions, run history, environment variables, schedules, Webhooks, and public Embeds, and can inspect uploaded Workflow or Conversation results and fixed-version Kanban previews. The Desktop or CLI selects local projects, applies .workflowignore, and uploads the archive. Server then installs dependencies and builds a runtime for Workflow or Conversation, while Kanban publication only validates and retains static HTML, JavaScript, image, and font artifacts.

Dates and Times​

Server Web shows run, update, sign-in, quota, schedule, and audit records that identify an exact moment as YYYY-MM-DD HH:mm:ss. Billing periods, statistical groups, and other calendar-only values use YYYY-MM-DD. Scheduled runs use the schedule's configured time zone; other records use the browser's current time zone. ISO timestamp fields in API requests and responses keep their protocol representation and are not changed by this display rule.

Mobile and Dark Mode​

Server Web supports mobile layouts, light mode, dark mode, and system theme. Mobile layouts preserve key state, filtering, and actions. Dark mode uses the same black and neutral-gray foundation as Desktop while success, waiting, and error retain distinct semantic colors, keeping badges, tables, drawers, and dialogs legible. Result notifications appear above dialogs and overlays so feedback remains readable while a dialog is open.