Today we’re releasing SpatiumDDI 1.0.0-rc.1, the first release candidate of our open-source platform for DNS, DHCP and IP address management. The release notes are on GitHub and cover what’s in it. This post is about how we got here.

Seven months ago, SpatiumDDI was a first commit. Years before that, it was an item on a wish list.

The wish list

My co-founder, Zachary McGibbon, and I have spent our careers in higher-education IT, more than 45 years between us. We’ve run networks, DNS, DHCP and address management, the cloud foundation underneath them, and the containers and Kubernetes clusters on top. Both of us ran the commercial DDI products in our day jobs.

Those products are good. They’re mature, they’re well supported, and the people who build them know this field deeply. What we kept running into wasn’t the software. It was two things around it.

The first was cost. Commercial DDI suites cost five to six figures a year, and the price tends to climb at every renewal, often faster than inflation. For a large, well-funded enterprise, that’s a line item. For a university, a hospital, a school board, a municipality or a public agency working to a fixed budget, it can be a choice between DDI and something else the organization needs.

The second was continuity. DNS and DHCP are the foundation everything else on a network stands on. When the platform that runs them is licensed, its future is partly someone else’s decision: renewal terms, roadmaps, acquisitions, end-of-life notices. Public institutions plan in decades. Their core infrastructure shouldn’t hinge on a contract they don’t control.

The alternative most teams fall back on is one we’d both lived with: Windows DHCP, BIND and a spreadsheet. Three systems that never quite agree. A lease with no DNS record, a record for a host that left months ago, every change made three times or forgotten once.

Open source has solved databases, operating systems, orchestration and monitoring. It never quite solved DDI. Underneath the commercial suites run BIND 9 and Kea, free engines anyone can run. What’s sold is the layer around them: the console, the automation, the single source of truth. The open-source tools that do exist are good at what they set out to do. NetBox documents a network beautifully, and by design it doesn’t run DNS or DHCP. phpIPAM manages addresses. Home-grown scripts work until the person who wrote them moves on.

Zac wanted something that didn’t exist: one open-source control plane that actually runs DNS, DHCP and IPAM from a single record, and that can manage an organization’s existing Windows DNS and DHCP without asking it to rip out Active Directory. For years, building that was out of reach for two people with day jobs.

What changed

AI coding tools got good enough.

Zac made the first commit on 12 April 2026. The instruction file for Claude Code was part of that very first commit, and the first commit co-authored with Claude landed the next day: an IPAM tree view, user management and the dashboard. On 16 April, four days after the first line of code, we published the first public release under the Apache 2.0 licence.

Then it moved fast. Thirty-four releases in the first seven weeks. Fifty-five date-stamped releases by the start of October. By 8 November, the repository’s main branch held 2,043 commits, 1,805 of them (88 percent) co-authored with Claude, along with 1,585 merged pull requests and 2,110 issues.

Zac wrote almost all of it. Writing with AI doesn’t mean the AI decided what to build. It means one person with a clear picture of the product, after years of wanting it, could finally build at the speed of that picture. What he’d wanted for years took weeks once the tools caught up.

There’s a picture from history I keep coming back to. In the late 1500s, Dutch shipyards began building the fluyt, a merchant ship that cost about half as much as its rivals. It wasn’t a lesser ship. It carried more cargo, with a smaller crew. It was cheaper because the yard was different: standard designs, new tools, and wind-powered sawmills that changed what a small yard could produce.

SpatiumDDI is the ship. A two-person company that builds with AI is the yard.

Trust, the harder problem

Speed was never going to be enough. If you’re going to run your network on software written mostly with AI, by a company of two people, you deserve to ask who checked it.

For most of the history of enterprise software, headcount stood in for trust. A big vendor had a big QA team, and people did the testing. We couldn’t have that, so we built something we think is better: evidence you can check.

On 2 July I started ddi-pg, our proving ground. It moved onto our own hardware that month. Today it installs every build of SpatiumDDI from its ISO, walks it four ways, and breaks it on purpose: leaders killed, members cut off, nodes replaced, backups restored. Plain code decides whether a check passed, never a model. A separate checker re-reads every claim the AI makes about the code. The lab proposes fixes but never merges its own. A person signs off on every build before its result is published. Seven scheduled AI sessions keep it running around the clock, nights and weekends included.

I go through the lab in detail in Built with AI, proven by evidence. The short version fits in one week’s numbers: from 2 to 8 November, 215 bugs were filed against SpatiumDDI, and all 26 of the serious ones were closed that same week.

Becoming a company

In August we incorporated Spatium North Inc. in Montréal. The software stays free. The company exists so that the organizations running SpatiumDDI have someone to call. We sell support, deployment and migration, and training and certification. There’s no paid tier, no enterprise edition and no feature held back for paying customers. Everyone runs the same software.

In September we built the SpatiumDDI Academy: 20 modules, about ten hours of material, narrated videos and labs that grade themselves. Recording it turned out to be a test in its own right. Walking slowly through every feature, on camera, turned up real bugs.

Freezing the features

On 26 September we drew a line: no more features, only stability. From that day, every hour went into making what existed hold up.

You can see it in the history. From April to July, while Zac built out the platform, about a quarter of the commits were fixes. Once the freeze began, that rose to 91 percent. October was the busiest month yet, with 861 commits, almost all of them fixes for problems the lab had found.

On 2 October we published the 55th and last date-stamped release. On 21 October, 1.0.0-beta.1 moved SpatiumDDI to semantic version numbers, and five betas shipped in seventeen days. Today’s release candidate is the build we expect to become 1.0.0, unless its soak week tells us otherwise.

Enterprise grade, and open

We built SpatiumDDI for the kind of organizations we come from: universities, colleges, hospitals, public agencies, and the managed service providers who support them. Networks with many sites, thousands of devices and little tolerance for surprises. That shaped the product from the first week.

The 1.0 core is what an enterprise network needs from DDI:

DNS on BIND 9 or PowerDNS, with DNSSEC.
DHCP on Kea, including high availability.
IP address management with dynamic DNS, so leases and records agree.
An appliance you install from an ISO, with A/B upgrades, rollback, backup and restore.
A three-node cluster, so losing a server is an event, not an outage.
A REST API and a web console for all of it, with role-based access and single sign-on through LDAP, SAML or OIDC.

Around that core: agentless management of existing Windows DNS and DHCP, cloud DNS providers, compliance checks with PDF reports, network discovery, integrations with Kubernetes, Docker and Proxmox, and an AI operator copilot whose changes wait for a person to approve them.

It’s enterprise ready in the ways an enterprise checks. And it’s open, because that’s the only way we know to answer the two problems we started with.

On cost: the software is free under Apache 2.0, forever, including every lab, test and disaster-recovery copy you care to run. An agency on a tight budget doesn’t have to choose between proper DDI and something else it needs.

On continuity: you own your deployment. The code is public, the engines underneath are the standard ones, and your data stays in your own infrastructure. If Spatium North disappeared tomorrow, your DNS would keep answering and the code would still be there for anyone to pick up. No licence agreement can promise that, and we think public institutions deserve it.

Several universities and colleges found the project and reached out on their own. That told us the gap we’d been living with wasn’t only ours.

Where it stands today

I want to be plain about where we are, because you’ll make better decisions if we are.

A release candidate is not 1.0.0. rc.1 now starts a soak week in our lab, and 1.0.0 follows once it comes through that week cleanly. We haven’t set a public date, and we won’t until the evidence is in.

SpatiumDDI isn’t running anyone’s production network yet. Reference deployments are our next milestone, and we’re looking for the first organizations to run one with us.

If that’s you, start the way we’d want to start ourselves. Install it beside what you run today. Import your existing configuration, read-only. Run it in parallel with nothing sent to your servers, compare its answers with your current system’s, and move one zone at a time when the evidence says you should.

Thank you

To Zac, who carried this idea for years and then built it in months. To the outside contributors who sent code before there was any reason to, and to everyone who filed an issue. To the universities and colleges who wrote to us first. And to our families, for a lot of nights and weekends.

SpatiumDDI is on GitHub. You can read about the product at spatiumnorth.com/spatiumddi, or get in touch with either of us.