How to deploy AI-built websites in 2026: a complete guide

The AI-build-a-website tools shipped in 2024 and 2025 changed how prototypes get made. You describe what you want, the model writes React and Tailwind, and a working preview appears in seconds. The catch is the same for every one of them: the preview is not the production site. To actually ship, you need a real host with a real domain and real uptime.

This guide is the deployment side of that workflow. It covers the five tools most builders use today and the patterns that work in production.

Who this is for

You've built something with Lovable, Bolt.new, Cursor, v0, or Claude artifacts. You want to put it on a real domain. You want to know what actually works without burning a weekend on YAML.

If you're deploying a hand-coded site with no AI involvement, most of this still applies, but the AI-specific patterns at the end will be irrelevant.

The shape of an AI-built site in 2026

Almost every AI-build tool produces the same artefact: a static or single-page app, usually Vite plus React plus Tailwind. The differences are surface-level. Lovable wraps it in a managed editor. Bolt.new compiles it in your browser. Cursor outputs it as a normal local repo. v0 generates components you compose into a project. Claude artifacts are typically a single HTML file or a small React tree.

Here's the shape:

Once you have the build output (a dist/, build/, out/, or a single HTML file), every host serves it the same way. The deploy problem reduces to "upload static files, point a domain, get HTTPS."

Step 1: Get the build output

The first place builders get stuck is realising the AI tool's preview is not the deployable artefact. The preview runs in a sandbox or hot-reload server. To deploy, you need the build.

For most tools, that means downloading the project and running:

npm install
npm run build

This produces dist/ (Vite), build/ (Create React App), or out/ (Next.js static export). That folder is what you upload.

For Claude artifacts that are pure HTML, you skip the build. Save the file as index.html and you're done.

Step 2: Pick a host

The 2026 market for static and SPA hosting splits into three types:

1. The big platforms (Vercel, Netlify, Cloudflare Pages). Generous free tiers, US-headquartered, usage-metered above the free limits.
2. The PaaS (Render, Railway, Fly.io). Multi-service hosting where static sites are one feature among many. Good if you also need backends.
3. The focused EU options (VibeDeploy and a handful of others). Flat per-plan pricing, EU data residency, smaller scope.

Pick by these factors, in order:

• Data residency. If your visitors are EU-based and you handle any personal data (analytics, contact forms, accounts), EU residency makes GDPR compliance materially easier. More on this here.
• Pricing predictability. Usage-metered hosts can surprise you when one of your sites trends. Flat per-plan pricing means you upgrade tiers, not get surprise invoices.
• Free-tier generosity. Cloudflare Pages and Netlify have the largest free tiers. VibeDeploy free tier is small (1 GB) but includes a custom domain.
• Backend needs. Static or SPA only? Most hosts work. Need a backend? You'll want the PaaS options or a separate API.

For this guide, the deploy steps assume VibeDeploy. The pattern translates to any host with minor changes.

Step 3: Upload

Three patterns work, in order of effort:

Drag-and-drop

Sign up, click New Site, drag your dist/ folder into the upload area. Done. This is the right choice for one-shot artifacts and prototypes you don't expect to update often.

CLI

Install once, deploy on every change:

npm install -g @vibedeploy/cli
vibedeploy login
vibedeploy deploy

The CLI detects your framework, builds, and uploads. ~10 seconds end-to-end on a typical SPA.

Git connect

Best for projects you'll iterate on. Connect your GitHub repo, push to main, the host redeploys. Pull-request preview builds work the same way.

Step 4: Custom domain

A vibedeploy.be subdomain is fine for prototypes. For anything client-facing or a real product, you want your own domain.

The mechanics are the same on every host:

1. Add the domain in your host's site settings.
2. Add a CNAME (or A record for apex) in your DNS pointing to the host's edge.
3. Wait 30 to 90 seconds for SSL provisioning.

If you bought the domain through your hosting provider, this is one click. Otherwise it's a copy-paste dance with your registrar's DNS panel.

Step 5: The AI-deploy magic file

This is the pattern that didn't exist before AI tools and matters most in 2026.

When you iterate with an AI agent (Cursor's chat, Claude Code, Aider, GitHub Copilot Chat), you don't want to re-explain the deploy setup every conversation. Drop a .vibedeploy.txt in your repo:

# .vibedeploy.txt
project: my-ai-built-site
token: vbd_xxx
framework: vite
build: npm run build
output: dist

Now any AI agent that reads the repo can ship without prompting. Tell it "deploy this" and it knows where, with what credentials, against what build command. This is the deploy equivalent of a Dockerfile for AI agents.

Common mistakes

These are the patterns we see kill production deploys.

Treating the preview as the deploy. Lovable, Bolt.new, and Claude artifacts all run in sandboxes. The sandbox uses dev-mode runtime tricks (hot reload, in-browser babel, mock APIs) that don't survive the build. Always run the build locally and test the output before deploying.

Hardcoding API URLs. AI tools love to hardcode http://localhost:3000 or a Vite dev URL into fetch calls. Search for localhost, 127.0.0.1, and :// patterns before deploying.

No environment variable strategy. If your app needs an API key (OpenAI, Supabase, etc.), don't put it in the AI-generated code committed to the repo. Use environment variables. Most hosts let you set them per-site.

Skipping the build. Some teams upload the source folder thinking the host will build for them. Some hosts do; many don't. Check whether your host expects pre-built output or source.

No custom domain on the free tier. Many big hosts gate custom domains behind paid plans. Verify before you start.

What's next

Once your site is live, the next things to think about:

• Analytics. Plausible (EU-hosted, GDPR-friendly) or Fathom are common picks for AI-built sites. Both work without cookie consent banners.
• Forms and email. If your site has a contact form, you need a form-handler service. Formspree, Netlify Forms (if you're on Netlify), or a small custom serverless function.
• Monitoring. Pingdom, Better Stack, or your host's built-in uptime monitoring.
• Backups. If your host doesn't keep historical deploys, you should. A bad AI regeneration can ship to production in 10 seconds.

Tool-specific guides

For deeper walkthroughs of each tool's quirks:

• Deploy a Lovable site to a custom domain
• Bolt.new export to production URL
• GDPR matters when hosting AI-built sites in Europe

The base deploy pattern is the same across tools. The differences are in how you get the build output and how the magic file integrates with each tool's AI agent.

TL;DR

Get the build output. Pick a host that fits your residency and pricing needs. Upload. Add a domain. Drop a magic file for the AI agents. Done.