Losing Shipyard is not the worst thing that happened to IPFS this year. The worst thing is that most of us building on it never noticed how few people were holding it up.
Here are the two dates that matter. Shipyard, the team behind much of IPFS’s core infrastructure, winds down on September 30, 2026, after Protocol Labs declined to renew their funding. Infura shuts down its IPFS service on August 15, 2026. That’s it. That’s the news. Two announcements, a handful of months apart, and a protocol that a lot of agent projects quietly treat as permanent plumbing.
I’ve shipped bots that pinned content to IPFS through a hosted gateway because it took about four lines of code and I didn’t have to think about it again. That last part was the mistake. Not the choice of IPFS — the not thinking about it again.
Why this lands harder on bot projects than on most software
Bots accumulate artifacts. Conversation transcripts, generated images, embeddings dumps, model checkpoints, scraped documents, plugin manifests. If you’ve built anything with a memory layer, you’ve had the moment where you needed content-addressed storage and IPFS looked like the obvious answer. A hash instead of a URL. Deduplication for free. No vendor lock-in, supposedly.
That last claim is where the wheels come off. Content addressing removes lock-in at the naming layer, not at the operations layer. Your CID stays valid forever. Whether anyone is still serving the bytes behind it is a completely separate question, and it’s a question that depends on funded humans running pinning services and maintaining client libraries. Two of those funded groups just put expiration dates on the calendar.
If your bot resolves content through a hosted IPFS gateway, that call is a third-party API dependency wearing a decentralization costume. Treat it accordingly.
What I’d actually do this week
Not a migration plan. Just an audit, because you probably don’t know your exposure yet.
- Grep for gateway hostnames. Look for any hardcoded gateway domain in your codebase, your config, your frontend, your prompt templates. Bots love embedding URLs in generated output, which means stale gateway links can end up in data you’ve already shipped to users.
- List every CID you depend on and where it lives. If you can’t produce that list from a database query or a manifest file, that’s the first thing to build. You cannot re-pin what you can’t enumerate.
- Check whether you’re pinning or just hoping. Plenty of projects add content to IPFS, get a CID back, and assume persistence. Adding is not pinning. Pinning through a service that shuts down is not persistence either.
- Put a storage interface in front of the calls. One small module with
put,get, andexists. Your bot’s business logic should not know what protocol is underneath. This is the change that turns future shutdowns into a config edit instead of a refactor.
The part that isn’t about IPFS at all
Agent stacks in 2026 are dependency trees with weather systems on top of them. Model APIs, vector databases, embedding providers, orchestration frameworks, hosted queues, tool registries. Most of it is maintained by small teams running on grant money, seed rounds, or the goodwill of a maintainer who has a day job.
The Shipyard situation is a clean illustration because the cause is stated plainly: funding wasn’t renewed. Not a technical failure, not a security incident, not a competitor winning. A budget decision upstream of the code. No amount of test coverage or protocol elegance protects you from that.
So the useful takeaway isn’t “stop using IPFS.” Content addressing is still a genuinely good idea for the kind of data bots produce, and the protocol doesn’t stop existing on September 30. The takeaway is that you should be able to answer, for each external system your bot touches, two questions: who pays for this, and what breaks if they stop?
If you can’t answer either one, you have a single point of failure you haven’t named yet.
A cheap habit that pays for itself
I’ve started keeping a plain text file in every bot repo called DEPENDS.md. One line per external service: what it does, who runs it, what the fallback is, and how long a migration would take. It takes twenty minutes to write and it’s the first thing I check when a shutdown announcement lands. Half the value is just the discomfort of writing “fallback: none” and having to look at it.
Two dates on the calendar, eight-ish months apart. Enough runway to move deliberately if you start now, and enough to hurt if you wait for the last week of August. Go read your own code and find out which one you’re in for.
🕒 Published: