Notes from the box.
How we think about ownership, reliability and running production on servers you actually control, plus what's shipping in Sproobo.
Why we rebuilt Sproobo on Docker-everything
v2's recurring outages were all the same failure class: native packages coupled to a host's mutable state. v6 deletes that class by running everything (apps and the databases behind them) as pinned containers.
An agent that only dials out
Most fleet-management tools need an inbound port into your server. Sproobo's agent never listens for anything. It dials out over WSS/443 and HTTPS, carries a rotating mTLS identity, and is structurally barred from ever locking you out.
Deploys that explain their own failures
Blue-green deploys mean a bad release never takes the old one offline. Now, when a deploy does fail, the failing container's own log tail is captured automatically and attached to the deployment record, no SSH required to find out why.
Your infrastructure, one conversation away
claude.ai and ChatGPT connectors, the CLI with browser login, and an Agent Skill for coding tools all reach your infrastructure through the same audited, role-gated API a human uses: reads free, writes plan-first, one destructive operation that never auto-applies.
TLS for every topology
A public box, a VPN-only server, a fleet of subdomains, and an app behind someone else's load balancer each need a different certificate story. Sproobo ships all four as a per-app setting: HTTP-01, delegated DNS-01, wildcard, and external termination.