Skip to content

v1.5.3 — servers you own

Latest

Choose a tag to compare

@wu-changxing wu-changxing released this 31 Jul 01:58
1c5ad8e

Servers you own — and a deploy that stops erasing the agent on it.

Servers you own

co server new prod          # have one created, $30/month charged yearly
co server add prod --ssh you@1.2.3.4   # or register one you already have
co deploy --to prod

The SSH key is derived from the recovery phrase you already have, so there is still one thing to write down.

  • A redeploy no longer reissues the agent's address. It used to, which changed the agent's email and voided every trust relationship other agents had granted it — silently, while the deploy reported success.
  • .co/logs/ and .co/evals/ survive, so a dashboard can show history that is real.
  • The deploying key is seeded as admin. A deployed agent previously had no reachable admin at all: admin actions were gated on a key that only ever existed on the server, so the one account that could grant admin was the one nobody could sign as.
  • Served over https on its own hostname, with AGENT_PUBLIC_DOMAIN set so the agent announces a URL that actually answers rather than a closed port.
  • co server ls reconciles against billing — a server you are paying for but never registered locally is now visible instead of silent.
  • co server destroy refunds the unused term. co server forget deliberately does not touch the machine; conflating the two would mean either believing you stopped paying when you did not, or deleting production while tidying config.

Skills stop leaking

The agent's full picture now travels over the authenticated socket instead of the open /info, which had been publishing the operator's personal skills — 117 of them on the machine where this was found, including a real name and an internal SaaS stack — to anyone who could reach the agent.

co skills list and co doctor now say which tier each skill came from, and both deploy paths name the ones that will not travel. A user-tier skill is usually a symlink into another repo, so it can look installed, work for months, and simply not exist on the server.

Install

pip install --upgrade connectonion

Why 1.5.3 and not 1.6.0

X.Y.0 is the version people sit on. This work is still being stabilised, so it ships as a patch; 1.6.0 is cut once co server newco deploy --to → https → dashboard has been run end to end against a real machine. VERSIONING.md now says so, rather than leaving it to be inferred from the roll-over rule.

Full changelog: v1.5.2...v1.5.3