How to Deploy to Cloudflare in One Click

Esther Howard's avatar

João Castro

blog-details-cover

Why we chose Cloudflare (and not Vercel or Netlify)

People ask me this all the time. Every AI code builder defaults to Vercel. It is the obvious choice -- great DX, tight Next.js integration, easy to set up. So why did I pick Cloudflare Pages for VULK's deployment pipeline?

Three reasons, and they all come down to what matters for the apps VULK generates.

No bandwidth bills. This is the big one. Vercel charges for bandwidth after the free tier. Netlify charges for bandwidth. Cloudflare Pages has zero bandwidth charges. When you deploy a VULK-generated app and it gets traffic, you do not get a surprise bill. For a platform where thousands of users deploy apps, this matters enormously -- both for us and for our users.

Global edge network. Cloudflare has over 300 data centers in 100+ countries. Your deployed app is served from the nearest edge location to every visitor. A user in Tokyo gets served from Tokyo. A user in Sao Paulo gets served from Sao Paulo. Time to first byte is consistently under 50ms globally. Vercel and Netlify have good CDNs too, but Cloudflare's network is genuinely the largest.

Atomic deployments. When you redeploy, Cloudflare serves the old version until the new one is fully uploaded, then switches instantly. No half-deployed states. No downtime. This is critical for a platform where users iterate and redeploy frequently.

The trade-off is that Cloudflare Pages only serves static sites and serverless functions, not full server-side rendered applications. But since VULK generates React + Vite SPAs for web projects, this is a perfect fit. The constraint matches the output.

The deployment flow, step by step

Here is exactly what happens when you click that Deploy button in the VULK editor.

Step 1: You click Deploy. The button is in the top toolbar, next to the preview controls. A deployment dialog opens showing build progress in real time.

Step 2: VULK builds your project on our servers. For a React + Vite app, this runs vite build, which compiles TypeScript to JavaScript, bundles all modules into optimized chunks, processes and purges Tailwind CSS, minifies everything, generates hashed filenames for cache busting, and outputs a clean dist/ directory. This happens on our infrastructure, not in your browser. Build times range from 5 to 20 seconds depending on project size.

Step 3: Upload to Cloudflare Pages. The build output -- static HTML, CSS, JS, and assets -- is uploaded via Cloudflare's Direct Upload API. Your files are distributed across the entire global network.

Step 4: You get a live URL. Cloudflare assigns your project a URL on the pages.dev domain, something like workout-tracker-abc123.pages.dev. HTTPS is automatic -- Cloudflare provisions an SSL certificate instantly. No configuration. No waiting.

The entire process -- build, upload, DNS, SSL -- completes in 10 to 30 seconds. That is not marketing language. I timed it.

What you need before deploying

Two things to verify before hitting Deploy:

Your app compiles in the preview. If the preview shows errors or a blank screen, the production build will fail too. Vite's production build is actually stricter than the dev server -- it catches import errors and type issues that hot module replacement sometimes lets slide. Fix those first.

You are on a paid plan. Deployment is available on Builder ($19.99/mo) and Pro ($49.99/mo) plans. You can try either plan with a trial starting at $1.99.

Performance of deployed apps

I care about this because the apps people deploy from VULK represent our quality. If they are slow, that reflects on us.

VULK-generated React apps are optimized by default. Vite's build produces code-split chunks, tree-shaken bundles, and compressed assets. Combined with Cloudflare's edge caching, the results are consistently strong:

  • Time to first byte (TTFB): Under 50ms for most global locations
  • Full page load: Under 1 second for typical VULK-generated apps
  • Cache behavior: Static assets are cached at every edge location with hashed filenames, so returning visitors load near-instantly

You do not need to configure any of this. The build pipeline and CDN configuration are handled automatically.

Connecting a custom domain

The pages.dev URL works fine for testing and sharing, but for a real project you want your own domain. Here is the process:

1. Note your Cloudflare project name from the deployment dialog or project settings.

2. If your domain is not already on Cloudflare, add it at dash.cloudflare.com (their free plan works) and update your registrar's nameservers.

3. In the Cloudflare dashboard, go to Pages, find your project, open Custom Domains, and add your domain (like myapp.com or app.mydomain.com). Cloudflare creates the DNS record and provisions an SSL certificate automatically.

4. Wait 1-5 minutes for SSL provisioning. If your domain is already on Cloudflare, the whole thing takes under two minutes.

Redeploying after changes

Development is iterative. After deploying, you will make changes -- new features, bug fixes, design tweaks. Redeployment is identical to the first deploy:

  1. Make changes in the editor (via prompts or manual code edits).
  2. Verify in the preview.
  3. Click Deploy.

The new version replaces the previous one at the same URL. Cloudflare's atomic deployment means the switch is instant -- visitors never see a half-deployed state.

There is no versioning UI or rollback mechanism in VULK currently. If you need to revert, use the chat to undo the changes and redeploy. I know this is a limitation, and proper rollback support is on the roadmap.

What gets deployed (and what does not)

Deployed: All static build output. HTML files, JavaScript bundles, CSS files, images in your public/ directory, fonts, and any other static assets.

Not deployed: Source code. Your .tsx files, node_modules, package.json, and build configuration stay on VULK's servers. The deployed site contains only the compiled output.

Not deployed: Backend APIs. If your project uses VULK's backend generation (PostgreSQL + API routes), the backend is hosted on VULK's infrastructure, not on Cloudflare Pages. The deployed frontend makes API calls to our servers. This means your backend works, but it is tied to VULK's hosting for now.

Framework-specific deployment

The deploy process adapts to your project:

  • React + Vite: vite build produces a dist/ folder. Static SPA with client-side routing.
  • Three.js: Same pipeline as React -- Vite builds the game into static files.
  • Shopify Hydrogen: Uses shopify hydrogen build and deploys to Cloudflare Workers (not Pages), since Hydrogen requires server-side rendering.
  • PHP/Laravel: Cannot deploy to Cloudflare Pages -- PHP needs a server runtime. Download the source code and deploy to any PHP hosting provider.

Troubleshooting common issues

Build fails. The most common cause is a TypeScript or import error that the preview's dev server tolerated but Vite's production build rejects. Check the error message in the deployment dialog and ask VULK to fix it. Something like: "The deploy failed with 'Cannot find module ./components/Chart'. Fix the import -- the file is ChartCard.tsx."

Blank page after deploy. Usually a base path or routing issue. Ask VULK: "The deployed app shows a blank page. Make sure the Vite base path is '/' and React Router has a route for the root path."

Broken images or fonts. Static assets need to be in the public/ directory and referenced with absolute paths starting with /. Relative paths work in development but break after deployment.

The bottom line

I wanted deployment in VULK to feel like a non-event. You build your app, you click a button, it is live on the internet. No CI/CD pipelines to configure. No hosting dashboards to learn. No billing surprises from traffic spikes.

Cloudflare Pages made that possible in a way that no other hosting platform could, and the performance numbers speak for themselves. Deploy your first app at vulk.dev.

Partilhar esta publicação
Comentários
Esther Howard's avatar

Esther Howard

Until recently, the prevailing view assumed lorem ipsum was born as a nonsense text. It's not Latin though it looks like nothing.

Responder

Recebe atualizações e dicas do produto

Novas funcionalidades, atualizações de modelos IA e dicas de construção — diretamente na tua caixa de entrada.

  • Sem spam, nunca

  • Cancela quando quiseres

  • Novidades e dicas do produto