Next.js Frontend on Vercel Backends on Azure
Joe Zeng, software engineer at Statsig, on using Docker
This shows how much of Statsig’s web surface could be treated as commodity infrastructure, while its real differentiation sits deeper in data pipelines, experiment logic, and internal control. A Next.js front end can slot neatly into Vercel’s fast default workflow, but Statsig still runs the heavier parts of its stack on Azure, AKS, Redis, MongoDB, Event Hub, and Databricks, where it needs portability, tuning, and ownership over how systems behave at scale.
-
For a Next.js app, Vercel bundles deploy previews, CDN delivery, serverless compute, routing, and API endpoints into one Git based path. That is why it feels easy to move a web app there, especially for small teams shipping quickly.
-
The trade off is control. Statsig points to bandwidth limits and less customizability, and other teams describe the same breakpoint, Vercel is great until a company needs special infrastructure tweaks, unusual backend setups, or tighter cost control at larger scale.
-
Statsig’s product is not just a website. Customers create feature gates and experiments, send event data through SDKs and integrations, and analyze impact on product metrics. That workflow depends on backend data collection and processing systems that fit Docker and Kubernetes better than a front end hosting product does.
The likely direction is a split architecture. More software companies will put the polished Next.js layer on platforms like Vercel, while keeping core stateful systems, data pipelines, and custom services on cloud infrastructure they control. As Vercel keeps pushing deeper into backend and edge capabilities, the boundary will move outward, but the highest value workloads will stay with teams that need full control.