How to Host Your App on IPFS and Filecoin with Fleek in 2026

Fleek is a hosting service that takes a web app built with a common frontend framework and publishes the output to IPFS, the InterPlanetary File System. You connect a code repository, Fleek runs the build, and the resulting files are stored on IPFS so anyone with the address can load them through a gateway.

The main appeal is that you do not have to install IPFS software, manage a server or run command line tools for pinning. Fleek's documentation describes hosting tools for sites and apps on IPFS, including continuous integration and deployment through GitHub. That matches the workflow in this guide: push code, let the build run, then check the published version.

Fleek has also been part of the Filecoin ecosystem, where it has been described as a way to deploy websites without relying on a central web host. Ecosystem descriptions are useful for understanding the goal, but they do not tell you what you will pay or which features your plan includes.

Check Fleek's current site for plan limits, build minutes, bandwidth and custom domain options before you start. Those details change often. The steps and concepts below stay the same across plan changes, so you can apply them whichever plan you use.

IPFS addresses files by their content rather than by location. Each file or folder gets a content identifier, called a CID, calculated from its bytes. If one byte changes, the CID changes. This gives you verifiable content: anyone can check that what they received matches the CID they requested.

IPFS nodes serve the content they hold and share it with peers. A node keeps data only while it has a copy or has been told to keep it. Pinning means asking a node or service to keep a copy available. If nobody pins a piece of content, it can become unavailable.

Filecoin is a separate network built around storage deals. Storage providers agree to hold data for paying clients and prove that they are storing it. Filecoin is often used for longer-term persistence of IPFS data, while IPFS handles addressing and retrieval.

• IPFS: content addressing and peer-to-peer retrieval
• Pinning: keeping a copy available so the content stays reachable
• Filecoin: storage deals that keep data persisted for a set term

Hosting services may use their own pinning and storage arrangements. Ask how your site is kept online and for how long, and keep your source code and build output somewhere you control.

IPFS serves static files. Plain HTML, CSS, JavaScript and images work well. A single-page app built with React, Vue, Svelte or a similar framework also works, as long as the built output is static and the app talks to blockchain nodes or public APIs from the browser.

What does not run on IPFS is a server. Any code that must run on each request, keep a database, or hold secrets needs another host. This is the usual answer to the question of whether a Node.js application can live on IPFS: the frontend can, while the server runs elsewhere.

Part of the app	Suitable for IPFS	Notes
Static HTML, CSS and JavaScript	Yes	The core use case
Built single-page app frontend	Yes	Needs correct client-side routing setup
Server-side rendering with a live server	Depends	Often needs a static export or a separate host
Node.js API or backend	No	Host separately and call it from the frontend
Database	No	Use a separate service for off-chain data

Wallet connection, reading contract data and sending transactions can all happen in the browser. The wallet signs each transaction, so your site never needs a private key.

Before you connect anything to Fleek, make sure the project builds cleanly on your own machine. Deployment problems are much easier to fix locally than in a hosted build log.

1. Run the install and build commands from a clean copy of the repository.
2. Find the output folder the build creates. Common names are dist and build, but some frameworks use other names.
3. Open the output folder through a local static server and confirm the pages, images and scripts load.
4. Commit your lockfile so the hosted build installs the same dependency versions you tested.
5. Note the Node version you used and set the same version in the hosting settings if the option is available.
6. Review every value that gets bundled into client code. Anything in the browser bundle is public, so remove API secrets, private keys and admin tokens.
7. If your app runs under a subpath, set the base path in your router and build config now.

RPC endpoints and API keys for read-only services are a common source of confusion. Some providers allow public keys with rate limits, and others expect you to restrict a key to specific domains. Read your provider's documentation and choose the option that matches a public frontend.

The exact labels in Fleek's dashboard can change, so treat these steps as the general sequence rather than exact button names.

1. Create an account on Fleek and choose the option to connect a Git provider.
2. Authorize Fleek to read the repository you want to publish. Limit access to the specific repositories you need where the option is offered.
3. Select the repository and the branch you want to deploy, usually main.
4. Choose a framework preset if one matches your project. Otherwise enter the install and build commands you tested locally.
5. Set the output directory to the folder your build creates.
6. Add environment variables for public configuration, such as a public RPC URL or a chain ID. Do not add private keys.
7. Start the deployment and open the build log. Read the log from top to bottom, because the first error often explains later failures.
8. When the build finishes, note the published address or CID that the dashboard shows.

After the first deployment, each push to the selected branch can trigger a new build. Every build that changes the output produces a new CID. If you want stable releases, deploy from a dedicated release branch and merge only tested code into it.

A successful build does not always mean a working site. Test the published version the same way a user would reach it.

• Open the published address and wait for the first render.
• Check the browser developer console for failed script or asset requests.
• Visit several routes, not only the home page, and reload each one.
• Connect a wallet on a test account and confirm the connection prompt appears.
• Read a value from the chain and confirm it matches a block explorer.
• Test one small transaction on a test network if your app supports one.

IPFS gateways can serve the same CID, but caches and gateway choice may differ. If something looks wrong, try a second gateway before you assume the deployment failed. If you run a local IPFS tool, you can also check that the CID you see matches the output you built.

Record the CID for each release in your own notes or repository tags. That record helps you roll back by pointing your domain or ENS name to an earlier version, and it helps you confirm which files a user is seeing.

Long CIDs are hard to share and change with every build, so most projects use a human-readable name. There are two common routes.

The first is a custom domain. You add the DNS records that Fleek gives you at your domain registrar. Your domain points to the hosted site, and you can update the deployment without changing the link. Check that you control the domain and that the DNS change is made by an account you trust.

The second is an ENS name. ENS is an Ethereum naming system. You can set the content hash of your ENS name to a CID, so that the name resolves to your site. Updating that record is an Ethereum transaction, so it costs gas. Whoever makes the change pays the network fee, and the fee changes with network conditions.

Security matters more here than anywhere else. Only update the ENS name from a wallet you control, ideally a hardware wallet. Confirm the name is registered to your address before you change it. A compromised name or domain can send users to a malicious copy of your app.

Most deployment problems come from a few predictable causes. Start with the build log and the browser console before changing settings.

• Blank page: the build uses absolute asset paths that break under a subpath. Set the public path or base path to relative or to the correct subfolder.
• 404 errors on refresh: single-page apps need every route to serve the main HTML file. Use hash-based routing if the host cannot provide that fallback.
• Build fails with a dependency error: check that the lockfile is committed and that the Node version matches your local test.
• Wallet cannot connect: the wallet is usually blocked by the RPC provider's domain rules or the chain configuration is wrong. Check the chain ID and the provider's allowed origins.
• Images or fonts missing: confirm the output directory is correct and the files are inside it.
• Old version still showing: wait a few minutes, try a different gateway, and hard-refresh the page. Confirm the domain or ENS name points to the newest CID.

If a problem continues, compare the failing build with the last one that worked. The difference is often a single dependency, environment variable or config value.

Once the site is live, plan for availability and security. Keep the repository as the source of truth, and keep a copy of the build output for each release. If a hosted deployment is unavailable, you can redeploy from the same code or move to another host.

For availability, understand how your content is pinned and stored. Ask your provider whether data is pinned on IPFS, whether Filecoin deals are used, and how long those deals last. If the site matters to users, discuss a second pinning arrangement with your provider or run one yourself.

For security, keep the frontend free of secrets and review dependencies before each release. Watch for changes in the libraries you bundle, and rebuild after applying fixes. Because anyone can copy public IPFS content, add clear signals that help users check they are on the right site, such as a stable domain or ENS name and a published list of official contract addresses.

Finally, document how to roll back. Write down which CID is current, which one was previous, and who can change the domain or ENS record. A short written process turns a stressful outage into a routine change.