Static Next.js + Cloudflare Pages + Pulumi

Launch a sharper SaaS landing at the edge.

CloudFare Landing is now shaped as a premium dark launch system: static-first architecture, deployment clarity, rich product storytelling, and motion that makes the page feel alive without slowing it down.

  • Static export
  • Cloudflare Pages
  • Pulumi managed
  • SEO ready
Optimized static delivery
Implementation-ready infrastructure
Clear path to custom domains

Performance posture

Pre-rendered pages, explicit infrastructure, and a quiet runtime.

The page reads like a real product launch while preserving the simple production model that makes static Cloudflare delivery so dependable.

Fast by default

Pre-rendered HTML, minimal client JavaScript, and Cloudflare edge delivery keep the first visit sharp.

SEO-first structure

Semantic sections, metadata, sitemap, robots rules, and indexable copy are included from the first build.

Cloudflare only

The deployment path stays focused on Pages and Direct Upload, without AWS or GCP abstractions.

What is scaffolded

A richer launch surface without SaaS-platform baggage.

Dense enough to feel production-ready, restrained enough to stay fast, and organized so the next product story has somewhere clean to grow.

Static Next export

Uses Next.js with output export so the production artifact is a simple static site in the out directory.

Small surface area

No auth, database, backend API, or admin surface in v1, which keeps the security and maintenance footprint low.

Conversion layout

A complete landing page flow with hero, proof, feature depth, FAQ, and final call to action.

Explicit config

Cloudflare account, API token, Pages project, and optional custom domain are documented instead of hidden.

Domain ready

Pulumi can attach a custom Pages domain when you are ready to connect a production hostname.

Lean design system

Reusable sections and card patterns give the page polish without introducing a heavy component framework.

A static-first launch path is exactly what small SaaS teams need: fewer moving pieces, faster pages, and infrastructure that remains visible.

Product engineering baseline

Launch readiness

Build checklist

  • Next static export configured
  • Pulumi-backed deploy command included
  • Pulumi Cloudflare Pages project included
  • Metadata, robots, and sitemap generated
  • Responsive sections for desktop and mobile

Cloudflare path

Pulumi shapes the Pages project. Wrangler ships the static output.

Infrastructure ownership remains visible, while the release path stays operationally simple: build assets, preview changes, upload to the edge.

  1. 01Run the Pulumi Cloudflare setup once to save stack config.
  2. 02Run Pulumi preview when you want to inspect infrastructure changes.
  3. 03Run pulumi:up to build, update Cloudflare Pages, and upload out/.

FAQ

Decisions made for this static launch.

Why use static export instead of SSR?

This project is a marketing landing page, so prebuilt static HTML is faster, cheaper to host, simpler to cache, and easier to deploy on Cloudflare Pages.

Can this later become a full SaaS app?

Yes, but the first version intentionally avoids auth, backend routes, and database choices. Add those only when product requirements justify them.

Does Pulumi deploy the files?

Pulumi manages the Pages project and optional domain. The project deploy command then uploads the static files with Wrangler Direct Upload after the Next build.

Can I switch Direct Upload to Git integration?

Cloudflare does not allow switching a Direct Upload Pages project to Git integration later. Create a new Pages project if you want that model.

Ready for the edge

Build once, upload static assets, and keep the launch path beautifully boring.

Back to top