Free Hosting for Side Projects: What's Actually Free in 2026

You've built your side project. Now where do you host it without spending money? This guide covers the realistic options, and is blunt about the ones that stopped being free.

All limits below were re-checked against the providers' own pricing and docs pages on 6 August 2026. That date matters more than it used to. Since the 2025 edition of this guide, Fly.io stopped offering plans to new customers entirely, Netlify replaced bandwidth and build minutes with a credit system, and Railway's free allowance shrank to a fifth of what it was. Free tiers are marketing budgets, and marketing budgets get cut. Check the pricing page yourself before you commit an evening to a deploy.

---

Quick Comparison

The "commercial use" column is new, and it is the one most guides skip. Two of the most-recommended free hosts forbid you from earning money on them. More on that below.

On the Oracle row: it is the only entry here that gives you a genuinely always-on VM with a real database for $0, which is why it belongs in a guide about free hosting even though it is infrastructure rather than a PaaS. The catch is significant enough that it needs its own treatment: Oracle reclaims Always Free compute instances when, over any 7-day window, 95th-percentile CPU, network and (on Arm shapes) memory all sit under 20% - which is the exact profile of a quiet side project. The PaaS guide covers the reclamation rule in full, and that section is the one to read before you build on it.

---

Full-Stack App Hosting

This is the category that changed the most. There is no longer a host that will run a small always-on web app with a database for $0/month. Render comes closest if you can live with your app sleeping. Everything else is now a paid product with a free evaluation period attached.

Railway

Best for: Rails, Django, Node.js, Go apps where you value the deploy experience enough to pay a few dollars for it

Railway is still the easiest way to deploy a full-stack app. Push your code, and it figures out the rest. What it is not, any more, is free.

Railway killed its free plan in 2023 and brought back a much smaller one on 27 August 2025. There are now three separate things that people confuse with each other:

1. The Free Trial - a one-time $5 in credit that expires after 30 days or when you spend it, whichever comes first. No credit card required. Maximum 5 services per project. Note that Railway deletes volumes created by trial accounts 30 days after the credits expire, so anything you stored during the trial is on a clock. (Railway's own two docs pages disagree on the trial's per-service RAM ceiling - one says 1 GB, the other 2 GB - so don't plan around a specific number.)

2. The Free plan - what you drop to when the trial ends. $0/month with $1 of usage credit per month, which does not roll over. Per-service caps: 0.5 GB RAM, 1 vCPU, 1 GB ephemeral storage, 0.5 GB volume storage, 1 replica, 4 GB image.

3. Usage rates, which is how that $1 gets spent: $10/GB RAM/month, $20/vCPU/month, $0.15/GB volume/month, $0.05/GB egress.

Do the arithmetic that matters. At $10/GB RAM/month, a 0.5 GB service left running costs about $5/month, so $1 buys roughly six days of always-on uptime. That figure is my estimate from Railway's published rates - Railway does not publish an hours number, so treat it as an order of magnitude, not a promise. The practical read: the Free plan runs a small service that is not always on, and nothing more.

What happens when the credit runs out matters, and it is not "sleeping." Your services stop and stay stopped until the credit refreshes next month or you upgrade. They do not wake on the next request. Railway's actual App Sleeping / Serverless feature - the one that does wake on request - is available on Pro and auto-pay Hobby only, not on Free.

Pros:
- Zero configuration for most frameworks
- One-click database setup
- Genuinely excellent UI and developer experience
- Nixpacks auto-detects your stack

Cons:
- $1/month is not a hosting plan, it is a sample
- Services stop dead when credits run out; no wake-on-request on Free
- Whether the ongoing Free plan requires a card on file is not documented either way - the "no credit card required" line on Railway's pricing page is attached specifically to the Free Trial. Check before you rely on it.

Deploy a Rails app:

# Install Railway CLI
npm install -g @railway/cli

# Login and deploy
railway login
railway init
railway up

Tips:
- Use railway run rails db:migrate for migrations
- Set RAILS_ENV=production in variables
- Add Procfile for custom start commands
- Use the $5 trial as what it is: 30 days to decide whether Railway is worth paying for

---

Render

Best for: the closest thing left to free full-stack hosting, if your app can sleep

Render still has real free instance types for web services, static sites, Postgres and Key Value. It is now my default recommendation for a hobby app that nobody is paying for.

Free Tier:
- 750 free instance hours per workspace per calendar month - per workspace, not per service, so two free services running full-time will not fit. Time spent spun down does not consume hours.
- Free web service instance: 512 MB RAM, 0.1 CPU
- Static sites
- Free Postgres: expires 30 days after creation (one per workspace, 1 GB storage, 256 MB RAM, 0.1 CPU, 100 connections)
- Free Key Value (Redis-compatible): one per workspace, 25 MB, 50 connections, in-memory only
- Free Hobby workspace also includes 5 GB outbound bandwidth, 500 build pipeline minutes, 2 custom domains, 1 seat, 25 services

The 30-day Postgres expiry is the single most important correction in this guide. The previous edition said 90 days. It has been 30 days since May 2024. You get a 14-day grace period after expiry to upgrade to a paid instance, and then the database is deleted. If you took the old advice and set a reminder for day 85, your data is already gone.

Two other limits worth knowing before you build on them: free Postgres is capped at 1 GB, and free Key Value is in-memory only - every restart wipes it, so it is a cache and nothing else. Never put sessions or job queues you care about in it.

Sleep behaviour: free web services spin down after 15 minutes with no inbound traffic and take about a minute to come back, showing a loading page in the meantime. Any changes your app made to the local filesystem are lost on spin-down.

Bandwidth and workspace plans changed on 23 April 2026, and every legacy workspace was auto-converted on 1 August 2026. The free Hobby workspace now includes only 5 GB of outbound bandwidth ($0.15/GB after that), 2 custom domains ($0.25/month each after that), and 25 services. If you had a Render account before April, your allowances changed last week.

Card requirements: none to deploy free services. A payment method only becomes necessary if you exceed included bandwidth - and if you have no card on file, Render suspends your free services for the rest of the month rather than billing you. That is the failure mode to design around.

Pros:
- A real free tier that is still a real free tier
- Sleeping is honest sleeping: it wakes on the next request
- Built-in cron jobs and preview environments

Cons:
- 15-minute spin-down, ~1 minute cold start
- Free database is a 30-day trial in disguise
- 5 GB bandwidth is not much if anything you build gets attention

Deploy from GitHub:
1. Connect GitHub repo
2. Select "Web Service"
3. Choose the free instance type
4. Set environment variables
5. Deploy

Tips:
- Do not ping your app to keep it awake. Spun-down time does not consume your 750 hours; keeping a single service awake 24/7 will use roughly 730 of them, so an uptime pinger is precisely what makes a single always-on app run out and get suspended. Let it sleep and accept the cold start.
- Put a reminder in your calendar for day 25 of your free Postgres instance, not day 85. Either upgrade or pg_dump it out.
- Treat the free Key Value store as a cache you can lose at any moment.
- Use background workers for heavy tasks.

---

Fly.io

Best for: global distribution, if you are willing to pay for it - which you now are

Fly.io no longer offers a free tier. Fly's own pricing docs state that it "no longer offers plans to new customers." Plans were deprecated on 7 October 2024 and are honoured only for organisations that were already on them. The 3 shared-cpu-1x VMs and 3 GB of volume storage that this guide used to list are legacy allowances for deprecated Hobby/Launch/Scale organisations. If you sign up today, you get none of it. The old $5 trial credit was tied to the discontinued $5/month Hobby plan and is not available to new signups either.

What it costs instead (pay-as-you-go from the first machine):
- shared-cpu-1x with 256 MB RAM: about $2.02/month (region-dependent; that is the Amsterdam figure)
- Volumes: $0.15/GB/month of provisioned capacity, whether you use it or not
- Outbound transfer: $0.02/GB to the public internet in North America and Europe
- Shared IPv4: free. Dedicated IPv4: $2/month

One correction to the previous edition while we are here: the 160 GB of included bandwidth it quoted was never right. The legacy allowance was 100 GB for North America and Europe, and 30 GB elsewhere.

Card required. Fly requires an active credit card on file for most accounts to do things like deploying multiple apps and deploying public images. The only alternative is prepaying a minimum of $25 in credits.

So: a minimal hobby app on Fly is roughly $2/month plus storage and egress. That is cheap, and for a globally-distributed app it is genuinely good value - but it is not free, and it is worth saying plainly rather than burying in a caveat.

Pros:
- Deploy to multiple regions easily
- Docker-based, so it runs anything
- WebSocket support, managed Postgres and Redis

Cons:
- No free tier at all
- Requires Docker knowledge and more setup than Railway or Render
- Volume charges accrue on provisioned size, not usage

Deploy with Fly:

# Install Fly CLI
curl -L https://fly.io/install.sh | sh

# Launch your app
fly launch

# Deploy
fly deploy

Tips:
- Use fly.toml to configure regions
- Use Machine auto-stop/auto-start (not fly scale count 0) to scale to zero between requests. This zeroes your compute charges, but a stopped Machine still bills $0.15/GB/month for its root filesystem - idle is cheap, never free.
- Provision volumes small. You pay for the size you asked for.

---

Frontend & Static Sites

Vercel

Best for: Next.js side projects that will never make money

Vercel still offers the best frontend deploy experience, and the Hobby plan is still generous. There are two things you need to know that most guides get wrong.

Free Tier (Hobby):
- 1,000,000 edge requests/month, 1,000,000 function invocations/month
- 4 CPU-hours of active CPU, 360 GB-hours of provisioned memory
- 5,000 image transformations, 300,000 image cache reads, 100,000 writes
- Web Analytics: 50,000 events/month, 1 month retention. Speed Insights: 10,000 events, 1 project
- 200 projects, 100 deployments/day, 50 domains per project
- Build resources: 2 vCPUs, 8 GB memory, 32 GB disk. Runtime logs retained 1 hour
- Function max duration: 300 seconds (5 minutes)

Correction 1: the 10-second function limit is gone. Hobby functions now run up to 300 seconds. The previous edition of this guide used that 10-second ceiling as a reason to push long-running work to Railway or Render. That reason no longer holds - Vercel serverless functions can now do real work.

Correction 2: "100 GB bandwidth" is no longer a plan entitlement. Vercel moved bandwidth out of the plan table and into its Fair Use Guidelines, where it reads as an expectation rather than an allowance: up to 100 GB/month of Fast Data Transfer and up to 10 GB/month of Fast Origin Transfer. That second figure is the one that actually bites, because uncached responses and image-heavy sites hit it long before the 100 GB. Do not plan around "100 GB free."

Correction 3: deployment history is now capped at 30 days on Hobby. Announced 2026-04-27, effective 2026-04-29. This affects how far back you can roll a deployment, not whether your app runs - so it is a smaller deal than the two corrections above, but it is worth knowing before you assume last quarter's build is still there to roll back to.

Commercial use is prohibited, and the definition is broader than you think. Vercel's fair-use page counts as commercial usage: asking for donations, any method of requesting or processing payment, ads including AdSense, sites whose primary purpose is affiliate links, and receiving payment to create, update, or host the site. That last one means a freelancer building a client's brochure site is in violation. If your side project has any path to revenue - even a "buy me a coffee" button - Hobby is the wrong plan and Cloudflare Pages is the free alternative that permits it.

When you exceed a limit, the general behaviour is that the feature stops working and you wait 30 days before it works again (Web Analytics resumes after 7 days).

Card: Vercel's docs never state it explicitly, but card details are only collected in the upgrade-to-Pro flow, so Hobby appears not to require one. Treat that as an inference, not a guarantee.

Deploy:

npm install -g vercel
vercel

Tips:
- Use ISR for dynamic content, and cache aggressively - Fast Origin Transfer is the tight constraint
- Connect to external databases (Supabase, Neon) since there is no persistent storage
- If money is anywhere in your plan, use Cloudflare Pages instead

---

Netlify

Best for: forms, and honestly not much else on the free plan any more

This is the biggest change in the guide, and it changes the recommendation, not just the numbers.

For any account created on or after 4 September 2025, Netlify Free is credit-based. You get 300 credits per month. Hard limit. No rollover, no auto-recharge, and no option to buy more credits on the Free plan.

Current credit rates, after the 14 April 2026 update:

Now the arithmetic your future self will wish you had done. 300 credits spent purely on bandwidth is 15 GB. Spend nothing on bandwidth and it is 20 production deploys. A realistic small site doing 15 production deploys in a month burns 225 credits and has 75 left - 3.75 GB of bandwidth. That is roughly a twenty-fifth of the 100 GB the old free plan gave you.

And when the credits run out, Netlify does not throttle or bill you. Every project on the account is paused and visitors get a "Site not available" page for the rest of the calendar month. The old failure mode was "builds stop working." The new one is "your site goes dark."

Other Free limits: 1 team owner and no additional members, 1 concurrent build, 500 projects, 1 live preview server, Netlify Database limited to 3 databases / 20 active branches / 7-day backup retention, analytics for the current and previous day only. No credit card required. Deploy previews and branch deploys cost nothing - only successful production deploys are charged, which is a genuinely nice design.

The legacy-account trap: accounts created before 4 September 2025 are "Legacy" and keep the old 100 GB bandwidth / 300 build minutes / 125K function invocation limits. Legacy accounts can move to credit plans but cannot move back. So if you have an old Netlify account, none of the above applies to you, and you will be convinced this section is wrong. It is correct for anyone signing up today.

What got better: form submissions are now free rather than capped at 100/month, and Netlify Identity survived its planned deprecation - Netlify reversed the decision in February 2026, so it is still an available auth option. (That reversal is documented on Netlify's community forum rather than in the main docs, and I did not re-verify the current Identity user limits, so check them before building on it.)

Recommendation change: Netlify Free is no longer a general-purpose static host. It is a trial-sized tier that happens to have excellent free forms. Pick it when Netlify Forms is specifically what you want, be aware of the ceiling, and put anything high-traffic on Cloudflare Pages.

Deploy with drag and drop:
1. Go to app.netlify.com
2. Drag your dist or build folder
3. Done

Tips:
- Batch your changes. Every production deploy is 15 credits, and deploy previews are free - iterate on previews.
- Use netlify.toml for configuration

---

Cloudflare Pages

Best for: almost every static site, and increasingly the default answer

Everything this guide said about Cloudflare Pages a year ago still checks out, and because most of the alternatives got worse, its relative position improved without it doing anything.

Free Tier:
- Unlimited bandwidth and unlimited requests to static assets - Cloudflare's Workers pricing docs state outright that requests to static assets are free and unlimited
- 500 builds/month, 1 concurrent build
- 100 custom domains per project
- Up to 20,000 files per deployment, 25 MiB max per asset
- Workers (for Pages Functions / API routes): 100,000 requests/day, 10 ms CPU time per invocation
- Workers KV: 100,000 reads/day, 1,000 writes/day, 1,000 deletes/day, 1,000 list ops/day, 1 GB storage
- D1 (SQLite): 5 GB storage, 5 million rows read/day, 100,000 rows written/day

The two additions worth flagging are the ones people actually hit. The 20,000 file limit is what a large docs site or an image-heavy static build runs into, long before any bandwidth concern. And D1's daily row limits are a tighter constraint than the 5 GB storage figure - 100,000 row writes per day is the number to plan against, not the storage.

No credit card required. No inactivity pausing. Commercial use permitted - Cloudflare imposes no non-commercial restriction on the free plan, which is why it is the right answer for anything you might one day charge for.

Pros:
- Genuinely unlimited bandwidth, at no cost, with no fair-use asterisk on static assets
- Fastest global CDN
- Workers, KV and D1 available on the same free account
- You are allowed to make money

Cons:
- Workers have a different runtime API than Node.js
- 10 ms CPU per invocation on the free Workers plan is tight for anything computational
- Cloudflare now pushes Workers Static Assets for larger deployments. Pages is not deprecated and the docs present it as actively supported, but be aware there is a "migrate from Pages to Workers" guide and a direction of travel.

Deploy:

npm install -g wrangler
wrangler login
wrangler pages deploy ./dist

Tips:
- Use Workers for API routes
- D1 is great for read-heavy apps; watch the daily write ceiling
- Enable Web Analytics (free)

---

GitHub Pages

Best for: documentation, personal sites, open source projects - and nothing you intend to monetise

The simplest option for static sites, directly from your repository. The limits are stable; two of this guide's old characterisations were not.

Free Tier:
- 100 GB/month bandwidth (soft limit) - not "unlimited"
- 10 builds per hour (soft limit)
- Published site max 1 GB; source repo recommended limit 1 GB
- Custom domains with SSL
- Jekyll built in

The old "unlimited bandwidth (fair use)" line was wrong in a way that matters for the comparison table: GitHub Pages has a stated 100 GB/month figure, the same headline number as Vercel and legacy Netlify. It should not sit in a comparison next to Cloudflare Pages under "unlimited" - that formatting implies an advantage that does not exist.

Commercial use is restricted. GitHub's docs state that Pages "is not intended for or allowed to be used as a free web-hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS)." So this is not the place for your SaaS landing page with a checkout on it. Donation buttons and crowdfunding links are explicitly permitted - which is the exact opposite of Vercel's policy, so read both if you are choosing between them.

Pros:
- Free, stable, no card, no pausing
- Direct GitHub integration, no build configuration for Jekyll

Cons:
- Static only
- Public repos only on GitHub Free - private-repo Pages requires Pro, Team or Enterprise
- No commercial SaaS or e-commerce

Enable GitHub Pages:
1. Repo Settings > Pages
2. Select branch (usually main or gh-pages)
3. Choose folder (/ or /docs)
4. Save

Tips:
- Use GitHub Actions for custom builds
- CNAME file for custom domains
- Great for project documentation

---

Backend-as-a-Service (BaaS)

Supabase

Best for: apps needing auth, database and real-time - up to two of them

Supabase is Firebase with PostgreSQL, and it remains an excellent free tier. The two things to internalise are the project cap and the pausing.

Free Tier:
- 500 MB database (shared CPU, 500 MB RAM)
- 1 GB file storage
- 5 GB egress plus 5 GB cached egress (this guide previously understated it as 2 GB)
- 50,000 monthly active users for auth
- Unlimited API requests
- Edge Functions: 500,000 invocations
- Realtime: 200 concurrent connections, 2 million messages
- Log retention: 1 day
- Maximum 2 active projects

The 2-project limit is the omission that catches people. If you already have two Supabase side projects, you cannot start a third without paying. Plan your account layout before you build a stack that assumes Supabase is your default backend.

Free projects still get paused after about a week of inactivity. This has not changed and you should not let anyone tell you otherwise. Pausing is measured by database activity, and Supabase's own docs say a few user requests to the database each day over the previous week is enough to avoid it. You get a warning email roughly a week beforehand and a confirmation email when it pauses. A paused project can be restored for up to 1 year; after that you are rebuilding from a downloaded backup into a fresh project by hand. That one-year cliff is what turns "my project paused" into "I lost my project."

Paid projects are never paused for inactivity.

Card: Supabase's pricing page does not state whether a card is required for the Free plan. I could not verify it either way - check at signup.

Pros:
- Full PostgreSQL power, row-level security, great dashboard
- Self-hosting option if you outgrow the free tier or the pausing

Cons:
- 2 active projects
- Pauses after ~1 week of inactivity
- 500 MB fills fast if you put files in the database
- Learning curve for RLS

Quick Start:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://xxx.supabase.co',
  'your-anon-key'
)

// Query data
const { data } = await supabase
  .from('projects')
  .select('*')

Tips:
- Use Storage for files, not the database
- Enable RLS for security
- If a project is going dormant, download a backup rather than trusting the restore window

---

PocketBase

Best for: self-hosted backend with zero dependencies

PocketBase is a single executable that gives you database, auth, file storage and an admin dashboard. It is in good health: the latest release is v0.39.10 from 30 July 2026, with releases landing roughly weekly, and an older v0.22.x branch still receiving backports.

Free Tier:
- Completely free, self-hosted
- Single binary, no dependencies
- SQLite database
- Admin dashboard included

Pros:
- Deploy anywhere (Render, Fly.io, a $5 VPS)
- No external dependencies
- Real-time subscriptions and file storage included
- Actively maintained, shipping weekly

Cons:
- Self-hosted means you manage it, including backups
- SQLite limits your scaling options
- Smaller community than Supabase
- Still pre-1.0 after four years - the API can break between minor versions, so pin your version and read release notes before upgrading

Deploying it - two corrections to the old instructions.

First, there is no official PocketBase Docker image. PocketBase's own production docs say so explicitly and offer a minimal Dockerfile as an example instead. The ghcr.io/pocketbase/pocketbase:latest image this guide used to recommend does not exist and the pull will fail. Build from the release archive:

FROM alpine:latest

ARG PB_VERSION=0.39.10

RUN apk add --no-cache unzip ca-certificates

ADD https://github.com/pocketbase/pocketbase/releases/download/v${PB_VERSION}/pocketbase_${PB_VERSION}_linux_amd64.zip /tmp/pb.zip
RUN unzip /tmp/pb.zip -d /pb/

EXPOSE 8080

CMD ["/pb/pocketbase", "serve", "--http=0.0.0.0:8080"]

Second, and more importantly: you must mount a persistent volume at /pb/pb_data. PocketBase keeps its SQLite database there, and if it lives inside the container filesystem it is destroyed every time the container is recreated. On any container host that is a routine event - every redeploy, every restart - not an edge case. Without the volume, your first deploy after launch silently wipes every user you signed up.

Tips:
- Mount /pb/pb_data on a volume, then back it up as well
- Pin PB_VERSION rather than tracking latest
- Use hooks for custom logic

---

Can You Actually Make Money On It?

Free hosts disagree sharply on this, and the disagreement is invisible until you read the terms. If your side project has any revenue ambition, this is a harder constraint than any bandwidth number.

Note the direct contradiction: a "buy me a coffee" button is fine on GitHub Pages and a terms violation on Vercel. If you want a free host and a tip jar, Cloudflare Pages is the uncomplicated answer.

---

Choosing the Right Platform

Decision Tree

What are you building?
│
├── Static site / Landing page
│   └── Cloudflare Pages (unlimited bandwidth, commercial use OK)
│   └── GitHub Pages (simplest, but public repo and no business use)
│
├── Frontend app (React/Vue/Next.js)
│   ├── Never going to earn money?
│   │   └── Vercel Hobby (best Next.js DX, functions now run 5 min)
│   ├── Might earn money?
│   │   └── Cloudflare Pages
│   └── Specifically want free forms?
│       └── Netlify (but 300 credits/month, and the site goes dark at zero)
│
├── Full-stack app (Rails/Django/Node)
│   ├── Can tolerate sleeping?
│   │   └── Render free (750 hrs/workspace, 15-min spin-down)
│   ├── Want it always on?
│   │   └── Budget for it: Railway paid, or Fly.io from ~$2/month/machine
│   └── Note: free Postgres anywhere is temporary. Plan the database first.
│
└── Need backend without coding
    └── Supabase (PostgreSQL + Auth; 2 projects, pauses when idle)
    └── PocketBase (self-hosted, simple; you own the backups)

By Framework

---

Pro Tips for Free Hosting

1. Don't Fight the Sleep

The old advice - ping your app every 10 minutes so it never spins down - is now actively harmful on the two hosts where people apply it.

• On Render, spun-down time does not consume your 750 monthly hours. Keeping a single service awake around the clock uses roughly 730 of them, so an uptime pinger is exactly what makes one always-on app exhaust the workspace allowance and get suspended. Let it sleep.
• On Railway's Free plan, pinging does nothing useful either. Once the $1 credit is gone the service is stopped, not sleeping, and no amount of traffic will wake it.

For a side project, a one-minute cold start on the first visit of the hour is a fine trade. If it genuinely is not, that is your signal to pay for hosting, not to game the free tier.

2. Design Around the Database, Not the App Server

Free compute is easy to find. Free persistent storage is the scarce resource, and it is where every free tier has a cliff:

• Render Postgres expires 30 days after creation, deleted 14 days later
• Railway deletes volumes created by trial accounts 30 days after credits expire
• Supabase pauses idle projects after a week and holds them for a year
• PocketBase on any container host loses SQLite entirely without a mounted volume

Pick where your data lives first, and know its expiry date before you write the first migration.

3. Optimize for Free Limits

• Compress images before upload
• Cache aggressively - on Vercel, the 10 GB Fast Origin Transfer guideline punishes uncached responses specifically
• Lazy load non-critical content
• On Netlify, iterate on deploy previews (free) rather than production deploys (15 credits each)

4. Hybrid Approach

Combining services still works well:

• Frontend on Cloudflare Pages (unlimited bandwidth, commercial use allowed)
• API on Render free if it can sleep, or Fly.io if it cannot
• Database on Supabase (mind the 2-project cap) or a paid Postgres you control
• Files on Cloudflare R2 (no egress fees - check the current free storage allowance, which I did not re-verify for this edition)
• DNS and SSL on Cloudflare

5. Know How Each Platform Fails

They do not fail the same way, and the differences decide how much damage a bad month does:

Cloudflare's daily-reset model is much more forgiving than a monthly cliff, and Netlify's is the harshest.

---

My Recommended Stack

For a typical side project in 2026:

That is a genuine $0/month, with two conditions attached that the 2025 version of this table did not have: your API sleeps, and your database pauses if nobody uses it for a week.

If you want an always-on app with a database you control, the honest number is no longer zero. Budget somewhere in the region of $5-10/month - a paid Render instance or a couple of Fly machines plus a small Postgres - and stop trying to make free tiers do a paid tier's job.

---

When Free Isn't Enough

Signs you need to upgrade:

• Cold starts are costing you users on the first click
• Your free database is about to expire, or already has
• You want revenue, and your host forbids it
• Netlify credits or Railway's $1 run out before the month does
• You need more than one collaborator (Netlify Free is 1 owner, Render Hobby is 1 seat, Vercel Hobby is personal)

Paid plan prices move as fast as free tiers do, so check the pricing page rather than trusting a number in an article - including this one. What is stable is the shape of the decision: the first $5-10/month you spend buys an app that stays awake and a database that stays alive, and that is usually the upgrade worth making first.

At that point, your side project is working. Reinvest some revenue into infrastructure.

---

Share Your Deployed Project

Successfully deployed your side project? Share it with the builder community and connect with other developers who understand the journey from idea to launch.

---

Limits in this guide were verified against provider documentation on 6 August 2026. Free tiers change without notice - if you are about to commit to a platform, spend two minutes on its pricing page first.