Central Command: A Cloudflare-Native Personal Performance Dashboard

Project Overview

Central Command is a personal performance dashboard that pulls a scattered set of life-data sources — calendar, weather, fitness, nutrition, sleep, gaming, news, and tasks — into a single, fast, edge-rendered view. It is multi-user with Google sign-in, ships with a public read-only demo, and runs entirely on the Cloudflare developer platform on free tiers — no paid services anywhere in the stack.

It's a solo project: design, architecture, and implementation. This post is the case study behind it.

Why I Built This

I'm a zero-inbox kind of person, and the way I stay that way is by keeping the things that matter permanently in view. I run a secondary monitor that's always showing the apps I live in — a calendar, Slack, Linear — alongside a Stream Deck configured with the time across a few cities, notification counts, unread badges, and the like. It's an always-visible command center, and it's how I stay on top of everything without things quietly slipping.

Central Command grew out of wanting a single, all-in-one version of that setup. While reading through the Cloudflare developer platform, I realized I could hit two birds with one stone: scratch that itch and learn the platform end to end by building something real on it. Hence this app.

Goals

The brief was simple to state and interesting to build:

• Bring scattered personal data into one dashboard that loads fast from the edge
• Run the entire stack on free tiers — no paid services, ever
• Support multiple users with real auth, plus a public demo anyone can open without an account
• Surface insights from a user's own data without shipping that data to a third party

The Stack

Central Command is Cloudflare-native and edge-first. Every layer is something Cloudflare offers on its free tier:

• The API is a Hono app running on Cloudflare Workers — TypeScript end to end.
• Persistence is Cloudflare D1 (SQLite at the edge) accessed through Drizzle ORM, with Cloudflare KV for caching and rate limiting.
• External data sources are refreshed on a schedule with Cron Triggers, so the dashboard reads pre-warmed data instead of hitting third-party APIs on every request.
• The frontend is React + Vite with TanStack Router (compile-time typed routes) and TanStack Query, deployed on Cloudflare Pages.
• It's all one pnpm-workspaces + Turborepo monorepo, with types shared between the API and the web app so a schema change propagates to every caller in a single commit.

At a glance, the pieces fit together like this:

The Build (Seth)

Auth evolution as a deliberate story

The most interesting part of this build wasn't a feature — it was how authentication changed as the product's audience changed.

While Central Command was single-user, it sat behind Cloudflare Access (Zero Trust, Google SSO). That gave me real auth for free, with zero application code: Cloudflare handled the identity layer at the edge, and the app could assume every request was already me.

Opening it up for a public v1 meant the app itself had to own identity. I migrated to first-party Google OAuth (PKCE) with stateless, signed session cookies — no server-side session store to operate, which keeps it true to the free-tier, edge-first goal.

The risk in any auth migration is breaking production mid-flight. I shipped it deploy-safe: a temporary fallback let the app accept both the old Cloudflare Access identity and the new first-party session during the transition, so production never had a window where nobody could log in. Once the new path was verified, the fallback came out.

A public demo that exercises the real stack

A demo that's just a static mockup proves nothing. Central Command's public read-only demo is backed by a seeded user running through the actual API, database, and rendering path — so visitors see the real product. A server-side write guard rejects any mutation for the demo user, which means the live stack is exercised without exposing shared state or leaking third-party API keys.

Protecting free-tier quotas

Free tiers and third-party APIs both have limits, and a public app invites traffic. KV-backed rate limiting runs at two levels — per-user and global — so one noisy user can't exhaust a quota and the whole system stays inside its free-tier budget.

Insights without leaving the edge

The insights engine computes rule-based correlations and nudges (e.g. relationships between sleep and activity) from the user's own data, with zero external calls. No data leaves Cloudflare to generate them, which keeps both privacy and cost in check.

Key Features

• Unified dashboard — calendar, weather, fitness, nutrition, sleep, gaming, news, and tasks in one edge-rendered view
• Multi-user auth — first-party Google OAuth (PKCE) with stateless signed session cookies
• Public read-only demo — seeded sample data, no sign-in, real stack behind it
• Rule-based insights — correlations and nudges from your own data, no external calls
• Per-user + global rate limiting — KV-backed protection for free-tier and third-party quotas
• Type-safe end to end — strict TypeScript, compile-time-checked routing, shared API/web types in a Turborepo monorepo

Screenshots

The welcome page leads with the choice that matters: sign in, or open the demo with no account at all.

Inside, the dashboard is a single edge-rendered view — weather, the day's schedule, and a performance score up top:

…with calendar, tasks, health, gaming, the rule-based insights engine, and news filling out the grid below:

Where We Are Now

Central Command is live at centralcommand.studiosc.dev, public as v1, with a read-only demo open to anyone. It's a working proof that a genuinely useful, multi-user, edge-deployed product can run end to end on free tiers — if you architect for the edge from the start.