Phoenix DevOps Persona · ShadowOps edge extension · AGPL v3

The Phoenix DevOps persona,
packaged for sovereign infrastructure.

FreeOSBot is not a separate AI. It is the DevOps persona of Phoenix Daemon, pre-shipped with the right Postgres role, the right MCP allowlist, the right escalation policy, and the right safety envelope for regulated on-prem operations. ShadowOps is its edge extension: per-node Watchmen agents that pre-classify the log firehose so a single DevOps persona can supervise hundreds of hosts without saturating.

Engine
Phoenix Daemon

Persistent multi-persona AI operations platform. One engine, five-layer brain, eleven-stage cognitive pipeline, four-tier action gate, hard persona severance.

Subset
FreeOSBot — DevOps persona, productionised

Phoenix's DevOps persona shipped as a turnkey package: pre-built persona YAML, Postgres role, MCP allowlist (k8s · Vault · ArgoCD · Wazuh · Helm · Trivy · Loki · Prometheus · Grafana · Dagster · Git · Shell), escalation contract, and safety envelope for healthcare-grade infrastructure.

Extension
ShadowOps — edge Watchmen

Per-node agent (DaemonSet on k8s, systemd unit on bare-metal) that tails journalctl + docker events + kubelet locally. Pre-classifies log lines through a deterministic regex tier and an optional local Ollama tier. Sends only structured envelopes to FreeOSBot — never raw log text.

One engine. One persona. One edge fleet.

FreeOSBot does not reinvent observability or replace your AI assistant. It plugs into Phoenix's existing severance model and uses ShadowOps to scale fan-in past the point where a centralised log tail breaks.

Phoenix Daemon

The engine.

Phoenix is the long-running daemon: brain, pipeline, gate, severance. It runs every persona — not just DevOps. Memory, audit, drift watchdog and constitutional core are all upstream.

  • Five-layer brain (L1 constitution → L5 RAG + watchdog)
  • Per-persona Postgres role + row-level security
  • Four-tier action gate · plan mode · drift auto-pause
  • 167 FastAPI endpoints · per-persona operator console
FreeOSBot — Subset

The DevOps persona, packaged.

Same engine, same brain, same safety. Difference is that FreeOSBot is exactly the DevOps persona YAML — pre-shipped with the operator contract, escalation policy and toolset that regulated on-prem clusters actually need.

  • 11 in-tree MCP servers · 279 DevOps tools
  • Pre-built escalation policy: telegram · email · PagerDuty
  • Drift detector → reconcile PR · GitHub PR auto-review
  • Daily security scan ladder · Wazuh stream · feed subscriber
ShadowOps — Extension

Eyes on every host.

An edge fleet that turns the log firehose into a manageable structured stream. Watchmen pre-filter, optionally pre-classify with a small local model, and emit envelopes — never raw text — to FreeOSBot.

  • DaemonSet (k8s) · systemd unit (bare-metal) · Nomad jobspec
  • Tier 0 deterministic regex · Tier 1 local Ollama (optional, feature-flagged)
  • Node-scoped auto-remediation · blast radius enforced mechanically
  • v1 envelope schema · sticky-routed by correlation_id

subset What "subset of the DevOps persona" actually means

FreeOSBot ships personas/devops.yaml with a healthcare-friendly default contract: escalation.assigned_person.name required before any Tier-1+ autonomous execution; auto_discover_sources seeded for k3s + Helm + ArgoCD + dpkg + npm + pip; security_feeds.yaml seeded with NVD, GitHub Advisory, kernel security list, OSS licence press; and a default-deny outbound allowlist that opens only the channels you configure. The tool catalogue is the same 279 tools the engine ships, gated to this one persona by the YAML overlay. Add a persona — by editing YAML, not by building a separate product.

Edge classifies. Centre acts.

A two-tier architecture. Watchmen at the edge handle the >95% of log lines that are deterministic. Only structured envelopes — never raw logs — fan in to FreeOSBot. The DevOps persona then applies Phoenix's full safety model to anything that needs a decision.

Tier 0 · Deterministic

Regex match against seeds/log_patterns.yaml. CrashLoopBackOff → restart (node-scoped). OOMKilled → queue a GitOps PR template. Disk pressure → prune + escalate. Noise → drop.

drop / self-remediate ~95%
Stays at the node

Sub-millisecond. No LLM. No network. Audited locally; aggregate digest emitted hourly to FreeOSBot for visibility.

Tier 1 · Local Ollama (optional)

Per-node 4B-class model — single-token {remediate|escalate|ignore} verdict + confidence. Only fires when Tier 0 confidence is below threshold. Routed locally via bifrost_llm; bypasses Bifrost circuit breaker; no token accounting.

classified ~4%
Stays at the node

Feature-flagged · default off in Phase 1. Killed and disabled if node memory pressure spikes — fail-safe to Tier 0 only.

Tier 2 · Envelope to centre

Stable schema. correlation_id, cluster_id, severity, category, auto_remediation, evidence (≤ 4 KB log excerpt). Never raw log text.

sticky-route by correlation_id ~1%
FreeOSBot · DevOps persona

Phoenix admission ingress accepts the envelope. Pipeline runs RECON, memory probe, action gate, plan mode. Operator escalation routed per escalation.policy: page · escalate-1h · daily digest · hourly digest.

500 hosts. One DevOps persona. Survives.

Without ShadowOps, the log firehose breaks any centralised AI assistant — economically and architecturally. With ShadowOps, the same DevOps persona stays under load and inside the Phoenix safety model.

~100k
Log lines / min · 500 hosts
≤ 100
Actionable events / min · centre
≤ 60 s
p95 detect-to-act · Tier 0
node
Watchman blast radius · enforced

Watchmen drop the noise locally and self-remediate the auto-fixable patterns — pod restarts, journal pruning, log rotation — within a contract that mechanically refuses any action outside the node. Only the ~1% that needs a real decision becomes an envelope. FreeOSBot then applies the full Phoenix pipeline: RECON pulls last-deploy diff, memory probe cites prior incidents, the action gate scales approval to blast radius, plan mode auto-triggers at three or more mutating steps. Operator escalation stays inside the existing telegram / email / PagerDuty contract.

Inherited from Phoenix. Specific to FreeOSBot & ShadowOps.

Two columns, no overlap. The left is what every Phoenix persona ships with — and FreeOSBot inherits unchanged. The right is what FreeOSBot and ShadowOps add on top.

From Phoenix Daemon inherited

  • Five-layer brain. L1 constitution · L2 persona · L3 working memory · L4 common sense · L5 RAG + drift watchdog.
  • Code-enforced safety. Four-tier action gate · plan mode at ≥ 3 mutating steps · L1 BLOCK overrides every persona and every operator approval.
  • Persona severance. Per-persona Postgres role + RLS · per-persona MCP allowlist · per-persona channels · isolated memory namespace.
  • Memory that compounds. Decision capture with citation IDs · 6 h distillation · nightly consolidator · postmortem assembler.
  • Per-persona daily LLM budget. Soft warn · or hard cap (forced gear downshift) under PHOENIX_BUDGET_HARD=on.
  • Cross-replica state. Redis-backed conversation buffer · sticky routing · FOR UPDATE SKIP LOCKED single-claim event dispatch.
  • GitOps deployment. Two-image hardening · SHA-pinned base · Trivy CVE gate · Watchtower auto-update.

FreeOSBot & ShadowOps added

  • 11 in-tree MCP servers · 279 DevOps tools. Kubernetes · Vault · Trivy · Prometheus / Loki / Alertmanager / Grafana · Nomad · PostgreSQL · Dagster · ArgoCD / Helm / Flux · Git · Shell.
  • CLI is ground truth. shell:* calls intercepted before MCP routing — no JSON-RPC overhead, no 30 s MCP hangs.
  • Drift detection → reconcile PR. Compares persona YAMLs vs git HEAD, K8s deployments vs PHOENIX_DRIFT_K8S_TARGETS; opens draft PRs with a reconcile checklist.
  • GitHub PR auto-review. Triggered on pull_request open / sync · deterministic diff + memory probe + scout + comment.
  • Production guardian contract. Autonomy disabled when escalation.assigned_person is blank — fail-closed.
  • ShadowOps Watchmen. DaemonSet · systemd · Nomad packaging. Tails journalctl + docker events + kubelet. Tier 0 regex + optional Tier 1 local Ollama. Local drop-oldest ring buffer survives FreeOSBot outages.
  • Mechanically-bounded blast radius for Watchmen. Restart pod / prune disk / rotate log / reset systemd unit on the node — and nothing else. ArgoCD, Vault, cluster-scope resources are denied at the executor.

04:17 AM. payment-api goes into CrashLoopBackOff.

A node-local Watchman tails journalctl on every host. The on-call SRE is asleep. Here is exactly what the next 90 seconds look like, end to end. Every line is something FreeOSBot + ShadowOps actually do today, not roadmap.

04:17:23

Watchman regex hit · Tier 0 deterministic.

Per-node ShadowOps Watchman classifies the log line against seeds/log_patterns.yaml. Severity HIGH, category crash, blast-radius node-scope. Watchman attempts the node-scoped remediation it is allowed to take.

[journalctl] Back-off restarting failed container payment-api-7f9 [watchmen] match=crash sev=HIGH conf=0.91 → restart_container
04:17:35

Restart fails · escalation envelope built.

Container crashes again 12 s after restart. Watchman blast-radius is bounded to the node — it cannot roll back, cannot touch ArgoCD, cannot read Vault. It builds a v1 envelope and POSTs it to FreeOSBot's admission ingress.

envelope.correlation_id = 01HK… envelope.category = crash envelope.auto_remediation = { attempted: true, outcome: failed } envelope.evidence.log_excerpt = <last 20 lines>
04:17:36

Sticky router pins to replica B by correlation_id.

Phoenix admission control accepts the envelope. Sticky router hashes correlation_id → replica_id. All follow-up events for this incident will land on the same replica — no cross-replica chatter, no double-claim.

04:17:38

RECON engine runs read-only investigation.

Investigative intent triggers RECON. Up to 12 iterations / 90 s, read-only enforced at two layers (text filter + subprocess permission drop). RECON pulls last 500 log lines, the last deploy diff, last 3 incidents involving payment-api, current cert chain, downstream dependencies. Memory probe surfaces [INC-2026-04-22-A4F1] — same crash signature, fixed by rolling back to :v3.4.1.

04:17:42

PASS1 produces a Tier-2 action plan.

Diagnosis: image :v3.4.2 shipped 41 minutes ago changes the JWT validation library; the same memory entry from April flags this as the recurring failure mode. Recommended action: rollback to :v3.4.1 via kubectl set image. Cumulative tier ≥ 4 → plan mode triggers and persists to Postgres.

04:17:43

Operator preference applied · approval token requested.

Memory probe also surfaces a standing common-sense entry: "always require operator approval for production rollbacks, even when previously successful." FreeOSBot sends a Telegram with diagnosis, evidence bundle, plan, and a request for a single-use token via the separate approval channel.

→ telegram(@on-call): 🚨 prod-eu-1 / payment-api crash plan: rollback :v3.4.2 → :v3.4.1 cite: INC-2026-04-22-A4F1 (same fix worked, 18d ago) reply with: APPROVE TOKEN-01HK… or DECLINE
04:18:09

Operator approves with single-use token.

Operator wakes briefly, taps approve. Token verified, marked used, cannot be replayed. FreeOSBot records who approved, when, and against which correlation id — to the audit log, not just to a chat scrollback.

04:18:10

Rollback executes via CLI · 60 s undo window opens.

Tier 2: semi-reversible. FreeOSBot issues kubectl set image deploy/payment-api …:v3.4.1. Snapshot of the previous deploy is preserved. Operator can /cancel <corr_id> from any replica during the next 60 seconds; Redis pub/sub reaches replica B and ACK-confirms.

04:19:30

Health probe green · audit row written.

New pod is Ready. No undo invoked. Audit row written: actor, action, tier, evidence hash, correlation id, approver token reference. Permanent, append-only. The nightly consolidator marks the resolution as ADR-eligible — promoted to accepted after 7 days unless revoked.

09:00:00

Morning briefing arrives.

Structured incident report on the operator's desk. Timeline, root cause cited from prior memory, what changed in the deploy, what was rolled back, recommended long-term fix (pin the JWT library version in the base image), who needs to know (the platform team committed :v3.4.2). All cross-referenced to the relevant DEC and PLAN ids.

+ 60 days

A new SRE asks: "have we ever rolled back payment-api?"

FreeOSBot replies in 30 seconds. Cites INC-2026-04-22-A4F1 and INC-2026-05-10-B7E3. Quotes the operator's standing rollback policy. Surfaces the long-term fix that was filed as an ADR. The new SRE is productive on day one against an institution that did not have to reconvene a war room. This is the compounding return chatbots structurally cannot offer.

Flat rate. No lock-in. Sovereign.

Start with a free 30-day pilot — we deploy a single Watchman into your cluster, read-only, no remediation. Convert when you're convinced. The platform is AGPL v3 — you keep it whether we keep working together or not, and hyperscalers cannot fork it into a closed managed service.

Pilot
Free
30-day evaluation. Read-only Watchman. Full incident log. No commitment.
  • ✓ One Watchman deployed into your cluster
  • ✓ Tier 0 deterministic classification
  • ✓ Full envelope log + cost displacement estimate
  • ✗ No SLA during pilot
  • ✗ Read-only · no remediation during pilot
Get in touch →
Enterprise
Custom
Multi-cluster federation · white-label for hosting partners.
  • ✓ Everything in Managed cluster
  • ✓ Multi-cluster federation
  • ✓ White-label for hosting partners
  • ✓ Custom Watchmen domains and thresholds
  • ✓ Custom escalation contracts
  • ✓ On-site deployment and handover
Start conversation →
🔑 Sovereignty in plain language. AGPL v3, top to bottom. All credentials, all documentation, all git history are yours from day one. You can run FreeOSBot without us — and if you stop paying, we hand over cleanly. The copyleft is deliberate: no hyperscaler can quietly fork this into a closed managed service and strip-mine the work. There is no "vendor mode" the platform falls back into.

Let's talk sovereignty.

Whether you're scoping a pilot, evaluating a multi-cluster federation, or just want to understand how a DevOps persona under Phoenix actually works — we're happy to have that conversation.