> For the complete documentation index, see [llms.txt](https://prodocs.webhash.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prodocs.webhash.com/what-you-can-deploy.md).

# What You Can Deploy

WebHash Pro publishes your project to IPFS, which is decentralized storage for static files addressed by their content hash (a CID). Think of it as a decentralized CDN: it serves files, but it does not run any server-side code.

The simple rule: if your project compiles to **static files that run entirely in the browser**, it is a great fit. If it needs a **live server** running behind it, it is not, though you can usually adapt it (see below).

{% hint style="info" %}
Not sure which category your project is in? Skim the two lists below. Most modern frontends and all static sites work; anything that renders pages on a server, per request, does not.
{% endhint %}

## Works great on IPFS

1. **Static websites** - plain HTML, CSS, and JavaScript: landing pages, blogs, portfolios, documentation, and marketing sites. A perfect fit.
2. **Static-site-generator output** - Hugo, Jekyll, Eleventy, Astro, Gatsby, Docusaurus, VitePress, and Next.js in static-export mode (`output: 'export'`). These pre-render everything to static files at build time.
3. **Single-page applications (SPAs)** - React (Vite or Create React App), Vue, Svelte, Angular, and similar. The whole app is a JavaScript bundle that boots in the browser and fetches data from external APIs or smart contracts.
4. **Web3 dApp frontends** - the signature use case. A static frontend, plus a wallet (RainbowKit/wagmi), plus smart contracts and RPC gives you a fully decentralized app: hosted on IPFS, reachable at an ENS domain like `yourname.eth`, with no centralized server anywhere. WebHash Pro is built precisely for this.
5. **Client-only apps and tools** - games, calculators, visualizations, and anything that runs purely in the browser.

## Does not work (and why)

Because there is no server process behind IPFS:

* **Server-rendered apps** - Next.js SSR, API routes, server components and actions, and ISR; Remix or Nuxt in SSR mode. Next.js works **only** as a static export: no `/api` routes and no per-request rendering.
* **Backends and APIs** - Express, Django, Rails, and the like. No server-side code can execute.
* **Server databases** - there is no Postgres or MongoDB "on IPFS." Your data has to live elsewhere: an external API, a smart contract, a decentralized database, or browser storage.
* **Server-held secrets** - every file is public and content-addressed, and there is no server to keep a secret. Only build-time public variables (`NEXT_PUBLIC_*`, `VITE_*`) make sense.

{% hint style="warning" %}
Never put a private key, API secret, or password in your build. Everything you deploy to IPFS is public and permanent.
{% endhint %}

### Adapting a dynamic app

You usually do not have to give up a dynamic app, you just split it. Deploy the **static frontend** to WebHash Pro, and move the dynamic parts to something the browser can call directly: an external API, serverless functions, smart contracts, or decentralized storage.

## What WebHash Pro supports

WebHash Pro auto-detects your project and builds it for you. It recognizes:

* Static sites
* React (Vite)
* React (Create React App)
* Next.js (static export)
* Generic "build to static output" projects

After the build, it runs **IPFS-compatibility post-processing** automatically: rewriting asset paths, adding a base href, handling `manifest.json`, and adding single-page-app routing fallbacks. This matters because IPFS serves your site under a `/ipfs/<CID>/` path prefix, so apps that assume root-absolute paths, or that rely on a server for client-side routing, need these fixes to work correctly on a gateway. You do not have to configure any of it.

![Project type selector in the deploy wizard](/files/Ptrht0rE1h72ZfOrP5VR)

{% hint style="success" %}
Ready to deploy? Head to [**Deploying a Site**](/deploying-a-site.md).
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://prodocs.webhash.com/what-you-can-deploy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.