Putting Vercel’s edge network in front of Discourse
Vercel’s CDN doesn’t require your application to live on the platform. You can proxy an externally hosted service such as Discourse or WordPress through Vercel’s global network, layering on firewall protection, DDoS mitigation, and analytics without moving the app itself.
The Vercel Community forum is a live example. The Discourse instance runs on its own infrastructure, but all user traffic passes through Vercel’s CDN. That setup brings three useful tools to bear:
- Web Analytics: anonymized, cookie-free data on demographics and referrers, showing where visitors come from and what content they engage with.
- Firewall: DDoS protection that has automatically blocked multiple attacks over the past year.
- Bot Management: blocks malicious scrapers while permitting trusted crawlers — including ChatGPT indexing — to access community posts.
Parts of the community site, such as live sessions, are Next.js applications deployed directly on Vercel. Using Vercel Microfrontends, these apps are mounted on the same domain as the Discourse forum. That hybrid approach exists for three reasons:
- To build new page types that would be impractical as CMS plugins.
- To override Discourse pages that cannot be fully customized.
- To keep users authenticated through Sign in with Vercel.
When a new page is ready, adding its path to the microfrontends configuration reroutes users on the next deploy with no downtime.
CDN proxy setup: inner host and outer host
Proxying an external site through Vercel requires two domains:
- Inner host — the origin server where the site actually runs (for example,
your-site.discourse.com). - Outer host — the Vercel project domain that end users see (for example,
community.vercel.com).
All links and canonical URLs on the site must reference the outer domain. Then create a Vercel project that deploys to the outer host and use a vercel.ts configuration (formerly vercel.json) to rewrite traffic to the inner domain.
import { type VercelConfig, routes, deploymentEnv } from '@vercel/config/v1'
export const config: VercelConfig = {
rewrites: [
routes.rewrite('/(.*)', deploymentEnv('INNER_HOST'), {
requestHeaders: {
'x-proxy-secret': deploymentEnv('PROXY_HEADER')
}
}),
],
}
The inner host validates the x-proxy-secret header on every request, guaranteeing that the origin is unreachable except through the Vercel proxy.
Serving multiple apps on one domain
To extend the forum beyond Discourse’s limitations, the team used a vertical microfrontend approach on the outer domain. A microfrontends.json file maps specific route paths to separate Vercel projects, so different parts of the same domain are served by different applications.
{
"$schema": "https://openapi.vercel.sh/microfrontends.json",
"applications": {
"community-proxy": {
"development": {
"fallback": "community.vercel.com"
}
},
"community-nextjs": {
"routing": [
{
"paths": [
"/.well-known/workflow/:path*",
"/live/:path*"
]
}
]
}
}
}
Routing can be added incrementally, one path at a time. The configuration also includes a .well-known/workflow route, which uses the Workflow Development Kit for event creation and video processing.
An alternative would be negative matching in a proxy regex to exclude certain routes from being forwarded. But splitting projects offers cleaner isolation: independent environment variables, separate organization-level permissions, and lockdown of the project that communicates with the third-party host.
Modern protections, incremental migration
With the CDN between users and origin, all traffic flows through Vercel’s edge network. Enterprise-grade security applies to your existing stack, with no application changes required.
Pairing the CDN proxy with microfrontends opens up an incremental modernization path. Rather than a full “big bang” rewrite, you can build a Next.js application, turn on specific routes one by one, and keep the legacy platform (Discourse, WordPress, or otherwise) running underneath. The Vercel Community site demonstrates the full architecture in production.



