SYS_01: Bypassing the Bloat—Why I Built My Own CMS with Next.js, Cloudflare R2, and Turso

The Fatigue of "Standard" Architectures

We live in an era of unprecedented framework maturity, yet our content management systems feel stuck in a loop of legacy design patterns. Whether you look at monoliths like WordPress or heavily decoupled modern Headless platforms, the status quo presents a frustrating trade-off: you either inherit an absurd mountain of bloated database queries, plugins, and security surface areas, or you lock yourself into expensive proprietary APIs just to render static markdown.

When I set out to build my personal writing workspace, I had a strict checklist:

• Absolute Minimalist Execution: Zero runtime bloat, zero dependencies I didn't explicitly inspect, and distraction-free data layers.

• Bulletproof Passwordless Authentication: Native WebAuthn/Passkey infrastructure so I never have to rotate, remember, or compromise security keys.

• Global, Edge-First Architecture: Computing and database reads sitting as close to the reader as mathematically possible, with zero egress fees for media assets.

The math didn't add up for any existing tool on GitHub. So, I opened a terminal and engineered a bespoke CMS from bare metal. This is how the stack works.

The Blueprint: A Serverless & Edge-First Topography

To keep operations lightning-fast and cost-effective, the infrastructure leverages an asymmetric, serverless architecture where Next.js acts as the centralized engine coordinating two highly specialized data planes.

Next.js App Router (The Core Engine)

Instead of running a traditional long-lived server process, the entire application executes inside serverless environments.

• Public Layer: Uses Incremental Static Regeneration (ISR). Public posts are prerendered as raw, optimized HTML at the edge. When a reader hits a URL, the response latency is practically single-digit milliseconds.

• Admin Dashboard: Powered by Server Components and native client-side hydration, leveraging dynamic route segment configurations to ensure administrative portals are never statically cached.

Turso & Drizzle (The Telemetry & Data Layer)

Traditional relational databases (PostgreSQL, MySQL) are notoriously heavy for serverless deployments due to connection pooling overhead. I selected Turso, a distributed database built on libsql (an open-source fork of SQLite).

Through Drizzle ORM, database interactions are fully type-safe. Turso allows the database to scale globally, pushing read-replicas directly to edge locations, turning complex relational queries into rapid local disk reads.

Cloudflare R2 (The Zero-Egress Media Store)

A modern CMS requires cover images, embedded tech diagrams, and rich media. AWS S3 has long been the default choice, but its egress fees (bandwidth charges for downloading files) are a predatory tax on independent creators.

Cloudflare R2 solves this natively. It is fully S3-compatible, meaning standard AWS SDKs or S3 clients drop right in, but it charges zero egress fees. The CMS uploads assets via pre-signed URLs directly from the dashboard to the global bucket, bypassing any intermediary server processing.

Deep Dive: State Transitions & Crystalline Business Logic

One of the most satisfying elements of building your own engine is writing the strict business logic that off-the-shelf tools abstract away with generic, fragile event listeners.

Take, for example, the lifecycle of a post moving between a draft and a publish state. In a naive implementation, updating a post might accidentally overwrite structural data or corrupt historical SEO parameters.

Inside the data mutation layer, the state machine enforces immutability on historical telemetry. When a post is updated via the administrative control plane, the system runs a strict state transition delta check:

// excerpt from the core mutation engine
const intent = formData.get("intent") as "draft" | "publish" | null;
const willBePublished = intent ? intent === "publish" : existing.published;

updateData.published = willBePublished;

if (willBePublished) {
  // Respect historical SEO parameters: do not overwrite the original publication timestamp
  updateData.publishedAt = existing.publishedAt ?? new Date();
} else {
  // Reverting to draft cleanly voids the temporal state
  updateData.publishedAt = null;
}

This ensures that if I enter a post published three months ago to fix a spelling error, the engine updates the raw text but safeguards the original publishedAt timestamp. However, if I explicitly trigger a fallback to a draft intent, the system cleanly flags it for removal from public edge feeds.

Architectural Edge Case: The Hybrid Passkey Strategy

Authentication in a modern web app shouldn't rely on standard user/password forms that are vulnerable to credential stuffing. However, hardlocking a CMS to WebAuthn introduces an engineering paradox: How do you access your system when deploying on dynamic preview infrastructures?

When Next.js builds preview environments on Vercel, it generates isolated, dynamic subdomains (e.g., project-git-branch.vercel.app). Because the WebAuthn standard mandates a strict Relying Party ID (rp.id), a passkey registered under localhost or your production domain will be rejected instantly by the browser agent.

To bypass this without writing messy environment configurations, the authentication plane operates on a dynamic, runtime-evaluated hybrid architecture.

// Dynamically resolving the Relying Party ID at the server runtime
const getWebAuthnDomain = () => {
  if (process.env.VERCEL_ENV === "production") {
    return process.env.VERCEL_PROJECT_PRODUCTION_URL;
  }
  if (process.env.VERCEL_ENV === "preview" && process.env.VERCEL_URL) {
    return process.env.VERCEL_URL; // Adapt seamlessly to dynamic preview branches
  }
  return "localhost";
};

When writing from my main machine on production, the client initializes a passwordless session with a single hardware cryptographic key exchange. But if I am debugging an experimental branch on a random preview deployment, the UI smoothly activates a secure database fallback.

Instead of parsing raw strings via server channels, the system passes native React client states directly through the auth client core. This executes secure client-side pre-hashing before any payload transits the network, establishing a fully uncompromised, parallel gate to the database layer.

Summary & Telemetry Insights

Reengineering a CMS from the ground up wasn't about avoiding existing open-source libraries; it was an exercise in extreme optimization and control. By eliminating the layered abstractions inherent in generalized platforms, the platform achieves near-zero cold-start overhead and deterministic rendering states.

The operational metrics speak for themselves:

• Time to First Byte (TTFB): Single-digit milliseconds at global edge points due to raw HTML caching via ISR.

• Database Overhead: Minimal connection lifecycles over HTTP with Turso, turning complex lookups into highly predictable relational disk evaluations.

• Storage Sustainability: Absolute zero dollar cost in egress data transfer fees, handing off media streaming entirely to Cloudflare’s global network.

A CMS should be an invisible pipeline between an idea and the browser. By stripping the bloat and compiling exactly what is needed, the workspace becomes exactly what it was meant to be: a crystalline, permanent enclave for high-level engineering thoughts.