Deploying for free

Six parts in, you have a real API with routes, error handling, a database, and auth. This last part gets it off your machine and onto a public URL, for free.

Picking a host

Vercel's free tier works well for this API since Express apps run there as serverless functions with no extra configuration beyond an entry file. A managed Postgres add-on (or a free instance from a host like Neon or Supabase) covers the database from part four.

Preparing the entry point

Serverless platforms expect your app to export a request handler instead of calling app.listen() directly. Split that out:

// api/index.js
const app = require('../app');
module.exports = app;

// app.js
const express = require('express');
const app = express();

// ...all your routes and middleware from parts 1–5

module.exports = app;

Locally, keep a small server.js that calls app.listen() for development — it's never deployed.

Setting environment variables

DATABASE_URL and JWT_SECRET need to exist in production the same way they did in your local .env file. Set them in your hosting provider's dashboard rather than committing them — this is the one step people skip and then spend an hour debugging.

FAQ

Can I use a custom domain instead of the free *.vercel.app URL? Yes — most hosts let you point a domain you own at the deployment via a DNS record. If a custom domain isn't resolving right after setup, how DNS resolution works covers exactly what's happening between adding that record and it actually taking effect.

Why split app.js from api/index.js instead of deploying server.js directly? Serverless platforms invoke your code per-request rather than running one long-lived process — they need a plain exported handler, not a script that calls app.listen() and blocks waiting for connections. Keeping server.js for local development only means the same app.js works in both environments without modification.

What happens to console.log output in production? Most serverless hosts capture stdout/stderr into their own logging dashboard automatically — check your specific host's docs for where to view it, since this is exactly where the error middleware's console.error(err.stack) from part three ends up being genuinely useful in production.

What's next

You've now built and shipped a complete API: routing, error handling, a real database, authentication, and a live deployment. The same shape — routes, middleware, error handling, deploy — is what you'll reach for on every backend project after this one.