One of the more practically useful skills I've built up over the past year is getting comfortable with free-tier hosting platforms. Between Cloudflare Pages, Vercel, and Netlify, I've deployed most of the projects on this site for zero ongoing cost.
These are notes from actually using them, not from reading the documentation in isolation.
Netlify
Netlify was where I started. The experience for static sites -- pure HTML, CSS, JavaScript -- is about as frictionless as deployment gets. Connect a GitHub repository, tell it the build command and the output directory if you have one, and it deploys. Every push to the main branch triggers a new deployment automatically.
I use Netlify primarily for projects that don't need a server-side runtime. Anson's Drive runs on Netlify. For that kind of project, the free tier is generous and the deployment experience is clean.
The learning curve for static sites is minimal. The only thing that tripped me up early was the distinction between a site with no build step (just upload the files as-is) versus a site with a build process (run npm run build first, then serve the /dist or /public output). Once that's clear, configuration is straightforward.
One thing Netlify does well: deploy previews. Every pull request gets a unique preview URL so you can see what a change looks like before merging. Useful for catching things that look fine in local development but break in production.
Vercel
Vercel is where most of my backend-adjacent projects live now. The specific capability that matters: Vercel's Python serverless runtime lets you deploy Flask apps as serverless functions. KnowThem, Instant Dashboard, and The Algorithmic Handshake all run on Vercel.
The key mental model for serverless Python on Vercel: your application doesn't run as a persistent process. Each incoming request potentially starts a fresh environment. This means anything stored in server memory between requests disappears. State that needs to survive requests has to live somewhere external -- a database, a cookie, a cache service.
This is a different programming model from running a Flask app locally where the process is always running and memory persists. Understanding the difference is important before you deploy something and find that it works locally but behaves unexpectedly in production.
Once that mental model is in place, the Vercel deployment experience is smooth. The GitHub integration is good -- push to main, it deploys, you get a production URL. Environment variables are managed through the dashboard and injected at runtime. Build logs are clear when something goes wrong.
Vercel also provides preview deployments for branches, which means you can test a change in a production-like environment before it goes live.
Cloudflare Pages
Cloudflare Pages is similar to Netlify for static site deployment. The difference that matters is the network: Cloudflare's CDN is genuinely fast globally. For a client-facing site where load speed matters, that's a real advantage.
I used Cloudflare Pages for the Vadakkanady Builders site. The build-and-deploy flow is the same as the other platforms -- connect a repo, specify the build command and output directory, done.
Beyond hosting, Cloudflare has services that connect well with Pages projects. Cloudflare R2 is S3-compatible object storage with no egress fees, which I used for profile photo storage in KnowThem. Workers are edge functions if you need server-side logic without leaving the Cloudflare ecosystem. These aren't things you need on day one, but they're there when a project grows into them.
GitHub Actions
For the Vadakkanady Builders project, the build process was a custom Node.js script that needed to run before deployment. GitHub Actions handles this -- a YAML workflow file describes what should happen when code is pushed:
on:
push:
branches: [main]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm run build
- name: Deploy to Cloudflare Pages
uses: cloudflare/pages-action@v1
The YAML syntax is a bit awkward if you haven't used it before, and the feedback loop for debugging is slower than it should be (you have to push a commit to test a change). But for automating a build-deploy sequence that would otherwise be manual, it's the right tool.
A few things that apply everywhere
Environment variables: Never put secrets directly in code. Every platform has a dashboard for setting environment variables that are injected at build or runtime. Use them. This is especially important for API keys, database credentials, and OAuth secrets.
Understand what you're deploying: Static hosting serves files. Serverless hosting runs code. These are different things with different constraints and different failure modes. Knowing which one your project needs before you pick a platform saves time.
The free tiers are genuinely usable: Vercel's free tier includes enough serverless function invocations and build minutes for hobby projects to run indefinitely without hitting limits. Same for Netlify and Cloudflare Pages. The main constraint is build minutes per month, and for personal projects you'll rarely come close.
The combination of these platforms means you can ship things quickly, at no cost, with decent reliability and global distribution. That's a remarkably good situation to be in as someone building personal projects.
