In Q1 2026, Shipyard moved IPFS meaningfully closer to production readiness by:
The result: IPFS continues to cement its evolution as a platform developers can confidently build on at scale.
A major focus this quarter was advancing and implementing IPIP-499 (UnixFS CID Profiles) across the ecosystem. UnixFS is the file system abstraction IPFS uses to represent and address data, and CID Profiles help bring greater consistency to how that data is identified across tools and configurations.
Shipyard contributed across specification development (ipfs/specs), implementation in Kubo, Boxo, and UnixFS libraries, and supporting changes such as configurable shard thresholds and import behaviour.
This work establishes clear, interoperable rules for CID generation. In effect, CID generation becomes a standardised contract rather than an implementation detail. With CID Profiles, IPFS takes an important step toward deterministic, reproducible content addressing — a key capability for production-scale workflows.
Shipyard contributed to IPIP-0524, improving how HTTP gateways handle content negotiation.
The change is simple but impactful: explicit format parameters now take precedence over implicit headers, making gateway responses more deterministic and easier to reason about — particularly for programmatic use.
This provides developers with clearer, more dependable behaviour in automated pipelines and application integrations.
As IPFS deployments grow in scale, visibility into DHT (Distributed Hash Table) announcements becomes increasingly valuable. The DHT is the routing layer responsible for content discovery across the network, and better insight into its behaviour helps operators run systems with greater confidence.
This quarter, Shipyard introduced a new DHT Provide Sweep diagnostic screen in IPFS WebUI, giving developers and operators direct visibility into content provider announcements, propagation behaviour, and routing outcomes.
These improvements make the network easier to observe and diagnose, helping reduce time-to-resolution and improve operational confidence.
One of the most significant operational milestones this quarter was the migration of IPFS.io infrastructure away from Equinix Metal — driven by both the upcoming sunset of the platform in June 2026 and the opportunity to move to a more cost-efficient hosting environment.
This migration underpins both ipfs.io and dweb.link, two of the most widely used entry points into the IPFS network. Improvements at this layer directly benefit availability, latency, and reliability for users accessing IPFS through public gateways.
The migration stands alongside the introduction of Cloudflare and the transition to Rainbow for request handling as a major evolution in how IPFS gateway infrastructure is operated — delivering a stronger, more resilient, and more efficient foundation for future growth.
Shipyard also delivered significant performance improvements to the in-browser gateway at inbrowser.link, continuing to improve the experience of browser-native access to IPFS.
Two areas drove the gains: reducing the bundle size of service worker assets, and optimising the loading strategy through better caching and concurrent fetching.
The result is substantial: the service worker can now download, initialise, and begin fetching content in under one second.
You can see it for yourself:
These improvements represent another important step toward zero-install, browser-native access to IPFS — lowering barriers to entry for both users and developers.
Shipyard introduced enhancements to gateway configuration covering codec conversion controls and more explicit handling of content formats.
These updates give operators finer-grained control over content serving behaviour, enabling more tailored and predictable deployments.
Alongside feature work, Shipyard continued strengthening the underlying stack: migrating away from legacy datastore components (Badger → Pebble), delivering coordinated releases across Kubo, Helia, Boxo, and related projects, and continuously integrating specification changes into production implementations.
Improvements like these are cumulative and foundational. They help ensure that advances across the ecosystem are consistently realised in production environments.
Shipyard also focused on the day-to-day experience of working with IPFS: updating documentation (including dnslink-action), migrating IPFS project websites to self-hosted infrastructure, and supporting ecosystem transitions driven by third-party deprecations.
Reducing friction supports stronger adoption and smoother operations. This work helps teams build and stay on IPFS with confidence as the ecosystem continues to grow.
The work delivered in Q1 2026 reflects the continued maturation of IPFS:
Shipyard’s focus this quarter has been on strengthening the foundations that enable broader adoption, smoother operations, and long-term ecosystem growth.
IPFS is not only a powerful idea — it continues to prove itself as a platform teams can depend on in practice.
Several foundational workstreams are now underway — we’ll be sharing more as they develop.
After migrating 15+ IPFS Project websites from Fleek, Shipyard explains why modular infrastructure with swappable components is the future-proof approach to content-addressed website hosting.
Update from Shipyard on our efforts to make IPFS work on the Web.
Our free IPFS tools and integrations have over 75 million monthly active users around the globe.
Help Fund Shipyard