Skip to main content

Earthly Shut Down a Year Ago. Here's What Betting on a VC-Funded Build Tool Actually Costs

8 min readDora NodaDora Noda
Share
On this page

Earthly was five years old, had raised roughly $8.6 million from Innovation Endeavors, 468 Capital, Uncorrelated Ventures, and Bessemer, and had earned 12,000 GitHub stars for a build tool developers actually liked using. Then, on April 16, 2025, its founder published a single blog post that started the countdown to the end. Three months later, on July 16, 2025, Earthly Cloud, Earthly Satellites, and every free tier attached to them stopped working. The open-source CLI itself — the thing thousands of teams had wired into their CI pipelines — was quietly moved to what its own README now calls "no longer actively maintained."

A year later, the pattern is worth studying not because Earthly did anything unusual, but because it did everything a reasonable, well-funded, well-liked developer tool company does right up until it can't anymore. If your build pipeline depends on a venture-funded CI tool today, Earthly's timeline is the closest thing you'll get to a preview of your own.

What Actually Happened

The shutdown wasn't a single event — it was a sequence, and the sequence matters because each step quietly narrowed what "keeping your Earthly pipeline running" would actually require:

DateEvent
Feb 2023Earthly Technologies raises a $6.5M seed round, its second, bringing total funding to roughly $8.6M
Apr 16, 2025Founder announces Earthly will stop active OSS maintenance beyond critical bug fixes; calls for community volunteers to organize a fork by Apr 30
Apr 30, 2025Deadline for prospective fork maintainers to register interest
Jul 16, 2025Earthly Cloud, Satellites (Cloud, Self-Hosted, and BYOC variants), Secrets, and Logs all stop working
Jul 2026 (today)earthly/earthly still carries the "no longer actively maintained" banner; stars and forks (12k / 456) have barely moved in a year; no independently governed successor fork has shipped a stable release

That last row is the one most retrospectives skip. Earthly's call for fork maintainers wasn't rhetorical — the company genuinely offered to hand the project to volunteers, on the condition they rename it to avoid trademark conflict. A year on, no such fork exists as a going concern. The offer to self-organize was real; the coalition to actually do it never materialized.

The Migration Path Users Actually Got

To its credit, Earthly didn't just walk away. It arranged a landing spot: Dagger, a competing build-pipeline tool, offered displaced Earthly users one free year of Dagger Cloud Team, a hands-on migration workshop pairing Dagger engineers with community Earthly experts, and a dedicated Discord channel for transition support.

What that offer doesn't change is the actual migration cost. Earthfiles are a Dockerfile-and-Makefile hybrid — declarative build targets a developer could read in five minutes. Dagger's model is different in kind: pipelines become code, written as Go, Python, or TypeScript functions that call into Dagger's SDK. There is no automated converter, because there's no structural mapping from "declarative build target" to "imperative function" — a team migrating isn't porting a config file, it's rewriting its CI logic in a general-purpose language it may not have chosen for that job.

One team's published migration plan puts a number on that rewrite. Terraphim AI scoped its move off four Earthfiles covering 40-plus build targets — spanning a root project, a desktop app, a server, and cross-compiled infrastructure for x86_64, armv7, and aarch64 — at roughly 154 hours of engineering time, close to four weeks of one person working full time, spread across a 12-week project with dedicated phases for setup, conversion, validation, and cutover. That's the real price of "arranged a migration path" for a mid-sized codebase: not a config swap over an afternoon, but a month of dedicated engineering work to reproduce build behavior — multi-architecture caching, vendor directories, cargo caching — the team already had working before the shutdown notice arrived.

Here's the detail that turns this from an inconvenience into the actual lesson: Dagger itself has raised $30.4 million in venture funding, led by Redpoint Ventures with Y Combinator participating. A team that spends its free migration year rewriting Earthfiles as Dagger Functions hasn't stepped outside the risk category Earthly's shutdown just demonstrated — it's re-entered it with a different vendor's name on it. If bottom-up open-source adoption not converting into enterprise revenue was Earthly's stated cause of death, that pressure doesn't disappear because you switched providers. It's the same investor calculus, running against a different clock.

This Is Not Earthly's First Rehearsal

Earthly is one data point, and a single data point risks a story that's too neat. A better test of the underlying pattern is a case with the same root cause but a different outcome: HashiCorp's Terraform relicensing in August 2023.

HashiCorp switched Terraform from the open MPL 2.0 license to the restrictive Business Source License — a different mechanism than Earthly's shutdown, but the same shape of event: a venture-backed dev-tool vendor made a unilateral business decision that broke what a large user base had built on top of it. The community response was the OpenTF Manifesto, published within days, which by September 20, 2023 had become OpenTofu — accepted into the Linux Foundation, governed by a Technical Steering Committee drawn from multiple companies, and shipping a production-ready 1.0 release by January 10, 2024. Less than five months from relicense announcement to stable, independently governed fork.

Compare the two outcomes. Terraform's fork succeeded fast because Spacelift, env0, Scalr, and Harness — companies that sell Terraform-compatible infrastructure tooling — all had a direct commercial reason to fund engineers to keep an open Terraform-compatible core alive. Nobody competes commercially on "who runs your Earthfile the best," so when Earthly asked the community to self-organize, there was no coalition with an economic stake in showing up. The volunteers Earthly hoped for needed to already be funded by something; for Terraform, that something existed. For Earthly, it didn't.

That's the generalizable lesson, and it's more precise than "avoid VC-funded tools" — plenty of VC-funded infrastructure survives vendor exits just fine, provided a fork has an economic engine behind it. The question that actually predicts what happens to your pipeline isn't "is this tool open source" or even "is this company venture-backed." It's: if this vendor's business model fails tomorrow, who has a commercial incentive to keep a fork alive — and for most single-company build DSLs, the honest answer is nobody.

What Actually De-Risks a Build Pipeline

None of this means avoid every dev tool built by a startup — that would rule out most of the interesting ones. It means being deliberate about which layer of your pipeline you let a single company's roadmap own:

  • Prefer commodity specs with multiple independent implementations over a single vendor's DSL. An OCI image, a Dockerfile, or the Cloud Native Buildpacks spec can be built by any of several competing tools (Docker, Podman, Kaniko, Paketo, Nixpacks, Railpack). If one implementation disappears, the spec doesn't go with it — you switch tools, not architectures.
  • Ask who else benefits if the vendor disappears. OpenTofu survived because Spacelift, env0, and others had a reason to fund it. Before adopting a proprietary pipeline language, look for that same coalition — a foundation, a set of competing commercial implementations, anything beyond "the community will probably step up." Earthly's own experience is the counterexample: a sincere ask for volunteers, with no funded coalition behind it, produced no successor a year later.
  • Self-host the build step itself, not just the config. The deepest form of this insurance is running the actual build execution — not just the pipeline definition — on infrastructure you own. A vendor's shutdown notice can end your support contract and your hosted control plane. It can't revoke your ability to run docker build or a buildpack lifecycle on your own machines, because nothing about that step was ever theirs to take away.

Bex.co's own build path is intentionally built on that last principle: it runs Cloud Native Buildpacks — an open spec with multiple independent implementations, not one company's CLI — on Cluster API-managed machines a team owns outright. A git push triggers a build that never depends on any single vendor's cloud staying solvent, because the build step was never rented in the first place.

Earthly's users didn't do anything wrong. They picked a well-funded, well-reviewed, well-loved tool, and it died anyway — not from incompetence, but from an ordinary venture-funding outcome that a bottom-up open-source adoption curve was never going to outrun. The lesson isn't to distrust developer tools built by startups. It's to ask, before the migration email arrives, who besides the vendor has a reason to keep your build pipeline alive.


Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex