I buy most of my domains on Spaceship, and my agents deploy most of my sites. Those two facts collided every time a deploy reached the DNS step: everything else in the pipeline was scriptable, and then the last mile was me in a browser tab, clicking through a dashboard to point an A record somewhere. Spaceship has a proper API; what it didn’t have was a CLI an agent could use. So one afternoon in March I built one, and DNS stopped being the manual step.
The surface is exactly what a deploy workflow needs and nothing else: spaceship auth login, domains list and domains info, then dns list, dns set, dns delete, and a bulk dns put that replaces a domain’s records from a JSON file. Set an apex A record with one command, verify with the next. Output comes as tables for humans or JSON for everything else that will actually be running this.
Scoped down on purpose
The design decision I’d defend hardest is what the CLI can’t do. The Spaceship API covers domain registration, deletion, transfers, nameserver changes, and SellerHub, and this tool wraps none of it. It touches exactly five endpoints: list domains, get domain info, and read, put, and delete DNS records. That’s not laziness; it’s the permission boundary drawn in the tool itself. The whole point is that a coding agent runs this unattended during deploys, and an agent that can flip a CNAME is useful while an agent that can transfer a domain out of your account is a liability. The API key scopes tell the same story: domains:read, dnsrecords:read, dnsrecords:write, nothing more. Even a confused invocation can’t escalate past record edits. It’s the same instinct as the permission model in Zodex: decide the blast radius before the agent gets the keys, not after.
Credentials never sit in a dotfile: on macOS they go into the Keychain (with env-var overrides for CI), so a repo full of agent scratch files can’t leak an API secret. And the repo ships an AGENTS.md operator guide, because the expected maintainer of this codebase is the same kind of agent that uses it.
Go binary, npm delivery
Like agentbox, it’s written in Go as a small self-contained binary with no runtime to install. I publish it as spaceship-domains-cli on npm because npm i -g is the install command every machine I touch already understands. The npm package is just a shim plus a postinstall script that downloads the right prebuilt binary per platform (with a build-from-source fallback), and releases are tag-driven through CI. A day-one project taken all the way to a versioned, published tool, because the difference between “script on my laptop” and “thing my agents can rely on anywhere” is exactly that packaging work.