Deployment step 1: official image and one isolated instance per person

Why

Today FlyBot runs locally per user. To try it without local setup, to keep Bots working while a laptop is closed, and to prepare team mode (#51 per-Bot grants, #149 task layer), users need an isolated, repeatable deployment. Step 1 is deliberately small: one instance per person, no multi-tenancy.

Step 1 scope: isolated per-person deployment

Official container image for FlyBot (core plus bundled plugins), built and published by the existing release flow on each tag (see Release cadence: at least one tag per day, small and stable #351).
One-command deploy on a Linux server or any container host, with a short zh/en guide: start, stop, upgrade, back up.
One instance per person: own data volume, own secrets, own port; nothing shared between instances.
Persistence and backup: data volume documented; a simple backup/restore command; upgrade keeps data and can roll back to the previous image tag.
Secure defaults: no default passwords or tokens in the image; secrets via environment or mounted files only; non-root user; only the needed port exposed; sign-in required before any remote access.
Health and logs: a health endpoint and readable logs for diagnosing failed starts.

How instances talk to each other

Only through Bot Social (friends, grants, approvals), as between two local users today. This is what makes isolation natural for team mode: a teammate's instance is just another friend with granted Bots.

Acceptance

Fresh machine to a running instance in under 10 minutes by following the guide.
Two instances on one host cannot read each other's data or secrets (verify, document how).
Restart and upgrade keep data; rollback works.
No secrets in the image layers or logs.
A real two-person trial: two deployed instances become friends, one sends a task, the other approves (feeds [Team] Verify the real two-human team pilot end to end #58).

Later steps (out of scope here)

Step 2: team mode requires one instance per member, with permissions from [Team] Gate cross-owner agent routes by per-Bot grants (default deny; superseded the publication gate) #51 and audit from [Team] Add a human-readable authorization and task audit trail #57.
Step 3: managed hosting if there is demand, with one isolated space per person (Linux user, container, firewall), sign-in portal, rollback updates and nightly backups; the private orbit-cloud repo is a reference for this.

Open questions

Which hosts do we officially document first (plain Docker, Compose, a cloud VM)?
How does a user sign in to a remote instance safely (token, SSO, reverse proxy)?
Where is the image published and under what tag policy?
Which parts of Desktop-only features need a headless equivalent?

Process

Image, workflow and docs changes go through cloud OpenCode, review via Codex; bots do not hand-write code.

Triage on main 7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-human, not agent-ready. Question for the owner: start the official container image / one instance per person now? It touches the release flow (owned by the daily release routine) and secure defaults, so it needs a yes and a decision on where images are published.

Triage (maintenance, 2026-10-20 08:59 Asia/Shanghai)

On main bae4128: no Dockerfile, image or compose file. The release flow (release.yml) only uploads the npm .tgz files to the GitHub Release. FlyBot runs as DSH plugins inside dsh web --port 3080, signed in with the printed ?token= link. Schedules (core/src/host/schedules.js) run in that host process, so they keep firing as long as the process runs. That is all #355 needs.

Expected behavior: one person runs one isolated FlyBot on a Linux box. It has its own data volume, secrets and port, and keeps running with the laptop closed. Instances talk to each other only through Bot Social.

Smallest first slice (unblocks #355)

A Dockerfile and compose.yaml in the repo. The image runs dsh web (DSH pinned like the README) with FlyBot core, social and tree from the same commit or tag.
One data volume. Non-root user. No keys in the image: DEEPSEEK_API_KEY and others come from env or mounted files.
A health check, plus a short zh/en guide: start, stop, upgrade (change the tag), roll back (previous tag), back up (copy the volume).
CI builds the image and runs a start/health smoke when these files change. Nothing is published or deployed.

Details I decided (say if you disagree)

Sign-in stays DSH's own token link. No new auth. By default the port is bound to 127.0.0.1 on the host, and remote access goes through your own HTTPS proxy or SSH tunnel.
Bot Social is not in the image. It stays self-hosted on its own.
The first slice does not touch release.yml, which the daily release routine owns. Desktop-only features are left out of step 1.

Question for the owner
(a) Ship the slice above. You build the image locally. Publishing to a registry is a separate small step after your yes.
(b) Same as (a), and release.yml also pushes ghcr.io/thinkflowlab/flybot:<version> on each tag.
(c) No container yet. Only a guide for running dsh web as a systemd service on a Linux VM.
Recommendation: (a).

Owner decision (2026-10-20): Confirmed option (a): add a Dockerfile, a compose file and a short English+Chinese guide. One data volume, non-root user, no secrets in the image, port bound to localhost by default; remote access via the user's own HTTPS proxy or SSH tunnel. CI only builds and runs a start check; no publishing or deploying. Pushing to an image registry needs a separate confirmation later.

Claimed by maintenance run (2026-10-20 09:54 Asia/Shanghai). Working on branch feat/352-docker-image (fork Birfy/FlyBot), developed in parallel with sibling issues; first slice per the Owner decision only.

PR #482 (branch feat/352-docker; the earlier claim's feat/352-docker-image had no commits). Minor details I decided:

Base image node:24-bookworm-slim (tag, not digest); DSH 0.2.0-rc.2 and pnpm pinned as build args; tini as init.
The image contains the FlyBot core plus social, tree and timeline (timeline stays off by default). Each start links them into /data/profiles/web, so a new image is a new FlyBot while cordis.patch.yml and plugins you added yourself stay on the volume.
/data is DSH_HOME and HOME (pnpm store) and holds the Bots' working folder /data/workspace.
Inside the container DSH binds 0.0.0.0 via a profile overlay (the CLI refuses --host 0.0.0.0, the webserver config allows it); compose publishes on host 127.0.0.1 only; host port via FLYBOT_PORT, image tag via FLYBOT_TAG; more people on one machine via docker compose -p <name>.
Health check: GET / answers (401 without cookie). CI Docker workflow runs only when the image files change; no push or registry login.
The guide lives in docs/docker.md / docs/docker.zh.md, linked from both READMEs' Quick Start.
(2026-10-20 11:01 Asia/Shanghai)

Cleanup: issue closed. Removing stale agent-working and assignee.

Navigation Menu

Repository navigation

Deployment step 1: official image and one isolated instance per person #352

Why

Step 1 scope: isolated per-person deployment

How instances talk to each other

Acceptance

Later steps (out of scope here)

Open questions

Process

Triage (maintenance, 2026-10-20 08:59 Asia/Shanghai)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Deployment step 1: official image and one isolated instance per person #352

Description

Why

Step 1 scope: isolated per-person deployment

How instances talk to each other

Acceptance

Later steps (out of scope here)

Open questions

Process

Activity

Birfy commented on Oct 19, 2026

Birfy commented on Oct 20, 2026

Triage (maintenance, 2026-10-20 08:59 Asia/Shanghai)

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions