Skip to main content
Use this path if you are setting up the runtime, picking how OpenWork should run, or deciding how teammates connect to a worker.

​
Pick a runtime

Desktop-hosted app/server

OpenWork runs locally and hosts the server on-device. Use this when you want the app and server together.

CLI-hosted server

openwrk or openwork-server runs on a trusted machine. Use this when you want automation without the desktop app.

​
Start the setup

Start with the app

Download OpenWork, create a worker, and use the desktop-hosted path for the fastest local setup.

Start with the CLI

Install openwrk, inspect status, and run headless when you do not need the desktop UI.

See the runtime model

Review desktop host mode, CLI host mode, and remote client mode before you commit to one path.

Create a shareable instance

Follow the operator playbook for one worker, one share path, and one scheduled automation.

​
Share it

Use the current share flow when another person needs access to a worker you already host.
  • Fastest: open worker actions, choose Share, then send OpenWork invite link.
  • Manual: share OpenWork worker URL + Access token.
  • Owner-only: keep host token private for approvals and admin actions.
  • Teammates connect through Add worker -> Connect remote.

Use the invite link

Prefill URL, token, and startup mode in one step.

Plan full workspace sharing

See the target design for sharing more than runtime access.

​
Extend it

Once the runtime is stable, wire in messaging and stricter operations.

Route Slack and Telegram

Map chat surfaces to the right worker directories.

Upgrade worker runtime

Keep runtime operations predictable as you change the stack.