Automated Business Operating System¶
A multi-tenant, config-driven automation platform for Australian SMBs.
Git is the source of truth
Everything here is markdown in octopodia-abos/docs/, reviewed through pull requests. This site renders it; the BOS Console links to it. Neither ever edits it (ADR-0028).
If this site is unavailable, the same content is readable from GitHub, from a local clone, or with cat on the box. That is the point.
Start here¶
-
Open Items: what still has to be resolved, decided or verified, and what each item blocks. Distinct from the roadmap: this register holds what must be resolved, the roadmap holds what will be built.
-
Closed Items: what was settled, when, and where the decision now lives. Kept so a question that resurfaces is not re-litigated from scratch.
-
VPS setup runbook: standing up and hardening a host, top to bottom. Two-phase SSH so you cannot lock yourself out.
-
Stack and sizing: what each component does and what it costs in RAM. Use the worksheet before provisioning a host.
-
Provisioning build order: which Ansible role owns which decision, and the safe order to build and run them.
-
Known traps: environment-specific behaviour that costs an evening if you meet it cold. Symptom-to-cause table; read before provisioning, and again when something breaks.
-
Decisions: the ADR index. Immutable once accepted; superseded, never edited.
The shape, in one line¶
A shared, stateless brain plus per-tenant isolated stacks, driven by config resolved at runtime, acting on the tools clients already run. Own the spine (state, decisions, memory) and orchestrate the body.
Rules that override convenience¶
| Rule | Why | ADR |
|---|---|---|
| Config, not code | New behaviour is config in the control plane, never a per-client fork | ADR-0003 |
| Control plane holds the map, never client content | No emails, no invoices, no client data in the registry. Ever | ADR-0006 |
| Data residency is hard | Everything client-facing stays on AU infrastructure | ADR-0008 |
| No review, no go | AI-generated actions require human approval. Deterministic automation does not | ADR-0026, OI-039 |
| Store as little client data as we can | Their system is the system of record. Back up by recoverability, not importance | ADR-0026 |
| Read before you write | Read AGENTS.md and the target file before editing. Prevents ADR collisions and lost content |
n/a |
Where things run¶
| Surface | What it is | Runs on | Deployed by |
|---|---|---|---|
| This site | Architecture decisions, runbooks and registers. Read-only: authored in git, never in a browser | Cloudflare Pages, deliberately off-box, so a runbook survives the outage it is used in | Git push to main |
| BOS Console | Operator-only. Tenant records, resolved config, rules and thresholds, provisioning state. The only surface that writes the control plane | The VPS, in the core stack, behind Caddy | Ansible |
| Client review app | Per tenant, client-facing. Approvals inbox and history, plus headline metrics and dashboards. Reads its own tenant's data only, with no control-plane write access | The VPS, one stack per tenant | Ansible |
| The brain | Shared and stateless. LangGraph engines: Capture, Progress, Bill, Remember. Read-only against the registry | The VPS, in the core stack | Ansible |
| Registry | The control plane's Postgres: the map, never client content. Its own network; tenants reach it only through the brain's API | The VPS, isolated network | Ansible |
| Tenant stack | Per client: isolated Postgres (the spine) plus a dedicated n8n instance for connectors, credentials and triggers | The VPS, one per tenant | Ansible |
| Ansible | Provisions and deploys everything above. Holds the secrets and the inventory | A control machine, never installed on a host | Never deployed |
Full reasoning in ADR-0029. Surfaces and their boundaries: ADR-0011.