Pipo is an always-on workflow engine for your connected computer.
It keeps context over time, watches for the work that repeats, and acts through the tools you already use — while your authority stays in the loop.
Before you deploy Pipo
Pipo is not a tab-bound chatbot. It is a persistent system with a brain, a computer control surface, and workflows that can keep running after you close the window.
Installation
Pipo runs as a Bun daemon or a Docker container. The dashboard
listens on http://localhost:1846 by default. Choose
Docker for the fastest cross-platform start, Bun for a native
development install, or a source checkout when you want to build
and extend Pipo.
docker run -d --name pipo \ -p 1846:1846 \ -v pipo-data:/data
\ ghcr.io/Motius/pipo:latest # after the container is healthy,
enroll a computer docker exec -it pipo pipo enroll
"my-desktop"
bun install -g @pipo/brain, then
pipo start. The first run opens guided
setup.
git clone https://github.com/Motius/pipo.git,
bun install, bun run build:ui,
then bun link.
/data persistent. It contains the local
database, configuration, logs, and encrypted runtime
state.
Docker can run on Windows, macOS, and Linux. The container cannot see the host desktop by itself; install a connected sidecar on each computer that Pipo should control.
Quick start
- Install the Pipo runtime.Run the installer for your operating system and sign in to the workspace you want this computer to serve.
- Enroll your computer.Name the machine, select its workspace, and confirm the sidecar connection.
- Set the boundary.Allow reading first. Require approval for sending, editing, and anything that changes external state.
- Ask for a repeat.“After every meeting, draft the follow-up for me to approve.” Pipo turns the outcome into a workflow draft.
Requirements
Prepare the runtime before you connect real accounts. Pipo needs a supported runtime, a writable data location, and at least one model route.
Make the first run useful
The fastest way to understand Pipo is to complete one small, reversible workflow. Do not begin by granting every permission or connecting every account. Start with a read-only task, confirm the context, then add one approval step.
-
Open the dashboard.Visit
http://localhost:1846afterpipo startor the Docker container is healthy. If the page does not load, runpipo statusand confirm that port 1846 is free. - Complete setup.Choose a model provider, set your voice preference if needed, and answer the short profile questions. These choices shape how Pipo interprets goals and communicates uncertainty.
- Connect one source.Choose the notes, files, browser session, or application that contains the context for your first task. Keep the source list narrow so the result is easy to inspect.
- Run a read-only request.Try: “Read today’s meeting notes and prepare three follow-up actions. Do not send anything.” Confirm that Pipo cites the source and keeps the output in review.
- Add one approval gate.Only after the draft is correct should you allow a consequential step. Keep sending, deleting, account changes, and public publishing behind Ask or Block rules.
Prefer drafting, summarizing, classifying, or preparing a file over sending a message or changing a production system. You are learning the boundary as much as the feature.
Configuration
Pipo’s configuration is designed around intent rather than plumbing. Set a goal, connect sources, choose an authority level, and keep the workflow inspectable.
Platform support
Pipo is designed around a persistent daemon and local sidecars. The dashboard works in any modern browser, while connected sidecars run across macOS, Windows, and Linux.
High-level architecture
Pipo has three layers: a daemon, a dashboard, and sidecars connected to the machines where work happens.
Daemon
The daemon is the always-on layer that keeps Pipo useful after the prompt is gone. It owns the durable context and coordinates judgement with programmed execution.
Dashboard
The dashboard is the full control plane for Pipo. It keeps the ambient feel of a desktop utility while giving you a clear place to inspect what happened and what happens next.
Workflows
A workflow has a trigger, programmed steps, AI judgement where it is useful, and approval points where you want to remain the decision-maker.
Core capabilities
Pipo’s product areas are designed to work together. A goal informs a workflow; memory gives it context; authority decides how far it can go.
How to think about Pipo
Pipo is easier to operate when you separate four ideas that are often mixed together in AI products. Each one answers a different question about a run.
Cross-platform setup
Keep the daemon hosted and use your connected computer as a deliberate sidecar. That gives Pipo a persistent brain without turning every app on your laptop into an open door.
Desktop sidecar
The connected sidecar is the local companion that lets Pipo operate on this computer. It authenticates to the daemon and exposes only the capabilities you choose.
- Desktop automation for approved applications
- Browser control for reading pages and filling fields
- Terminal access with explicit workspace scope
- Filesystem and clipboard access under your rules
- Screenshots and awareness capture when enabled
CLI commands
pipo statusShow daemon, workspace, sidecar, and authority
status.
pipo enroll "desktop-name"Mint an enrollment token for a sidecar device.
pipo sidecars list --jsonList enrolled sidecar devices.
pipo doctorCheck the runtime environment and connectivity.
pipo logs -fStream recent workflow and authority events.
Local models with Ollama
Pipo can route judgement to a local Ollama service when you want to keep model inference on your own machine or network. Self-hosting the daemon does not automatically make every provider local, so check each connection separately.
ollama serve ollama pull llama3.1 # In Pipo Settings, choose
Ollama and set: # http://127.0.0.1:11434
-
If Pipo runs in Docker,
localhostpoints inside the container. Use a reachable host address or container network name instead. - Keep the local model endpoint private; do not expose it to the public internet without authentication and a deliberate network policy.
- Local inference can reduce provider egress but may require more memory, slower responses, or a smaller model.
Operations
Once the first workflow works, make the runtime boring: persist data, keep the port stable, watch logs, and define how Pipo starts after a reboot.
pipo status # daemon, port, sidecars, provider pipo logs -f #
follow the active log pipo doctor # inspect environment and
connectivity pipo restart # restart after setup or
configuration
pipo autostart on Linux or macOS to
install a user service. On Docker, use Docker’s restart
policy and keep the data volume attached.
Never publish an unauthenticated dashboard to the internet. Start on localhost, enroll devices, then add a protected reverse proxy only after the local flow is understood.
Logs, health, and recovery
When a run feels slow or stops, start with evidence instead of changing several settings at once. Pipo exposes the daemon state, sidecar connection, provider route, workflow event, and authority decision separately.
pipo status # process, port, sidecars, provider pipo doctor #
environment and connectivity checks pipo logs -f # follow live
daemon output # Docker alternative docker logs -f pipo
Start with status +
Confirm that the daemon is running, that it is listening on port 1846, and that the expected workspace and sidecar are connected. If the daemon is stopped, check the first error in the startup output before restarting repeatedly.
Then check the provider route +
A reachable dashboard does not prove that a model provider is configured. Check the selected provider, model name, endpoint URL, and whether a Docker container can reach a service that is running on the host.
Then inspect the authority event +
If a workflow pauses, that may be a deliberate Ask boundary. Read the exact proposed action, approve or edit it, and only widen the rule when the workflow is understood.
Keep logs free of secrets. Pipo redacts common credentials, but you should still avoid copying tokens, private messages, or sensitive screenshots into public issue reports.
Scaling safely
Start by adding capability to one authoritative daemon and multiple sidecars. Do not run two daemons against the same local data directory. When the workload grows, separate execution capacity and durable state deliberately.
- Back up the Pipo data directory or Docker volume before upgrades.
- Test restores in an isolated environment, not against the live workspace.
- Keep email, payments, deletion, account changes, and public publishing behind approval gates.
- Use canary releases and a known-good rollback version for both daemon and sidecar.
Troubleshooting
The sidecar is offline +
Open Pipo from your system tray or app launcher, confirm the
workspace name, confirm that the sidecar application is
running, and use pipo enroll "device-name" when
the device needs a new enrollment token. If the operating
system paused a permission, revisit its privacy and security
settings.
A workflow stopped for approval +
That is expected when the next step crosses an Ask boundary. Review the draft in the dashboard and approve it, edit the authority rule, or leave it paused.
Pipo used the wrong context +
Check the workflow’s connected sources and Memory entries. Tighten the input list before raising the workflow’s autonomy.
A run is repeating unexpectedly +
Open the workflow’s run history and inspect the trigger event. Use test mode, add an idempotency guard, or pause the workflow before reconnecting the source.
Useful first workflows
Choose a routine that happens often, has a clear input, and can be reviewed before it changes the outside world. These examples show the level of specificity that makes a workflow dependable.
Privacy & data
Pipo’s usefulness depends on context, so every connected source should have a reason to exist. Keep data access narrow, review what is stored, and remove a connection when the workflow no longer needs it.
Disclaimer & liability
Pipo can act in connected applications and on your connected computer. Review permissions, workflow definitions, generated outputs, and approval prompts before relying on them for business-critical work.
Do not give Pipo unrestricted access to accounts, files, or systems. Start in test mode, use least-privilege permissions, keep destructive actions blocked, and maintain backups for important data.
This documentation describes the intended product model, not legal, security, financial, or operational advice. Your workspace owner and your organization’s policies determine what you may connect and automate.