Deploy a converted Framer site to Vercel, Netlify, Cloudflare or Fly.io

A Framer site converted with Deframer is a standard Next.js 16 App Router project in TypeScript, so you deploy it like any other Next.js app. On Vercel and Netlify, you connect a Git repository or use their CLIs; on Cloudflare Workers, you add the @opennextjs/cloudflare adapter; on Fly.io, you add a Dockerfile and run fly launch. Whichever host you choose, set the form webhook environment variables, update metadataBase to your production domain, and test before moving DNS.

Before you deploy anywhere

Do these once, locally, whatever host you pick.

1. Use Node.js 20.9 or later. Next.js 16 requires it, and your host should run the same major version you test with.
2. Install and build. A clean production build catches most problems before a host does.

   npm install
   npm run build
   npm start

3. Put the project in Git. npm install creates a package-lock.json; commit it so every host installs the same versions. The project's .gitignore already excludes node_modules, .next and .env*.local.
4. Collect your environment variables. If the site has forms, .env.example lists FORMS_WEBHOOK_URL (receives every form's submissions) and one FORMS_<NAME>_WEBHOOK_URL per form. Without them, submissions are only logged by the server. Details are in forms after leaving Framer.

Deframer doesn't deploy for you or connect to your Git provider. You download the .zip, and from there the project is yours to host.

Vercel

Vercel builds Next.js projects without extra configuration.

From the dashboard

1. Push the project to a Git repository.
2. In Vercel, create a new project and import the repository. The framework is detected as Next.js.
3. Add your FORMS_… variables under the project's environment variables.
4. Deploy. Each push to a branch gets a preview deployment.

From the CLI

npm i -g vercel
vercel            # creates a preview deployment
vercel env add FORMS_WEBHOOK_URL
vercel --prod     # deploys to production

Netlify

Netlify detects Next.js and applies its Next.js runtime automatically. You can add a netlify.toml to make the build explicit. This is a new file you add at the project root:

[build]
  command = "npm run build"
  publish = ".next"

[build.environment]
  NODE_VERSION = "22"

Then either connect the repository in the Netlify dashboard or use the CLI:

npm i -g netlify-cli
netlify init
netlify env:set FORMS_WEBHOOK_URL https://hooks.example.com/your-endpoint
netlify deploy --build --prod

Check Netlify's docs for the current Next.js support, including how it handles src/proxy.ts, which the project uses for URL forms and 404s.

Cloudflare Workers

Cloudflare runs Next.js through the OpenNext adapter, @opennextjs/cloudflare. Install it and Wrangler:

npm install @opennextjs/cloudflare
npm install --save-dev wrangler

The adapter needs a Wrangler configuration file and an OpenNext config at the project root. These are new files you add; follow the adapter's getting-started guide for their current contents, including the Node.js compatibility flag. Then build and deploy:

npx opennextjs-cloudflare build
npx opennextjs-cloudflare deploy

Set form webhooks as secrets:

npx wrangler secret put FORMS_WEBHOOK_URL

Before relying on it in production, confirm in the adapter's docs that the version you install supports Next.js 16 and proxy.ts, and test every route, including unknown URLs that should return the 404 page.

Fly.io

Fly.io runs containers, so the project runs with next start exactly as it does locally. Add a Dockerfile at the project root (a new file):

FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-slim
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app ./
EXPOSE 3000
CMD ["npm", "start"]

Add a .dockerignore (also new) with node_modules, .next and .env*.local so local files don't end up in the image. Then:

fly launch        # creates the app and a fly.toml; use port 3000
fly secrets set FORMS_WEBHOOK_URL=https://hooks.example.com/your-endpoint
fly deploy

The same Dockerfile works on any container host or your own server.

Forms on serverless hosts

Each form posts to its own route, src/app/api/forms/<name>/route.ts, which uses src/lib/forms.ts for validation, a honeypot spam filter and a per-IP rate limit. That rate limit is kept in memory. On a single long-running server, such as one Fly.io machine, it behaves as one counter. On serverless platforms, where requests may be served by several instances, each instance keeps its own count. If spam becomes a problem, you can replace it with a shared store or your host's own protection.

After deploying, submit each form once on the live URL and confirm the webhook receives the JSON.

Domain switch checklist

Moving your domain from Framer to the new host is the step that affects visitors and search engines. Work through this before and after the DNS change.

1. Update metadataBase. The root layout, src/app/layout.tsx, sets it to the site's published URL. Change it to your production domain:

   export const metadata: Metadata = {
     metadataBase: new URL("https://www.example.com"),
     // …
   };

Canonical URLs and relative social images resolve against it. This matters even more if you included assets locally, because social images then become relative paths.

2. Update public/robots.txt and public/sitemap.xml. They're copied as the site publishes them, so they still name the old domain if it changed.
3. Check redirects. Redirects set in Framer's site settings are carried into next.config.ts with the same status codes, unless a notice says one wasn't carried over. Test a few.
4. Deploy and test on the host's preview URL. Check every route in the README's routes table at desktop, tablet and phone widths.
5. Add the domain on your new host and follow its DNS instructions. Then follow Framer's docs to disconnect the domain from your Framer project.
6. Re-test on the real domain: HTTPS, forms, canonical tags and social previews.
7. Resubmit your sitemap in Google Search Console. The SEO side of the move is covered in SEO when moving off Framer.

If you kept assets on Framer's CDN, images, fonts and videos still load from there after the move. To serve them from your own host instead, convert again with "Include assets locally" on; the trade-offs are in Framer fonts and assets, CDN vs. local.