Hosting the Backend with Render: APIs, Free Tiers, and the Trap You Need to Know About

Your frontend is live on Vercel. Great — now it needs something to talk to. Render is where your backend service or API actually runs, and it's just as GitHub-connected and CI/CD-friendly as Vercel. But the free tier has two behaviors you absolutely need to understand before you build anything real on it.

Prerequisites

• Backend code (Node.js/Express, Python/Flask or FastAPI, or similar) already pushed to a GitHub repository.

• A Render account.

Again — no Git teaching here. If your API runs locally and is committed to GitHub, you're ready.

Why Render for the Backend

Vercel is optimized for frontend/edge workloads; Render is built for long-running web services — the kind of always-listening server process an API needs. It supports native runtimes (Node, Python, Ruby, Go, Rust) and Docker, with the same "connect your repo and deploy" simplicity you just saw with Vercel.

Deploying Your Web Service

From the Render dashboard: New → Web Service → connect your GitHub repository. You'll specify:

• Build Command (e.g. npm install or pip install -r requirements.txt)

• Start Command (e.g. node server.js or uvicorn main:app)

• Any environment variables your service needs, set in the dashboard

Just like Vercel, once this is connected, every push to your main branch triggers an automatic redeploy. This is the same CI/CD principle applied to backend compute instead of static assets.

The Free Tier Reality Check

Here's the part every student needs to internalize before demo day: free Render web services spin down after 15 minutes of inactivity. If nobody hits your API for 15 minutes, Render puts it to sleep. The next request wakes it back up — but that first request after a nap can take close to a minute to respond, because the whole service is cold-starting.

This isn't a bug, it's the trade-off for free compute. It's completely fine for a personal project, a portfolio piece, or a classroom demo. It is not fine for anything where a user expects an instant response 24/7 — plan accordingly, and don't be surprised if your API feels "slow" the first time someone opens your app after a coffee break.

The 30-Day Database Trap ⚠️

This is the single most important warning in this series, so read it twice: if you spin up Render's free PostgreSQL database alongside your API, it will expire and be permanently deleted exactly 30 days after creation. You get a 14-day grace period to upgrade to a paid plan before your data is wiped — after that, it's gone. No recovery.

Students building a semester-long project on Render's free database have shown up to their final demo with an empty, expired database. Don't let that be you.

What This Means for Your Architecture

Use Render for what it's good at — hosting your compute, your API, your background logic — and treat its free database as a throwaway convenience at best, never as your project's real data layer. In Part 3, we fix this properly with a database that doesn't have a countdown timer.