Whether you manage one domain or 100,000 domains, DNSimple delivers simple, secure domain management solutions. Learn more -> https://dnsimple.com
This is the 6th launch from DNSimple. View more
DNSimple CLI
Launched this week
Manage your domains and DNS without leaving the terminal, built for developers who live in their terminals and CI pipelines. What you can do: create, update, and delete DNS records; register domains and manage renewals; issue and manage SSL/TLS certificates; run it in CI with API token auth and structured output. Built in Go, it uses the same foundation as our official client libraries and Terraform provider.
Read our announcement: https://blog.dnsimple.com/2026/05/announcing-the-dnsimple-cli/
Free Options
Launch Team
Since this shares a foundation with your Terraform provider — where's the line you'd draw between reaching for the CLI versus just declaring records in Terraform? Anything that lives in version control I'd default to the provider, so I'm trying to picture the CLI's home turf: one-off changes, incident response, scripting renewals?
Secondly, The "structured output for CI" line is the part I'd lean on hardest. Is that stable, documented JSON I can pin a script to, or is it formatted-for-humans output that'll shift between releases and quietly break my pipeline? CLI tools live or die on whether their machine output is a contract.
@sounak_bhattacharya Hi Sounak, thanks for your feedback!
You're absolutely right that the CLI and the Terraform provider overlap in some areas. Both can be used for automation workflows, and in practice they can be used either independently or together, depending on the operational model you prefer.
I see the Terraform provider as the better fit for teams or individuals who want infrastructure to live as declarative configuration with all the structure and guarantees that come with IaC. That usually means version control, review workflows, reproducibility, auditing, and a deliberate operational pace. Of course, that also comes with additional overhead: maintaining repositories, managing state storage (Terraform Cloud, Spacelift, etc.), and accepting that changes are intentionally slower because the goal is traceability and consistency.
The CLI sits in a different space. It's more immediate and operational in nature: quick changes, bulk operations, debugging, scripting, incident response, or exploratory workflows where the UI becomes limiting. In many cases it's simply the fastest way to iterate, especially when you’re trying to understand or troubleshoot something in real time.
Personally, I tend to manage production domains through Terraform, but I've increasingly appreciated the CLI alongside LLM-assisted workflows for faster experimentation and iteration, especially in less familiar areas. I also intentionally keep certain domains outside Terraform entirely, particularly ephemeral or CI/CD-related environments where maintaining IaC state would add more friction than value. In those cases, the CLI becomes a lightweight programmable interface that’s much faster than building a custom integration against the API SDK.
On the JSON output question: I completely agree that machine-readable output has to be treated as a contract, otherwise it becomes dangerous to depend on in automation.
Right now, we haven't defined a CLI-specific JSON schema layer with separate compatibility guarantees. The CLI intentionally relies on the Go API SDK models that we also maintain and version carefully. Those models closely follow the API’s JSON design, and we’ve been disciplined about compatibility through semantic versioning.
So while I wouldn't call the output immutable, I do think it's reasonably safe to pin automation against. Any breaking structural changes would be treated seriously and planned through major version transitions rather than introduced casually in minor releases.
I hope that helps and answers your questions.