DigitalOcean has decided to end its Open Source Credits Program, which provided infrastructure credits to free software projects, without accompanying the decision with a public announcement. The first known cases show the impact on projects that rely on the cloud for critical tasks: Node.js found itself considering migrating 21 virtual servers, while other maintainers are looking for new sponsors so they don’t have to absorb the cost of their infrastructure all at once.
DigitalOcean’s open source credits: the key facts in 30 seconds
- DigitalOcean has closed new applications and renewals for its open source credits program.
- Credits already granted remain in place under their current terms, but can’t be extended or renewed.
- Node.js had 21 Droplets tied to its build, testing and services infrastructure.
- The company has committed $3 million to the Omacom Foundation to fund Omarchy.
- The case puts the spotlight back on how many free software projects depend on corporate sponsorships to keep their infrastructure running.
The decision became known through emails sent to maintainers. In one documented case, DigitalOcean said it was no longer accepting new applications and wouldn’t approve renewals, extensions or additional credit requests either. The company also said the program’s dedicated inbox would no longer be monitored and that inquiries would be routed to the regular support channel.
So far, there’s no public statement from DigitalOcean explaining the reasons behind the shutdown. The company still keeps a section on its website dedicated to open source software and highlights how important this development model is to its own business, but that page doesn’t address the end of the credits program.
The lack of a general announcement meant the change surfaced first in the repositories and communities of the affected projects.
Node.js Had to Rethink Its Infrastructure
One of the best-documented cases is Node.js. The project’s infrastructure team opened an issue on October 1 titled “Solidify Digital Ocean Partnership” after receiving DigitalOcean’s email.
The initial reaction was to look into pulling the provider’s services. The team noted it would need to find an alternative for the 21 Droplets it was using, on top of reviewing volumes, snapshots and backups.
That figure helps explain that these programs don’t always fund small servers used for personal projects. In Node.js’s case, DigitalOcean is one of its top-tier infrastructure providers and supplies resources for important parts of the project, including infrastructure used for builds and testing.
Node.js’s infrastructure is spread across several providers. Its own infrastructure repository explains that DigitalOcean supplies a significant share of the resources needed to run the project, while other companies provide servers, email services and various other components.
The situation evolved quickly. In the same issue, Node.js maintainers later updated their position to say that DigitalOcean was willing to help work through the transition and that new conversations would open up about the relationship between the two organizations.
That changes the outcome for Node.js, but it doesn’t remove the problem that triggered the announcement in the first place. The project had to react to the possibility of losing a significant part of its infrastructure and revisit a dependency that had been built into its operations for years.
On top of that, Node.js has far more visibility and negotiating leverage than many independent projects. A small project may not run 21 machines worth of infrastructure, but it also may not have the audience needed to get a provider to sit back down at the table.
Other Projects Are Already Looking for Alternatives
Node.js’s case isn’t isolated. Other projects have published their own statements about the end of the program.
On the Textpattern forum, for example, a maintainer confirmed receiving the same message from DigitalOcean. The project plans to keep using its own servers, expand its network of providers, and turn to open source incentives when they’re a good fit.
There are also other free infrastructure projects that have said they need to find alternative hosting for their continuous integration systems.
The situation is especially delicate for projects without enough revenue to pay for equivalent infrastructure. An application can be fully free, maintained by volunteers and have thousands of users, but that doesn’t mean it has the money to pay for servers, storage, bandwidth and backups.
For years, cloud credits have helped cover that gap.
The model is simple: the provider hands over a set amount of credit, and the project uses its services without directly bearing the full cost. For a tech company, it can be a tool for building relationships with developers and communities. For an open source project, it can become a structural piece of its infrastructure.
The problem shows up when the sponsorship goes away.
The Contrast With the $3 Million for Omarchy
The decision has sparked even more discussion because of how close it came, timing-wise, to another DigitalOcean announcement.
On September 9, David Heinemeier Hansson announced that DigitalOcean was joining as a Founding Corporate Patron of the Omacom Foundation with a commitment of $1 million a year for three years, totaling $3 million for the development, maintenance and promotion of Omarchy.
Omarchy itself described the deal as a contribution meant to fund the project, and noted that DigitalOcean would also act as the compute provider for its build systems.
The timing has drawn criticism within the free software community. Some developers have read the withdrawal of general credits and the new Omarchy sponsorship as related decisions.
However, there’s no public information showing that the $3 million earmarked for Omarchy came from the budget that previously funded the open source credits program. Nor has DigitalOcean publicly explained that the program’s closure is tied to that agreement.
That’s why the connection should be treated as a coincidence that has sparked debate, not as a proven transfer of money between the two programs.
The difference between the two models is clear enough, though. The credits program benefited numerous individual projects with amounts earmarked directly for infrastructure. The agreement with the Omacom Foundation is a specific, multi-year corporate sponsorship.
They’re different mechanisms, even though both draw on DigitalOcean’s resources to support projects tied to free software.
The Problem Goes Beyond DigitalOcean
The case exposes a common weakness in open source infrastructure: many critical projects depend on resources they don’t directly control.
Code can be published on GitHub, licenses can allow its use, and thousands of developers can contribute to it. But running continuous integration systems, building releases, distributing binaries, maintaining documentation, hosting services or keeping backups all cost money.
When a company covers that cost through credits, the project can run for years without needing to build its own financial structure.
The trade-off is that those credits aren’t the same as a long-term infrastructure contract.
DigitalOcean has made clear that credits already granted will remain valid under their existing terms. So projects that still have a balance haven’t immediately lost their servers. The problem will arrive once that credit runs out and can’t be renewed.
That window allows time to prepare migrations, negotiate with other providers or look for funding. But it also forces maintainers to spend time on a task that has nothing directly to do with developing the software.
For small projects, the situation can be harder than it was for Node.js. They don’t necessarily have multiple providers, a legal entity, a large community or the ability to negotiate special terms.
The experience also serves as a reminder for anyone designing infrastructure for free software projects: a free credit shouldn’t be mistaken for a long-term guarantee of availability.
The cloud can make it very easy to spin up a service. The cost shows up once that service becomes a permanent piece of a project’s infrastructure and the provider changes the terms.
The end of DigitalOcean’s program doesn’t mean the affected projects are going to disappear. Node.js is already negotiating a path forward, and other projects are looking for alternatives. But it does force several maintainers to revisit a dependency they could, until now, consider stable.
And that’s the issue that goes beyond DigitalOcean: a significant part of the infrastructure holding up free software runs on sponsorship agreements that can change with a single corporate decision, with no transition period comparable to a conventional commercial contract.
Frequently asked questions
Has DigitalOcean closed its open source credits program?
Yes. DigitalOcean has told participating projects that it’s ending the Open Source Credits Program and is no longer accepting new applications, renewals, extensions or additional credit requests.
What will happen to the credits projects already have?
DigitalOcean has said that credits already granted will remain valid under existing terms. The problem will arrive once those credits run out or it’s time to renew them.
How many DigitalOcean servers does Node.js use?
Node.js’s infrastructure team initially said it would need to look into migrating 21 Droplets, along with other resources such as volumes, snapshots and backups.
How is the closure related to the $3 million for Omarchy?
DigitalOcean announced a $3 million commitment to the Omacom Foundation in September, but there’s no public information showing that money came from the open source credits program’s budget, or that the two announcements are directly connected.
