HeroCtl vs Nomad: the alternative for those caught by the license change

The Nomad story is, in retrospect, a warning. For many people who chose Nomad between 2020 and 2022 — for the argument of "simpler than Kubernetes, real open-source, open governance" — the two announcements that came after changed the base of the contract. In August 2023 the license changed. In February 2025 the company was sold. The technical product is still good. The contract around it is no longer the same that was on the table when you signed.

This post is about that difference. It isn't a critique of Nomad's technical core — we'll get to that. It's about the structural problem of adopting a tool whose contractual base can change between one reorganization and the next, and what's left for whoever decides today, in April 2026.

Where Nomad got it right (and keeps getting it right)

Before any criticism, the credit owed. Nomad is technically good. Replicated control plane works in production. The command-line interface is consistent — nomad job run, nomad job stop, nomad alloc logs behave predictably across a thousand different clusters. Multi-region operation was actually thought through, with federation between datacenters and routing between them. Supports non-Docker workloads (native binaries, lightweight virtual machines, custom drivers) — a flexibility the larger competitor never prioritized.

Whoever has operated Nomad in serious production rarely complains about the core. The incidents that show up in public post-mortems are almost always at the edge — integration with the configuration manager, integration with the external router, integration with the secret vault — not in the orchestrator proper.

That technical performance is important because it sets the tone for the rest of the post: the Nomad problem isn't the code. The code is good. The problem is what happened around the code.

The timeline, in absolute dates

Worth recapping without dramatizing.

August 2023. HashiCorp, then a publicly traded company, announces a license change in all main products — including Terraform, Vault, Consul, and Nomad. The license migrates from Mozilla Public License 2.0 (an open license, with copies of the OSI definition) to Business Source License 1.1 — a "source available" license. The practical difference is the clause that restricts use in commercial products that compete with the company's paid offering. You can still read the code. Can run internally. Can no longer embed in a commercial product of yours, and can no longer offer as a managed service to third parties, without separate licensing.

The community reaction was immediate. In a few weeks, a Terraform fork — OpenTofu — came off the page, with Linux Foundation governance. Months later, Vault gained OpenBao with similar governance. Nomad and Consul were left without an equivalent strong community fork. There were discussions, halted contributions, some maintainer departures — but nothing the size of what happened with Terraform.

February 2025. IBM announces the acquisition of HashiCorp for approximately US$6.4 billion. The operation closed still in 2025. HashiCorp becomes part of IBM's portfolio — aligned with IBM's existing offerings around internal platforms, configuration management, and hybrid cloud.

Today (April 2026). The BSL license remains in force. Official support is exclusively through the IBM channel. The release cadence continues, but the roadmap responds to IBM's internal OKRs now — no longer to an independent product plan. There's no community fork strong equivalent to OpenTofu for Nomad. Whoever is in production, is in production; whoever is adopting today, is adopting a tool whose owner changed twice in 30 months.

What this means in practice

For those who already had Nomad in production before August 2023, the situation is manageable. The version immediately prior to the license change is frozen at MPL 2.0 — you can keep with it, take selected patches, wait for a fork to mature. It's not comfortable, but it's workable.

For those deciding in 2026, it's a different decision. Three asterisks matter:

The next critical feature might land only in the paid version. The license doesn't prevent it, and the company no longer has an independent product plan that keeps strategic features on the open path. It's a choice now, not a principle.

The roadmap responds to IBM OKRs. This may be good — IBM has engineering muscle, will invest — or bad, if IBM's priorities (compliance, governmental, integration with legacy products) are different from yours. You don't control which of the two happens.

Commercial prices may be revisited in a next reorganization. Large acquisitions usually have a "value discovery" period where price tables are reviewed. There's no rule preventing a new round of contractual changes in 12 or 24 months. You have no protection against this.

The technical community registers these signals. The rate of external contributions to Nomad fell after August 2023. Companies that previously displayed public use cases stopped publishing. Conference talks cooled. The ecosystem still exists — but it lost the product-of-community traction it had between 2018 and 2022.

The right lesson isn't "open source or nothing"

Here comes the part that matters for any infrastructure tool — including HeroCtl.

The Nomad problem wasn't going paid. Companies need to be sustainable; charging for software is legitimate; serious commercial software is better for everyone than open software that goes into skeletal maintenance because nobody pays.

The Nomad problem was changing the contract with whoever already bet. Whoever chose Nomad in 2021 based on the open license had a reasonable expectation — that the base would be stable. It wasn't. In three years, the base became something else, and the cost of leaving was — exactly — the amount of work that had been invested in the original choice.

This reveals an asymmetry. Open software that can become commercial at any moment is riskier than commercial software published from day one, with terms frozen for existing contracts. The first looks safer because "it's open". It's a wrong perception when control of the project is concentrated in a single company, subject to acquisition, IPO, CEO change, or investor pressure. The contract may change; the security perception was illusion.

Honest commercial software — published prices, frozen terms, no retroactive change, continuity mechanism in case the company shuts down — is structurally more predictable.

That's the HeroCtl pivot.

How HeroCtl solves this structurally

HeroCtl was born commercial. There was no "open source while we grow, commercial later" phase. The terms have been on the table since day one, published, with explicit anti-rug-pull mechanisms.

Permanently free Community plan. No server limit. No job limit. No artificial feature gate. Runs the entire stack — real high availability, integrated router, automatic certificates, encryption between services, metrics, and logs. Individuals and small teams never need to leave Community.

No phone-home, no kill-switch. Once installed, the cluster works without ever talking to the company's server. There's no periodic activation that expires. There's no flag that can be revoked from outside. If office internet goes down forever, the cluster keeps running.

Source-code escrow on Enterprise. Enterprise contracts include an escrow clause — the code is deposited with a third-party custodian. If the company shuts down operations, the code goes to paying customers via the custodian, with license for internal continuity. It isn't "trust us"; it's a legal mechanism that survives the company's disappearance.

Published prices. Business and Enterprise have visible prices on the plans page — without mandatory "talk to sales" as a qualification tactic. No unilateral revision clause; the agreed price stays frozen for existing contracts.

The difference with what happened in August 2023 and February 2025 isn't a promise. It's a structure.

Honest technical comparison

Setting license aside, what's the technical difference? At a high level, surprisingly less than you'd imagine.

Similar primitives. Nomad organizes work in job → group → task. HeroCtl organizes in job → replica → task. The concepts map almost one-to-one. A job describes the service, the grouping determines replica and location, the task is what actually runs. Both support long-running jobs (services), batch jobs, and periodic jobs.

Replicated control plane in both. Both use consensus between servers for state durability. Both tolerate the loss of a minority of servers without unavailability. Both elect a leader automatically. In HeroCtl, the public chaos test shows election in around seven seconds after a kill -9 on the leader.

Key difference 1: batteries included vs assemble the mesh. Here the philosophies diverge. Nomad was designed to be composed with other components from the same ecosystem — external configuration manager for service mesh, external secret vault, and some separate gateway for ingress. This gives huge flexibility in complex scenarios, but means running Nomad in honest production usually requires three products in parallel, each with its own control plane, its own update, its own learning curve.

HeroCtl has integrated router, automatic Let's Encrypt certificates, and encryption between services embedded in the single binary. You don't assemble the mesh — it comes assembled. For small teams that's two months of work saved; for large teams operating dozens of federated datacenters, it's less flexibility.

Key difference 2: application range. Nomad targets high scale. There are public clusters running tens of thousands of nodes. The ecosystem is more mature in that range — and whoever is coming down from Nomad because the complexity isn't justified is usually doing the same math we describe in Kubernetes is overkill: when you don't need it.

HeroCtl targets the "1 to 500 server" range — single-server for prototyping, three for real high availability, dozens to hundreds for productive scale of medium SaaS. Above that, we haven't yet tested at large scale in production; the roadmap gets there, but it isn't this quarter's priority.

Side by side, no flourishes

The column that gives the chills is the second-to-last. "Frozen contract for existing customers" is exactly what was missing in August 2023 — those who had adhered with expectation of open license were caught by the retroactive. In HeroCtl, this is an explicit clause.

Migrating from Nomad to HeroCtl

The good news of primitive convergence: migration isn't an architecture redesign. It is, mostly, a file translation.

Direct mapping. A job in Nomad becomes a job in HeroCtl. A group becomes a replica grouping. A task remains the unit that runs on the agent. Placement constraints (node class, datacenter, custom attribute) have direct equivalents. Update strategies (rolling, canary, blue-green) idem. Health checks via command or HTTP idem.

What changes in the file. The HeroCtl configuration file is smaller — around 50 lines for a common case of web app with ingress and secrets, compared to 80–120 lines in equivalent jobspec. The difference comes from fewer intermediate abstractions and from native integration with the router (you describe ingress: { host, tls: true } in the job itself, not in a separate document).

What needs adaptation. Integrations with the external secret vault need to become secrets: blocks in the job itself (the cluster is the vault in HeroCtl). Service mesh via external configuration manager needs to be replaced with the embedded encryption between services — usually it's simplification, not regression. Non-Docker drivers (exec, java) today don't have a direct equivalent; applications that depend on it stay with Nomad or are packaged in a container.

Experimental converter. There's a jobspec converter under development — takes a Nomad file as input, emits a HeroCtl file as output, with warnings for non-covered cases. It's under development, we don't promote it as a finished product. It covers the common cases (service job with Docker, ingress, health check, secrets); edge cases still require manual review. If it's relevant to your migration, write to us.

Phased plan. The path we recommend for those who have production on Nomad:

• Phase 1 (weeks 1–2). Bring up HeroCtl cluster in parallel, with 3 servers. Migrate first a non-critical job — preferably a batch or periodic job that has no awake user depending on it. Validate logs, metrics, behavior under failure.
• Phase 2 (weeks 3–4). Migrate a web application with few users. Validate certificate issuance, rolling deploy, behavior during server loss. Compare latency and error rate with the equivalent Nomad.
• Phase 3 (weeks 5+). Cutover by application, not entire cluster cutover. DNS points to HeroCtl, monitor for a week, next application. Keep Nomad running what hasn't migrated yet.
• Phase 4 (when comfortable). Decommission Nomad. Document what you learned in your internal wiki for the next tool — because there's always a next tool.

For teams with a few dozen jobs, the entire migration is an afternoon. For teams with hundreds of jobs, and exotic drivers, it's bespoke work — write to us so we can help plan.

When Nomad continues being the right choice

Honesty first: don't migrate out of fashion.

If you're already running Nomad in production without operational problem, stay. License change for those who don't embed nor offer as a managed service is manageable — you run internally, update carefully, wait for the ecosystem to settle. Migrating a stack that works is unnecessary work. For those leaving Nomad after something simpler and single-server, worth considering Coolify as alternative before assuming the path is HeroCtl.

If your architecture deeply depends on other components from the same ecosystem. Secret vault integrated with configuration manager integrated with Nomad, with federated policies and ACLs — undoing that integration is expensive. The cost of leaving may be greater than the license asterisk.

If you operate multi-region at large scale. Hundreds of federated datacenters, with workloads moving between them, depending on mature federation between clusters. Nomad has eight years invested in that direction. HeroCtl has a few quarters in real production. The conservative choice for that profile is Nomad — and that's fine.

If you have governmental contracts that list vendors by name. Some frameworks (FedRAMP, ITAR, federal contracts) require listed vendors. IBM now meets that list. HeroCtl is too young. If your compliance officer needs to point to a company name in an audit list, today the answer is Nomad via IBM, not HeroCtl.

Questions we get

Is HeroCtl just a Nomad clone? No. Convergence of primitives (job, grouping, task, replicated control plane) reflects that these are the right blocks for container orchestration — not a copy. The important differences (batteries included instead of external mesh, frozen commercial contract, application range 1–500) are opposite structural choices, not implementation detail. If it were a clone, the configuration file would have 100+ lines and depend on three parallel products.

What if HeroCtl changes its license? Fair question — it's exactly the kind of question that matters after August 2023. Three protections: the published commercial contract has a clause of frozen terms for existing customers (the agreed price stays, doesn't change retroactively); the binary has no phone-home or kill-switch (once installed, runs independent); Enterprise contracts have active escrow (code goes to paying customers if the company shuts down). It isn't "trust us". It's legal and technical structure that survives management change, acquisition, or shutdown.

Does the jobspec converter convert integration with secret vault and configuration manager? Not entirely. Integrations with external vault become secrets: blocks in the HeroCtl job — the converter does the syntactic transformation, but it's up to you to review the logic (rotation, access policy, scope). Service mesh via external manager generally becomes the embedded encryption, with simplification in most cases. Exotic cases (dynamic policies, secrets with coordinated renewal) get a "review manually" warning in the converter report.

And the Nomad driver plugins? I have a custom driver to run native binaries. Today, HeroCtl runs over Docker as runtime. Exotic drivers (exec, java, qemu, custom) don't have a direct equivalent — the application needs to be packaged in a container. For a lot of things, this is simplification; for some workloads (statically compiled binaries, lightweight virtual machines), it's extra work. If you depend on a non-Docker driver in production, talk to us before migrating.

And the periodic and batch jobs? Supported. HeroCtl has long-running jobs, batch jobs (executes, finishes, releases), and periodic jobs (cron-like). The syntax is direct — a schedule: "*/5 * * * *" key in the configuration file. What we don't yet have is massive batch fan-out (thousands of parallel tasks with result aggregation) — for that, tools dedicated to data flow remain better.

Can I operate HeroCtl behind an existing Nomad? Technically yes — HeroCtl runs on any Linux server with Docker, so you can describe a Nomad job that brings up the HeroCtl agent. But the recommendation is the opposite: run HeroCtl in parallel, migrate application by application, decommission Nomad when comfortable. Nesting two orchestrators is maintaining two control planes, two mental models, two log sets — without gain.

Is Business price higher or lower than Nomad Enterprise? HeroCtl Business and Enterprise prices are published on the plans page — without mandatory "talk to sales" as a qualification tactic. The Nomad commercial license under IBM is negotiated case by case and has no public price; direct comparisons depend on quote. The point we highlight isn't "we're cheaper than IBM" — it's "our price is public and frozen for existing contracts". You know what you'll pay in five years. That predictability is the product.

How does support work? Community has a public forum and community channels — no SLA. Business has direct official support from the manufacturer with hours-level SLA on first response. Enterprise adds 24×7 support and dedicated development for specific extensions. Important: official support is direct, not outsourced via channel, not dependent on extra vendor in the chain.

Closing

The Nomad story is less about Nomad and more about how to adopt infrastructure. Open software controlled by a single company is fragile on a years-scale — not in the code, but in the contract. Acquisition, IPO, management change, investor pressure: any of these can rewrite the base under your feet.

The right answer isn't "reject everything that has a CNPJ behind it". The right answer is to require the contract to be explicit from day one, with frozen terms for those who already signed and continuity mechanism in case the company disappears. Honest commercial software, with these three properties, is structurally more predictable than open software that may change.

That's the HeroCtl design. Commercial since day one. Permanently free Community plan, no artificial feature gate. Business and Enterprise with published prices. No phone-home, no kill-switch. Escrow on Enterprise.

To install: curl -sSL https://get.heroctl.com/install.sh | sh on a Linux server with Docker. For real high availability, the same command on three servers — they form quorum automatically.

To understand the motivation behind this, read why we created HeroCtl — explains the three paths that existed in 2026, the gap each left, and what we tried to fill.

If you're on Nomad and want to talk about migration, write. If you're on Nomad and you're well, stay on Nomad — and take advantage to read the contract more carefully next time a renewal arrives. That's the real lesson of August 2023.