How to Migrate IPFS Websites from Fleek to Modular Infrastructure

Marcin Rataj
How to Migrate IPFS Websites from Fleek to Modular Infrastructure
#kubo #gateways #fleek #websites
Share this item:

Cross-posted from the Shipyard blog (opens new window).

This is a practical guide to hosting websites on both HTTP and IPFS using modular, swappable components. When Fleek announced it was discontinuing hosting, we migrated 15+ IPFS Project websites to a setup designed to survive any single provider shutting down. Whether you're moving off Fleek or just want more resilient hosting, this guide covers the approach and the tools we used.

# What Changed

Sites including ipfs.tech (opens new window), docs.ipfs.tech (opens new window), blog.ipfs.tech (opens new window), and specs.ipfs.tech (opens new window) now use:

All sites now have redundant hosting: traditional HTTP via GitHub Pages and content-addressed access via IPFS Desktop (opens new window) with IPFS Companion (opens new window) and third-party public IPFS gateways (opens new window).

# Third-Party Services Come and Go

Fleek Hosting was a turn-key solution that combined HTTP CDN with TLS, IPFS pinning, IPFS gateway, DNSLink, IPNS, ENS, and GitHub Actions CI integration in one platform. Fleek is pivoting to AI (opens new window) and discontinuing its hosting services on January 31, 2026 (opens new window).

The IPFS service landscape is always evolving. Some providers have shut down or changed focus: nft.storage transitioned operations (opens new window), Infura deprecated its IPFS public API and gateway (opens new window), and Scaleway shut down IPFS pinning (opens new window). At the same time, new options have emerged: Storacha (opens new window) launched as a successor to web3.storage, Shipyard took over Cloudflare's public IPFS gateways (opens new window), and pinning services like Pinata (opens new window) and Filebase (opens new window) continue to grow. This isn't a criticism of any particular service. Commercial offerings evolve based on business realities. The lesson: design your setup so that no single provider change requires starting over.

# Modularity as the Future-Proof Approach

IPFS is built for robustness (opens new window): strict about verification outcomes, tolerant about methods. A hosting strategy should follow the same principle.

Decouple Web2 hosting from IPFS content-addressing. Keep each component independent:

  • HTTP: GitHub Pages, Cloudflare Pages, or a self-hosted server
  • IPFS: pinning/storage service, self-hosted Kubo/IPFS Cluster, or both
  • DNS: Cloudflare, Gandi, DNSimple, Route53, or any provider with a management API

DNS serves both layers: HTTP needs A/AAAA records and TLS certificates, IPFS needs TXT records for DNSLink to map domains to CIDs.

The key: control CID and CAR creation. Creating the CAR locally means no lock-in to any provider. Pick content providers that accept the CAR. If one shuts down, upload the same CAR elsewhere. HTTP hosting and DNS stay untouched.

Compare this to an all-in-one platform. When it shuts down, everything needs rebuilding.

Two standards make this work: CAR files (opens new window) for portable content and DNSLink (opens new window) for human-readable addressing. Switching providers requires no pipeline changes.

# Our Setup

We use our own IPFS Cluster (opens new window) instance since Shipyard already runs IPFS infrastructure. For most projects, a third-party pinning service (opens new window) works just as well with less operational overhead.

Our CI/CD uses two GitHub Actions:

ipshipyard/ipfs-deploy-action posts a comment on each PR with gateway preview links and CID commit status

For security, we use a sandboxed DNS zone pattern: CI credentials can only modify DNSLink TXT records, not other DNS entries. If credentials leak, the blast radius is limited to the _dnslink subdomain. See the dnslink-action security documentation (opens new window) for details.

# Getting Started

Already have HTTP hosting? Just add IPFS and DNSLink. Migrating from Fleek? Pick all three.

  1. HTTP: GitHub Pages (opens new window) and Cloudflare Pages (opens new window) are simple and maintenance free. For all-in-one self-hosted HTTP+IPFS, see Setup a DNSLink Gateway with Kubo and Caddy (opens new window)
  2. IPFS: Choose a pinning service (opens new window) or run your own node. Follow Deploy static apps to IPFS with GitHub Actions (opens new window)
  3. DNS: See Automate DNSLink updates with GitHub Actions (opens new window) for TXT record automation, or use OctoDNS (opens new window) for more providers

The ipfs-deploy-action (opens new window) creates the CID and exports the site as a CAR file. This makes content portable across any provider that accepts CARs. The dnslink-action (opens new window) links CID to DNS, allowing IPFS-enabled browsers (opens new window) to load content over IPFS.

# Conclusion

Third-party services will continue to come and go. The takeaway: separate your concerns and use standards-based tooling. Keep HTTP hosting independent from IPFS content-addressing, create CARs in your own CI rather than someone else's cloud service so you can switch providers, and automate DNSLink updates so they're not tied to any particular service. When one component needs replacing, swap it out without rebuilding everything. This modularity is the robustness that IPFS enables.

All the tools we used are open source and documented. If you have questions, open an issue in the respective repositories or reach out in the IPFS community forums (opens new window).