Reverse Proxy

The Challenge

Outside Inc. needed to modernize its web infrastructure while maintaining backward compatibility with legacy WordPress content. The goal was to serve three distinct applications—Headless Editorial (Next.js), Activity Feed (Next.js), and legacy WordPress articles—from a single domain per brand.

Key requirements included:

• Unified URL structure — Users should see consistent URLs regardless of which backend serves the content
• Centralized authentication — Single sign-on across all applications without third-party cookies
• Gradual migration — Route traffic to new headless pages incrementally without disruption
• Multi-tenant deployment — Support 21 different brand domains from shared infrastructure

Architecture

The reverse proxy acts as the front door for all brand traffic, making routing decisions based on URL patterns and content metadata:

                    www.backpacker.com/article-slug
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│                     Reverse Proxy                            │
│                                                              │
│  1. Check auth state (SSO cookies)                          │
│  2. Determine content type via API                          │
│  3. Route to appropriate backend                            │
└─────────────────────────────────────────────────────────────┘
        │                   │                   │
        │                   │                   │
  ┌─────┴─────┐       ┌─────┴─────┐       ┌─────┴─────┐
  │  /home    │       │ /article  │       │ /article  │
  │  /feed    │       │ (new)     │       │ (legacy)  │
  ▼           │       ▼           │       ▼           │
┌─────────────┐ │ ┌─────────────┐   │ ┌─────────────────┐
│  Activity   │ │ │  Headless   │   │ │    WordPress    │
│    Feed     │ │ │  Editorial  │   │ │    (Pantheon)   │
└─────────────┘   └─────────────┘     └─────────────────┘

Technical Approach

URL Rewriting with Next.js

The proxy uses Next.js rewrites for transparent routing. Static routes like /home and /feed/* are mapped to the Activity Feed application. For article routes, the proxy queries the GraphQL API to determine whether an article should be served from the headless application or legacy WordPress based on its displayType field.

Authentication Hub Integration

The proxy integrates the Auth Hub package to manage authentication across all backends. This handles the OAuth authorization code flow, token encryption/decryption for browser cookies, search bot detection, and WordPress content proxying with URL rewriting.

Multi-Tenant Configuration

Each brand deploys as a separate Vercel project with brand-specific environment variables defining the content host, headless host, and activity feed host. Deployment scripts manage rolling out changes across all 21 brand instances.

SST/AWS Deployment Option

For brands requiring custom infrastructure (like National Parks sites), an alternative deployment uses SST with AWS ECS and Cloudflare. This provides more control over the hosting environment while maintaining the same routing logic.

Key Features

Gradual Migration Support

The proxy enables incremental migration of content to the headless platform:

1. New article templates are built in Headless Editorial
2. Content editors flag articles for the new platform in WordPress
3. The proxy routes flagged articles to Headless Editorial automatically
4. Legacy articles continue serving from WordPress unchanged

Cache Control

Custom cache headers optimize CDN behavior. Pantheon cache headers are stripped and replaced with appropriate Vercel CDN cache control headers for optimal performance.

Killswitch

A safety mechanism allows quickly disabling headless routing via environment variable, immediately routing all articles back to WordPress if issues arise.

Outcomes

The reverse proxy architecture achieved:

• Seamless user experience — Users navigate between applications without noticing backend changes
• Zero-downtime migration — Content migrates gradually without service interruption
• Simplified authentication — SSO works across all applications and brands
• Operational flexibility — Traffic can be shifted between backends instantly

The system currently handles traffic for 21 brand domains, routing millions of requests daily to the appropriate backend services.