← Workflow Companion overview

Workflow Companion
deployment guide.

Install a private workspace, complete a synthetic-data workflow and rehearse recovery before adding your own records.

1. Choose your workspace

Workflow Companion 0.1.0 documents permitted Order Desk screen metadata as private, versioned walkthroughs. It previews deterministic guidance, saves revisions, exports JSON and compares versions in the workflow-classic layout. Actor labels describe the supplied metadata and do not grant access to another application.

2. Verify and install privately

Verify the downloaded archive and release metadata with the Store verification helper and public key before extraction. Confirm the key fingerprint through a separately trusted ProgreTech channel. Use the private Linux recipe in the included buyer guide, a dedicated service account and a new external data directory. Keep the development listener on loopback.

python3.13 -m venv .venv
.venv/bin/python -m pip install --require-hashes --only-binary=:all: -r distribution/requirements.lock
.venv/bin/python scripts/state.py init --data-dir /srv/private/workflow --username operator --lang en
export WORKFLOW_DATA_DIR=/srv/private/workflow
.venv/bin/python main.py --port 8080

Get the release verification helper

Get the Store public key

3. Complete your first workflow

Sign in, confirm permission, choose an actor and load the Order Desk example. Preview the guidance, arrange its steps and save explicitly. Save a second revision from the current base_revision, then export and compare both revisions in My library. Imported UTF-8 JSON must match the included schema and stricter domain checks: 1–200 visible metadata nodes and 1–40 distinct selected IDs. A stale save returns HTTP 409.

Workflow Companion source application, 1440px.
Workflow Companion local source-edition capture with synthetic screen metadata.

4. Set up your coding agent

Use a coding agent that can read project files and run commands. On Windows use PowerShell; on Ubuntu or macOS use Terminal. Check opencode --version before installing: OpenCode 1 and 2 share the command name, so preserve an existing working installation. For a fresh OpenCode 1 setup, install Node.js LTS with npm and Ollama for your OS, then run npm install -g opencode-ai.

For the local OpenCode route, use Ollama 0.15 or later and an already installed model with tool-call support and at least 64k context. Open a terminal in the extracted source folder and run ollama launch opencode. Confirm the chosen provider is local and the agent can open the named source files. Review its diff and commands before applying them. Plain ollama run chat accepts sanitized pasted text; it cannot read the folder or apply a patch by itself.

Prompt: Read docs/en/buyer-cookbook.md and the technical specification before changing the source. Prepare my chosen private Linux VM and external data directory. Preserve roles, CSRF and EN/ES/JA. Keep metadata-only import, private revisions and stale-save conflicts intact. Use synthetic data, return a diff, exact commands and backup/restore/rollback steps, and keep secrets and private records out of prompts. Ask before provisioning or paid actions.

node --version
npm --version
ollama --version
ollama list
opencode --version
ollama launch opencode

OpenCode installation and version choice

Connect OpenCode to Ollama

Node.js installers

Ollama installers for your OS

5. Choose a persistent cloud VM

Use one buyer-owned persistent Linux VM: Hetzner Cloud with a Volume, AWS EC2 with EBS, Azure VM with Managed Disk, or Google Compute Engine with Persistent Disk. Keep SQLite on a single durable local filesystem.

Terminate TLS at a maintained reverse proxy, preserve the exact approved hostname and keep Gunicorn on loopback. Restrict SSH to authorized administrators and verify the host fingerprint before connecting. Review the service, firewall and backup commands before provisioning.

Set WORKFLOW_DATA_DIR to the private state directory and WORKFLOW_PUBLIC_ORIGIN to your exact HTTPS origin. Preserve Host and scheme through the trusted proxy and keep config.json, workflow.sqlite and backups private. Do not enable arbitrary forwarded-header trust.

export WORKFLOW_DATA_DIR=/srv/private/workflow
export WORKFLOW_PUBLIC_ORIGIN=https://workflow.example.com
.venv/bin/gunicorn --bind 127.0.0.1:8080 --workers 1 --threads 4 wsgi:application

6. Back up and recover

Back up through scripts/state.py to a new file outside source. Stop the service and restore into a fresh private directory. Restore checks integrity, rotates the signing secret and clears sessions; sign in again and compare saved revisions, JSON export and guidance. Keep the original state until the restored copy is accepted. The existing backup filename is protected against accidental overwrite.

.venv/bin/python scripts/state.py backup --data-dir /srv/private/workflow --file /srv/backups/workflow-new.sqlite --lang en
.venv/bin/python scripts/state.py restore --data-dir /srv/private/workflow-restored --file /srv/backups/workflow-new.sqlite --lang en

7. Keep access and scope clear

Each operator keeps a separate library protected by session authentication, consent and CSRF. Review imported labels and provenance yourself. The app rejects executable and input-value fields and performs no target URL fetch, browser action or model call. Offline help is public and excludes saved walkthroughs. BTP service mappings are planning guidance, not an included deployable profile. Preserve notices and the Source License.

Read the canonical Source License