Run your Framer marketing site and your app on one domain

There are four ways to run a Framer marketing site and your web app on one domain. The simplest is a subdomain: the site stays on example.com and the app lives on app.example.com. If you want the app under a path such as example.com/app, you need something routing requests by path: a reverse proxy in front of Framer, Next.js multi-zones with the site converted to code, or the converted site merged into the app's own Next.js project. Which one fits depends on who edits the marketing pages and how tightly the two need to share things like navigation and sign-in state.

Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer. Converting is for sites you own or have the owner's permission to convert.

The four options

Option 1: a subdomain for the app

Keep Framer on the apex and www, and point app.example.com at wherever your app is hosted. It's two DNS records and no shared infrastructure.

It suits most products. The trade-offs:

• SEO. Search engines treat subdomains as related but separate sites. That rarely matters for an app behind a login, which you don't want indexed anyway.
• Cookies. If the marketing site should know the visitor is signed in (to switch "Sign in" to "Open app"), set the auth cookie on .example.com, or have the marketing page call a small endpoint on the app.
• Docs and blog. If you want those on paths of the main domain for SEO, a subdomain for the app doesn't block that.

If this is enough for you, stop here.

Option 2: a reverse proxy in front of Framer

You can keep editing in Framer and still serve your app under a path, by putting a proxy in front of both. The proxy owns the domain, sends /app/* to your app and everything else to the Framer site.

Common places to do this are a Cloudflare Worker, a Vercel or Netlify project with rewrites, or nginx. The idea, in nginx terms:

location /app/ {
  proxy_pass https://my-app.internal.example/;
}
location / {
  proxy_pass https://my-site.framer.website;
  proxy_set_header Host my-site.framer.website;
}

Things to check if you go this way:

• Framer must serve the site at an address the proxy can reach, and you're relying on Framer's hosting behaving well behind a proxy. Read Framer's current docs and terms on proxying before relying on it.
• Canonical URLs, sitemaps and absolute links in the Framer site name the Framer-connected domain. Make sure they name the public one.
• You now run a proxy in the request path of your whole marketing site.

Can you host a Framer site elsewhere discusses proxies in more depth.

Option 3: Next.js multi-zones

Multi-zones is Next.js's pattern for serving several Next.js apps on one domain. Each "zone" is a separate project and deployment; one of them rewrites the paths it doesn't own to the others.

With the marketing site converted to a Next.js project, it becomes the main zone on /, and the app is a second zone on /app:

1. In the app, set basePath: "/app" in its next.config.ts, so all its routes and assets live under /app.
2. In the converted site, add a rewrite in next.config.ts that forwards /app and /app/:path* to the app's deployment:

async rewrites() {
  return [
    { source: "/app", destination: "https://my-app.example-host.app/app" },
    { source: "/app/:path*", destination: "https://my-app.example-host.app/app/:path*" },
  ];
},

3. Deploy both. Point the domain at the converted site.

Links between zones are full page loads, not client-side navigations: use a plain <a> for links from the marketing pages into the app.

The converted project also has src/proxy.ts, which applies the site's URL forms (trailing slashes, locales) and returns its 404 page for unknown paths. Check that /app requests reach the rewrite instead of the 404: if they don't, make the proxy skip paths that start with /app. Read the current Next.js docs on multi-zones for the version in your project, as details have moved between releases.

Multi-zones keeps the two codebases and deploys independent. Marketing can ship without touching the app.

Option 4: merge the converted site into your app

If your app is already a Next.js App Router project, you can bring the converted marketing pages into it, so one project serves everything. This gives you shared layout, shared components, one deploy and no rewrites, at the cost of mixing marketing and app code.

The converted project is laid out to make this manageable:

Then fix imports. The converted code imports the kit as @/deframer and uses @/ paths into src/, so update tsconfig.json path aliases in your app to match, or rewrite imports. Route groups ((marketing), (app)) let each side have its own root layout.

Work on a branch, move one page first, and get it rendering identically before you move the rest. What you get in a converted Next.js project explains each folder, and an AI coding tool is good at the mechanical import rewriting; see editing a Framer site with Cursor or Claude Code.

The trade-off nobody mentions: who edits the marketing site?

Options 3 and 4 mean the marketing site is code. Designers and marketers who edited in Framer now need a different path:

• Keep designing in Framer and convert again after big changes, then merge the new output in Git (maintaining a converted site with Git). Converting again is free; each new download uses a credit, or nothing with the lifetime deal (pricing).
• Move content to a CMS so text and blog posts change without a developer (adding a headless CMS).
• Use preview deployments so a designer approves each change before it ships (preview deployments).

If the marketing team needs to publish several times a day without engineering, Option 1 or 2 keeps that workflow.

How to choose

1. App behind login, no need for shared paths: subdomain.
2. Must be one origin, and the team keeps designing in Framer: reverse proxy.
3. Must be one origin, and you want the marketing site as code but separately deployed: multi-zones.
4. You want one codebase, shared components and a single deploy: merge.