The Deployment Journey: From GitHub Pages to Cloudflare and a $0 Bill

 

There's a wider gap than you'd expect between running code locally and putting it in front of the world. Deployment isn't just uploading files to a server. It's making architectural decisions about your infrastructure.

Deployment Options for Side Projects

Several platforms can host a frontend project: Vercel, Netlify, GitHub Pages, Cloudflare Pages. Each has distinct tradeoffs.

Vercel, built by the Next.js team, is optimized for React deployments. It offers serverless functions and automatic preview deployments. But the free tier restricts commercial use and has bandwidth limits.

Netlify occupies a similar niche. Build automation, serverless functions, form handling, lots of convenience features. The free tier is generous, but monthly build minutes are capped.

GitHub Pages is the simplest option. Push static files to a GitHub repository and you're done. No serverless functions, no built-in build automation (you configure GitHub Actions yourself). But it's completely free with almost no restrictions.

Why I Chose GitHub Pages

The short answer: three reasons.

First, it's completely free. The bandwidth cap of 100 GB per month is generous, and the 1 GB site size limit is more than enough. Side project traffic won't come close to either.

Second, simplicity. Push built static files to a specific branch and deployment is complete. No extra accounts, no platform-specific learning curve. I was already on GitHub, so zero additional tooling.

Third, it's sufficient for a React SPA. Tarot Master is a static site. There's no server-side logic; API calls are handled by Cloudflare Workers. When all you need is static file hosting, the advanced features of Vercel or Netlify are unnecessary overhead.

GitHub Pages has drawbacks. SPA routing requires a 404.html redirect trick, and build automation needs manual setup. But these were acceptable tradeoffs.

Cloudflare Workers: Home for the API

The frontend was handled by GitHub Pages, but I still needed a server for the AI interpretation API. As covered in Part 12, Cloudflare Workers fills that role.

The key advantage of Cloudflare Workers is edge computing. Code runs across hundreds of data centers worldwide, delivering fast responses regardless of user location. A visitor from South Korea hits a Seoul or Tokyo data center; someone from the US hits a nearby American data center.

The free tier's 100,000 daily requests is effectively unlimited for a side project. That's roughly 1.15 requests per second sustained over 24 hours. Even burst traffic of 100 requests per minute stays well within the daily total.

Deploying Workers code is also simple. A single Wrangler CLI command pushes to every edge location globally. Local development is just wrangler dev.

Designing the Build Pipeline

The heart of deployment automation is the build pipeline: a flow where pushing code triggers automatic building, validation, and deployment.

Tarot Master's build pipeline has four stages: typecheck, vite build, sitemap, prerender. Each runs in sequence, and any failure halts deployment.

Stage one is TypeScript type checking. It catches runtime errors before they reach production.

Stage two is the Vite build. TypeScript compiles to JavaScript with bundling and optimization. Code splitting, tree shaking, and asset hashing all happen here.

Stage three generates the sitemap. As covered in Part 13, the script extracts all URLs from the route configuration and produces sitemap.xml.

Stage four is pre-rendering. A headless browser renders the built static files and saves each page's complete HTML. Essential for SEO.

When all four stages succeed, the output deploys to GitHub Pages. GitHub Actions runs this pipeline automatically on every push to the main branch.

Custom Domain and HTTPS

GitHub Pages defaults to a username.github.io/repository URL. That works, but a custom domain gives the project its own identity.

I purchased a domain, set DNS A records pointing to GitHub Pages' IPs, and added a CNAME file to the repository. GitHub Pages automatically recognizes the custom domain.

HTTPS is provided automatically too. GitHub Pages issues and renews Let's Encrypt certificates with zero manual intervention. Free hosting with managed SSL is a significant win.

Anatomy of a $0 Bill

Here's the infrastructure cost breakdown.

Static hosting: GitHub Pages, free. API server: Cloudflare Workers, free. AI inference: Groq API (free tier) or Cloudflare Workers AI (free allocation), free. The only cost is an annual domain fee, and even that can be eliminated with a free domain.

Total server cost: zero. This is the reality of side projects in the 2020s. A decade ago, you'd need an AWS EC2 instance running around the clock, costing anywhere from a few to tens of dollars monthly. Today, combining free tiers lets you run a production-grade service without spending a cent.

The Limits and Tradeoffs of Free Infrastructure

There's no free lunch, of course. Free infrastructure has clear limitations.

GitHub Pages serves only static files. Server-side rendering, database connections, file uploads, none of these are possible. If you need dynamic features, you'll integrate additional services.

Cloudflare Workers' free tier caps CPU time at 10 milliseconds per request. Fine for simple request forwarding like an API proxy, but tight for heavy business logic.

There's also the anxiety about scaling. A sudden traffic spike could blow past free quotas and interrupt service. Having a paid upgrade plan ready is prudent.

But these are "good problems." Hitting the free tier's ceiling means the project is succeeding. Worrying about infrastructure costs for a project with no traffic is like agonizing over furniture placement before the house is built.

A side project's first goal is getting it out into the world. Infrastructure cost should never be the reason a project doesn't get started. Start free, invest as you grow.

What's Next

With deployment complete, Tarot Master was live. But the real challenge was just beginning. In Part 16, I cover converting the web app into a PWA, making it feel like a native app with offline support, home screen installation, and the surprising impact on return visits.