DEV Community: Paweł Gałązka

Embracing TanStack Start for full-stack development on Cloudflare - PageZERO v2

Paweł Gałązka — Tue, 14 Jul 2026 10:22:13 +0000

If you have not run into PageZERO before, it is an open source, Cloudflare-native web app starter. You get auth, payments, permissions, email, blog, newsletter, a database layer, a tested CI/CD pipeline, and more, running on Cloudflare Workers and Cloudflare D1 database.

It requires Bun to be installed. Once you have it, start with one command:

bunx pagezero@latest init

That is the foundation. Today I want to talk about what changed in v2, the largest release since the project began, and TanStack Start is at the center of it.

From React Router v7 to TanStack Start

PageZERO v1 was built on React Router v7. Unfortunately, the strategic picture shifted. The core React Router team is focused on Remix 3, which is no longer React-based. Community momentum is fading, and betting the web app foundation on a framework moving away from React is a risk not worth taking. That's why PageZERO v2 swaps React Router v7 for TanStack Start.

The main difference in practice is that React Router's loaders and actions, which doubled
as ad hoc API endpoints, are replaced by TanStack Start's server functions.
React Router loaders fetch the data a route needs before it renders, while actions
handle mutations, like form submissions that create or update data.

React Router loader:

export async function loader({ context }: Route.LoaderArgs) {
  const db = context.get(dbContext)
  return { projects: await db.select().from(projectsTable) }
}

export default function ProjectsPage({ loaderData }: Route.ComponentProps) {
  return <ProjectsList projects={loaderData.projects} />
}

TanStack Start equivalent:

import { createServerFn } from "@tanstack/react-start"
import { createFileRoute } from "@tanstack/react-router"
import { getMainDb } from "@/db/main"

export const getProjects = createServerFn({ method: "GET" }).handler(async () => {
  const db = getMainDb()
  return { projects: await db.select().from(projectsTable) }
})

export const Route = createFileRoute("/projects")({
  loader: () => getProjects(),
  component: ProjectsPage,
})

React Router action:

export async function action({ request, context }: Route.ActionArgs) {
  const db = context.get(dbContext)
  const formData = await request.formData()
  const name = formData.get("name") as string
  await db.insert(projectsTable).values({ name })
  return redirect("/projects")
}

TanStack Start equivalent:

import { createServerFn } from "@tanstack/react-start"
import { getMainDb } from "@/db/main"

export const createProject = createServerFn({ method: "POST" })
  .validator((data: { name: string }) => data)
  .handler(async ({ data }) => {
    const db = getMainDb()
    await db.insert(projectsTable).values({ name: data.name })
  })

A few concrete wins fall out of that shift:

Simpler client-server communication. Server functions handle the request and response behind the scenes, so calling server code from the client feels like calling a regular function, no route or URL to define by hand.
End-to-end type safety. Return types and validated input flow straight from server function to caller, no Route.LoaderArgs or Route.ActionArgs generics to pass around.
One RPC layer for everything. rpc/ is now the single place callable server logic lives, instead of splitting it across page routes, resource routes, and ad hoc API endpoints.
Reusable by default. One server function can be called from multiple loaders, a beforeLoad guard, a form submission, or a client event handler, no more duplicating logic across a page route and a resource route just to reach it from two places.

TanStack Start and Cloudflare

TanStack Start runs on Cloudflare Workers without any adapter gymnastics (unlike Next.js). wrangler.json simply points its main entry at the framework's own server bundle:

{
  "main": "@tanstack/react-start/server-entry"
}

Wrangler builds that entry, hands it to a Worker, and server-side rendering just works: every
route renders on the edge, close to the user.

Like React Router before it, TanStack Start itself is just a Vite plugin, tanstackStart(), dropped into vite.config.ts alongside the Cloudflare plugin:

import { cloudflare } from "@cloudflare/vite-plugin"
import { tanstackStart } from "@tanstack/react-start/plugin/vite"
import react from "@vitejs/plugin-react"

plugins: [
  cloudflare({ viteEnvironment: { name: "ssr" } }),
  tanstackStart({
    ...
  }),
  react(),
]

That plugin also handles static prerendering: pages you mark for it are built to static HTML at deploy time and served straight from Cloudflare's CDN via the assets binding, bypassing the Worker entirely. Everything else keeps rendering on demand through the Worker. Same codebase, same routes, and the right pages are served from the CDN without a separate static site to maintain.

A simpler deployment to Cloudflare

v1 required manual work before a first deploy: create each D1 database with wrangler d1 create, paste the ID into wrangler.json, then run a bespoke db:setup chain. v2 drops that ceremony: Wrangler provisions D1 databases automatically on first deploy, and migrations run through wrangler d1 migrations apply instead of drizzle-kit migrate.

A first deploy now looks like this:

Log in to Cloudflare with bunx wrangler login.
Reset wrangler.json for your project with bun setup:wrangler.
Deploy with bun deploy:preview and bun deploy:production.
Apply migrations with bun db:migrate --env preview --remote and bun db:migrate --env production --remote.

Push-to-deploy through GitHub Actions still works the same way: every merge to main ships to production and every PR gets a preview environment, with migrations applied automatically per environment via the official cloudflare/wrangler-action.

A built-in blog

v2 ships a file-based blog out of the box. Posts live as .mdx files in apps/blog/content/. Drop one in and it shows up on the blog index automatically, served at /blog/<slug> with the slug derived from the filename. No route registration step. A minimal post looks like this:

import cover from "../assets/hello-cover.jpg"

export const frontmatter = {
  title: "Hello, world",
  description: "My first post.",
  date: "2026-06-01",
  imgSrc: cover,
  author: { name: "Jane Doe" },
}

Regular **Markdown** works here, alongside any JSX you need.

Each post exports a frontmatter object (title, description, date, cover image, author) that is validated with Zod at load time, so a missing field fails loudly at build instead of quietly producing a broken page. Posts get SEO meta tags from that frontmatter automatically, code blocks are syntax-highlighted, and the index is sorted newest-first. The post you are reading right now is, fittingly, just such an MDX file.

MDX static content

The blog is really one instance of a more general capability: MDX content compiled at build time into React components. Frontmatter is written as a JS export rather than YAML, which means a content file can import local image assets processed by Vite and reference live config values directly.

The same getMdxModuleBySlug helper and MDXProvider that power the blog route work for any content area. Here is a docs route built the same way:

import { createFileRoute, notFound } from "@tanstack/react-router"
import { getMdxModuleBySlug, MDXProvider } from "@/mdx"
import { docModules, docFrontmatterSchema } from "../content"

export const Route = createFileRoute("/docs/$slug")({
  component: DocPage,
})

function DocPage() {
  const { slug } = Route.useParams()
  const mod = getMdxModuleBySlug(docModules, docFrontmatterSchema, slug)
  const DocComponent = mod?.default
  if (!DocComponent) throw notFound()

  return (
    <MDXProvider>
      <DocComponent />
    </MDXProvider>
  )
}

v2 uses this for more than blogging. Legal pages moved to MDX files, and a shared ProseArticle layout handles any read-focused page. Adding a new content area follows the same shape as the docs route above: a content folder with an index.ts globbing its .mdx files, an index and detail route, both registered in apps/routes.ts. Static prerendering and sitemap generation are scaffolded in vite.config.ts and ready to switch on.

A newsletter with double opt-in

The new newsletter app adds a complete subscription flow powered by Resend. A subscriber enters their email in the ready-made NewsletterSignup component, receives a confirmation email, and is only added to your Resend audience after they click through. A proper double opt-in that keeps your list clean and compliant.

Drop the form into any route. When Cloudflare Turnstile is configured, load the public key in the route loader and pass it through, otherwise omit the prop and bot protection stays off:

import { NewsletterSignup } from "@/newsletter/components/newsletter-signup"

<NewsletterSignup
  cloudflareTurnstilePublicKey={cloudflareTurnstilePublicKey}
/>

The details are handled for you: confirmation links are signed and expire after 30 minutes, Cloudflare Turnstile bot protection is optional, and the contact lands in a configured audience segment on confirmation. The signup form is already embedded on the home page.

Type-safe forms

Building forms by hand is tedious and easy to get subtly wrong, so v2 introduces a small @/form package that ties together TanStack Start server functions, TanStack Query mutations, and Zod validation around one shared Zod schema. Rather than pulling in a full form-state library like TanStack Form, it stays deliberately thin: native FormData, a single hook, and a schema you already have.

Here is the client side of it, a form wired up with the useFormAction hook against a server function that validates incoming data with that same schema:

import { useFormAction } from "@/form"

function ContactForm() {
  const { onSubmit, fields, isPending } = useFormAction(
    contactFormSchema,
    contactFormAction,
  )

  return (
    <form onSubmit={onSubmit} noValidate>
      <input name={fields.email.name} type="email" />
      {fields.email.errors.map((err) => (
        <p key={err}>{err}</p>
      ))}
      <button type="submit" disabled={isPending}>
        {isPending ? "Sending..." : "Send"}
      </button>
    </form>
  )
}

useFormAction wraps the server function in a TanStack Query mutation and hands back an onSubmit plus typed fields with per-field validation errors, so you never manage individual input state by hand. The schema is the single source of truth, so field names, types, and error messages stay in sync. The newsletter signup is built on exactly this primitive.

Ready for horizontally scaling D1

Cloudflare D1 database is designed for horizontal scaling: many small, independent SQLite databases rather than one giant one. v1 didn't leave room for that, everything lived behind a single DB binding at packages/db/.

v2 renames it to DB_MAIN and moves it into its own packages/db/main/ folder with its own schema and migrations. That DB_<NAME> / packages/db/<name>/ convention is now the pattern to follow: adding a second database, e.g. DB_SECONDARY, means registering the binding in wrangler.json, adding a matching packages/db/secondary/ folder with a getSecondaryDb(), and reusing the existing scripts:

DB_BINDING=DB_SECONDARY bun run db:generate
DB_BINDING=DB_SECONDARY bun run db:migrate

The starter still ships with a single DB_MAIN by default, but the seams for splitting off a second one (per tenant, per domain, per region) are already there.

Getting started

If this is your first time hearing about PageZERO, everything above (TanStack Start, the blog, the newsletter, type-safe forms, MDX content, the simplified deployment flow, and the groundwork for multiple databases) ships out of the box the moment you generate a project. One command and you can start building your app on solid foundations:

bunx pagezero@latest init

For the full picture, check pagezero.dev.

Meet PageZERO: an open source SaaS starter kit on Cloudflare for the AI era

Paweł Gałązka — Thu, 04 Jun 2026 10:40:01 +0000

You have an idea for a SaaS. You open Cursor or Claude Code, and the familiar ritual begins. Auth. A database. Payments. Transactional email. Permissions. The agent generates it. You spend the weekend reviewing and patching, you burn $100 to $300 in tokens on the same foundational plumbing every serious project requires, and half of what comes back has subtle security holes or broken logic that only surfaces once a real user signs up. Welcome to AI slop.

Then comes the second surprise. The project grows, the free tier ends, and the infrastructure bill arrives. Egress fees on every byte that leaves the network. A managed database that costs money even while it sits idle overnight. Pricing that grows faster than expected.

PageZERO exists to remove both of those problems. It is an open source, full stack codebase that wires together everything a serious SaaS needs, with conventions an AI agent can actually follow, and it runs entirely on Cloudflare, so your infrastructure starts free and scales for pennies. This is the first real post on this blog, so let me introduce what it is and why it is built the way it is.

What PageZERO is: a SaaS starter kit you own

PageZERO is a complete starter codebase you own outright. Run one command:

bunx pagezero@latest init

You get a complete TypeScript project with authentication, payments, role based permissions, email, a database layer, UI components, testing, and a full CI/CD pipeline already connected and tested. You write product code on day one instead of glue code.

It is important to be precise about what PageZERO is not. It is not a framework and not a hosted service. There is no runtime dependency on PageZERO, no contract to honor, no upgrade treadmill. After the init command you have a normal repository. Keep what you need, delete what you do not, replace anything you disagree with. Every line is yours under the MIT license.

Why Cloudflare, and how it works

The most distinctive choice in PageZERO is that it is Cloudflare native from top to bottom. Most starters assume Vercel for hosting and a separate provider for the database. PageZERO instead uses one integrated platform, and that decision drives both the architecture and the economics.

Here are the parts of Cloudflare a PageZERO app uses:

Job	Cloudflare service	What it does
Compute	Workers	Runs server side rendering and API routes in 300+ cities, close to the user
Database	D1	A serverless SQLite database that lives at the edge next to your Workers
Static files	Assets	Serves JS, CSS, and images from the global CDN
Bot protection	Turnstile	Blocks form spam with an invisible challenge, no annoying CAPTCHA

Because compute and data sit in the same edge network, requests do not hop across regions to reach a distant database. Code runs in the data center nearest the visitor, and Workers have no cold starts, so there is no slow first request after a quiet period.

Free tier

	🟠 Cloudflare	▲ Vercel	☁️ AWS
Requests	3M/mo	1M/mo	Lambda: 1M/mo
Database	D1: 5 GB, 5M reads/day	Neon: 0.5 GB	RDS: 20 GB (12-mo trial)
KV Storage	1 GB, 100K reads/day	Upstash: 256 MB, 16K cmd/day	DynamoDB: 25 GB
Object Storage	R2: 10 GB	Blob: 1 GB	S3: 5 GB
Egress	$0	$0 (up to 100 GB)	$0 (up to 100 GB)

Paid tier

	🟠 Cloudflare	▲ Vercel	☁️ AWS
Base Price	$5/mo	$20/user/mo	Pay-as-you-go
Requests	10M/mo + $0.30/M	10M/mo + $2/M	$0.20/M requests
Database	D1: 5GB + $0.75/GB	Neon: $0.35/GB	RDS: ~$13/mo + $0.115/GB
KV Storage	$0.50/M reads, $5/M writes	Upstash: $2/M commands	$0.25/M reads, $1.25/M writes
Object Storage	R2: $0.015/GB/mo	Blob: $0.023/GB/mo	S3: $0.023/GB/mo
Egress	$0	1 TB/mo + $0.15/GB	1 TB/mo + $0.09/GB

Two numbers do most of the work here. Egress on Cloudflare is always $0, so a viral moment never turns into a four figure bandwidth bill. And the database does not charge you a flat fee just for existing, the way a managed Postgres instance does. Pay for what you use, scale gradually, no idle tax.

Built for the AI era

The way we write code has changed. AI agents like Cursor and Claude now write a large share of it. They are fast, but they struggle with architectural decisions and can quietly introduce security holes when they improvise on a generic template.

A well structured, open codebase is the fix. PageZERO ships with an AGENTS.md file that agents actually read. The moment an agent opens the project it understands the architecture, the conventions, and how to add a feature correctly. The module layout is predictable, every UI component follows the same four file pattern, and TypeScript is strict throughout, so an agent can reason about a function from its signature alone.

PageZERO also bundles agent skills under .agents/skills/. You can ask in plain language to scaffold a component, change the theme, open a pull request, or merge one, and the agent runs a structured workflow that follows the project conventions every time. You move fast with AI without trading away quality or security.

What comes wired together in the starter kit

Each capability lives in its own module under apps/, so you can keep it, remove it, or extend it:

Authentication. Passwordless login with a six digit one time password sent by email. No passwords to store, no third party auth service, sessions in secure httpOnly cookies, and optional bot protection through Turnstile.
Payments. One time purchases and subscriptions through Polar.sh, including checkout, webhooks, invoicing, and global tax compliance. A completed payment grants the matching role automatically, and a refund or cancellation revokes it.
Permissions. Simple role based access control backed by the database and config, wired directly to payment events.
Email. Resend integration with React Email and TailwindCSS templates, plus ready made templates for auth and access management.
Database. Drizzle ORM on Cloudflare D1 with type safe queries, automatic migrations, and separate databases for production and preview.
UI. 27 components built on Radix UI and TailwindCSS, accessible, documented in Storybook, with dark mode included.
Testing and delivery. Vitest, Playwright, and Storybook preconfigured, with push to deploy through GitHub Actions.

This is not a weekend project cranked out to win a feature count. It is engineered to last, with unit and end to end tests included, strict TypeScript throughout, and a CI/CD pipeline that runs on every push.

Why open source matters here

I made PageZERO fully open source because transparency is the strongest foundation you can build on. Most quality SaaS boilerplates are closed source and paywalled, so you rent someone else's architecture without ever seeing inside it. When every layer of your stack is open and community driven instead, you get the stability, security, and longevity that no proprietary shortcut can match. You can audit it, fork it, and trust it.

There is a practical angle too. Asking an AI agent to generate a codebase of this quality from scratch can cost anywhere from $100 to $300 in tokens on a frontier model like Claude Opus, and the result is usually worse. PageZERO gives you a better starting point for free.

Start building

If any of this resonates, the fastest way to understand PageZERO is to run it:

bunx pagezero@latest init

You only need Bun and Node.js. From there:

pagezero.dev - the project homepage with an overview of everything included
docs.pagezero.dev - comprehensive documentation covering setup, architecture, every module, and how to extend the kit
GitHub - the full source under MIT, read every line before you commit to it

Build your startup on solid foundations. Start free, scale for pennies, own every line.