Honest about scope. Shipped runs in the operator console right now. In progress is being built this week. Planned is on the list, not yet started.
// agent install → console-managed boxes
One install line on the box, signed heartbeat back. The agent is the only thing that touches root.
Live posture across services, packages, SSH access, firewall, scheduled tasks, and audit. One pane per box.
systemd unit visibility — start, stop, restart, tail logs. Everything via the agent's wrapper scripts.
Inventory of what's installed, what's pending update, what's pinned. apt + dpkg today; rpm next.
Edit authorized_keys with a typed picker. Pick from your registered org keys or paste a one-off.
age-encrypted, S3-compatible. Public key on Ordic, private key on a device you control. We never see plaintext.
Pick a snapshot, fingerprint-match the recipient, restore to staging or in-place. Decryption happens on your server.
Every action by every actor, exportable, deep-linkable. Sensitive params redacted to fingerprints, never raw key material.
A site is a git repo + a build command + a destination. Hugo and pre-rendered WordPress both supported.
Atomic deploys with a previous-release symlink. Rollback in one click. Publish history in audit.
Detect-and-import existing zones, propose A/CNAME/TXT changes through the same plan-approve-execute loop.
Signed agent binaries, staged rollout, opt-out per server. Not auto-on by default — operators choose the cadence.
unattended-upgrades wired into the audit log. Plan-approve-execute, just like every other op.
Agencies running on behalf of multiple clients. Per-org audit isolation, per-org keys, per-org billing.
// editor → git → static publish
Pages, posts, drafts, scheduled. Tree view that mirrors the on-disk content directory exactly.
Markdown + frontmatter, with a forms-first inspector for the structured fields. No chatbot, no live shell.
Upload, browse, reuse. Stored next to content in the repo so backups capture both at once.
Build runs on your server through the agent. Output is static. The destination is a directory you choose.
Theme variables, build command, publish target, env vars — all forms, all written into the repo's config file.
Multi-stage wizard: connect source → render to static → review diffs → cut over. WXR + database paths both wired up.
Map a WordPress theme to a Hugo theme, with a manual review pass for the layouts that don't translate cleanly.
Same build, multiple targets — your server plus a CDN, or staging plus production. One git tag, two destinations.
Show, per site, exactly which plugin behaviours have a Hugo equivalent and which need a manual decision.
An LLM proposes a plan. You see the plan. You approve. The agent executes. There is no "tell me what you want" prompt at the centre of the product.