Employees work in the client, and the skills and agents they build can be shared with everyone. Usage, budget and audit stay on your own server. The deliverable is a single container image: server, embedded PostgreSQL, reverse proxy and the installers for all supported platforms are inside it, so employee machines never need the public internet.
Most companies stall in the same place — individuals do well, the organisation captures nothing. This platform exists to close the last three steps: capture know-how, reuse it, and make the level visible.
People reach for outside tools, data leaves the company, and spend is a black box.
Every team wires up its own stack and nothing can be reused next door.
Skills, agents and apps become searchable, approvable and reusable assets.
Management can see the water line: who uses AI, where, at what cost, and what got reused.
How the Capability Hub and memory work · What administrators can measure · Apps built by employees
The client handles interaction, the local service runs the agent, and the server owns accounts, models and audit. Each layer upgrades on its own; there is exactly one interface between them.
A native window with tray, terminal and automatic updates. Chat, Capability Hub, connectors, scheduled jobs, the built-in browser and voice input all live in one place.
Starts, stops and recovers the local Harness service automatically. Sessions, files and workspaces stay on the machine; model traffic goes through your gateway.
One intranet server carries accounts, the model gateway, metering, approvals and audit. The admin console is embedded in the same image.
Available out of the box, with no third-party extensions to install — and every one of them configured and audited centrally.
Every session is bound to a project directory; file writes, shell commands and browser actions are confirmed per call through the permission gate.
Skills and agents, from your own library or the shared marketplace — install, update, uninstall and review upload status in one place.
Reach internal systems with one standard MCP configuration. OAuth authorisation and token renewal happen automatically; credentials stay encrypted locally.
Upstream Schedule reminders (once / interval / daily / weekly / cron) delivered back to the original session; account-scoped with delivery history.
The agent can drive a real browser: tabs, address bar, download control and an operation log. Control changes hands only through the “I will take over” button.
Dictate into the composer. Recognition runs in a local subprocess — audio never leaves the machine, works offline, and the model ships with the client.
User profile, global facts, project key memory, project log and daily log — scoped by directory and git branch, written only after you confirm.
Employees build their own WASM apps with AI. They open in a dedicated client window; the server needs no public hostname or certificate for them.
Desktop client guide · Plugin development · Plugin ecosystem
Sessions and workspaces, Capability Hub, connectors, scheduled jobs, the built-in browser, voice input and five-track memory.
Desktop client guide→Accounts and authentication, model catalogue, budget and billing, capability approvals, usage and audit.
Enterprise control plane→One image for deploy, upgrade and rollback; air-gapped installs, channel delivery and troubleshooting.
Deployment guide→
The console is embedded in the server image at /admin/ and its sidebar
follows the RBAC permissions of the signed-in administrator: super admins see
everything, auditors get read-only views, employees never reach it.
The water line is measured, not surveyed — the usage centre reports real calls and cost
by department, member and model.
No install scripts, no registry mirror and no Git checkout on the deployment machine. The image carries everything needed for a first deployment, an upgrade and a rollback.
Download the image archive and SHA256SUMS from your channel, verify them
and docker load. No registry is involved, so an isolated network can import the archive by hand.
One command writes the compose file, the three certificate variants and the client
installers into your deployment directory; then fill in .env.
docker compose up -d brings up Caddy, the server and the embedded
PostgreSQL. The health probe and the client manifest are the acceptance criteria.
Employees download the client from your portal and sign in. Clients follow the server, so upgrading the server upgrades every client.
# 1) Verify and import the image (<version> comes from latest.json -> server.version, without the leading v)
curl -fL -O https://release.picoaide.com/official/releases/<version>/picoaide-server-<version>-amd64.zip
unzip -p picoaide-server-<version>-amd64.zip image.tar | docker load
# 2) Export the stack files (the image carries compose / Caddyfile / client installers)
docker run --rm -v /opt/picoaide:/out -e PICOAI_UNPACK_STACK=/out \
picoaide-harness-server:<version>
# 3) Fill in .env, start, and confirm the health probe
cd /opt/picoaide && docker compose up -d
curl -k https://<your-domain>/healthz picoaide-data/ (including master.key) and pg-data/
live in the deployment directory. Upgrades replace the image, never the data; a rollback
is a pointer change.
Self-signed for a pure intranet, automatic issuance for a public domain, or your own
enterprise certificate — switch TLS_MODE in .env.
Never a -v teardown, never the latest tag, always back up and
verify the backup is non-empty before upgrading, and never overwrite an existing
deployment's .env.
Deployment overview · Upgrade, backup and rollback · Client delivery and updates · Air-gapped deployment · Operations and troubleshooting
One build per channel, and the brand is never washed away by an upgrade.
Windows, macOS and Linux installers are packed into the server image and served by your
own server (/api/client/v2/updates/manifest and /updates/client/*),
so a version mismatch is structurally impossible.
Installing, signing in and updating all happen against your domain. Resumable downloads and SHA-256 verification are built in, so a LAN can distribute a few hundred megabytes reliably.
Name, tagline, welcome copy, mark and accent colour come from the channel content shipped with the image — one configuration drives the sign-in page, the client, the console and the portal. Channels never upgrade into each other.
Every statement below maps to a concrete implementation and an automated check — not an adjective.
Upstream keys are stored with AES-GCM (enc:v1: prefix, master key in its own file); credentials are written atomically with 0600/0700 permissions, guarding against symlinks and path escape.
Employee API tokens expire after 90 days and only their hash is kept; password, role and status changes revoke them in the same transaction. Admin sessions are capped at 12 hours with idle expiry and CSRF protection.
Sessions choose read-only, workspace-write or full access. Writes are confined to the workspace and a private temp directory (Landlock on Linux, ACLs on Windows); anything outside is refused.
The client ignores system proxies by default and its only update source is the server it signed in to. With no server configured it performs no outbound check at all, so an isolated network works offline.
Unauthorised marketplace and shared content returns 404 rather than revealing existence; grant changes are audited; admin actions pass both RBAC and the audit trail.
Data, keys and the ledger live on your own machines in bind-mounted directories, shipped with the image. No per-seat licence fee, and nothing handed to a third party.
Real product screenshots, no visual retouching.
Every release is curated: who must upgrade, and what happens if they do not.
Server image archives and checksums for the public channels. Channel-specific builds are served from each deployment's own update directory.
Back up, verify the backup is non-empty, swap the image tag, and keep the previous image as the rollback anchor.
Installers ship inside the server image and update against the manifest the server publishes, so clients and server always move together.
The Wiki ships in English and Simplified Chinese; every page has a language switcher.
What the platform is and how to read this Wiki.
From an empty machine to a signed-in client.
Every surface an employee touches, in detail.
Accounts, gateway, metering, approvals and audit.
Bring up server, database and proxy on your network.
Move versions without losing data.
Management and client-side endpoints.
Common questions about deployment and data.
The upstream project provides the core agent, plugin system and web UI. This project adds the desktop shell, the local service lifecycle and the enterprise server, built on a pinned upstream revision that is never patched. The desktop shell itself is a regular DSH plugin.
Yes — that is the primary form. The deliverable is a single container image (server, embedded PostgreSQL, Caddy and the installers for all supported platforms). Three certificate modes are available and all data lives in bind-mounted directories. You can also join an existing reverse proxy, or run the single binary against an external PostgreSQL.
No. Clients download and update from your own server; employee machines only talk to your domain. A fully isolated network can import the image archive offline.
By upgrading the server. Client installers ship inside the server image, and each client periodically asks the server it signed in to for a new version, verifying the SHA-256 from the manifest before installing. A client can never drift ahead of its server.
The model catalogue and upstream API keys are configured in the admin console. Keys are encrypted on the server; clients receive a model list and a session token only, so no upstream key ever reaches an employee machine.
Through the two standard forms: enterprise capabilities ship as SKILL.md and are distributed by the Capability Hub with approval and grants, while MCP capabilities use the connector framework with a single standard configuration. Both are auditable, approvable and revocable.
Yes, under the MIT licence, free of charge. The upstream project runs unmodified at a pinned version, and upgrades only follow upstream releases.
Windows x64 (NSIS installer), macOS on Apple silicon (DMG, signed and notarised for stable releases) and Linux x64 (AppImage). Linux deb packages are not part of the enterprise delivery surface.
Pull one image and follow one guide for deployment, upgrade and rollback. Employee machines stay off the public internet.