Frontend vs Backend Deployment: What's the Difference?

Your index.html opens fine when you double-click it. Your FastAPI server answers every request the moment you type uvicorn main:app in your terminal. None of it exists anywhere except your own laptop, though. The second you try to make any of it public, a new question shows up: deploy what, exactly, and where?

You already know what deployment means from the last lesson. Here's the part that trips up almost everyone next: frontend vs backend deployment isn't one process, it's up to three different ones, depending on what you actually built. This lesson gives you a simple test to figure out which your own project needs.

Key Takeaways

• Frontend deployment copies static files (HTML, CSS, JavaScript) to a host built to serve files fast, with no ongoing computation and often a free-forever tier
• Backend deployment keeps a real program, like a FastAPI server, running continuously and listening for requests, which needs more compute and has tighter free-tier limits
• Full-stack deployment means both together, usually on two different platforms connected by a live URL instead of localhost
• A three-question test tells you exactly which type your project needs, no matter how it grows later

---

What Is Frontend Deployment?

Frontend deployment means moving static files, your HTML, CSS, and JavaScript from lessons 06.01 through 06.04, onto a server built specifically to serve files fast to a browser. Nothing runs continuously and nothing gets computed on the fly.

The server's whole job is handing out the exact files you gave it, the same way a librarian hands you a book instead of writing one for you on the spot. That's why frontend hosting is usually the simplest and cheapest option in this whole module, often free with no real limits for a small project.

Skip understanding this distinction, and you'll end up reaching for a full backend server (or paying for one) just to host a page that never changes. Lesson 09.03 walks through deploying your own index.html to exactly this kind of host, using Vercel.

MDN's explainer on how the web works covers this same file-serving model in more technical depth, if you want it.

What Is Backend Deployment?

Backend deployment means putting an actual running program, like the FastAPI server you built in lesson 07.01, on a server that keeps a process alive and listens for requests around the clock. This is not handing out files. It's actively running your code every single time someone visits.

That constant activity is exactly why backend free tiers tend to be tighter than frontend ones. A file host pays almost nothing to store a page nobody's viewing right now. A backend host is paying to keep your program awake and ready, whether anyone's using it or not.

I've watched this exact mistake happen more than once: someone tries to run a live Python process on a plain static file host, and nothing ever loads. A file server has nowhere to actually execute your code. Lesson 09.04 walks through the fix, how to deploy a backend to Render so a real process stays running. AWS's explainer on what a cloud server is is a good plain-English reference if the "always-on process" idea still feels fuzzy.

What Is Full-Stack Deployment?

Full-stack deployment means both of the above, together. A frontend serves your interface, and a backend handles real logic, like calling the Claude API or reading from the Supabase database you set up in lesson 07.03. Some platforms can host both pieces in one place, but often you'll use two platforms connected by real, live URLs.

Here's the failure mode almost everyone hits the first time: you deploy your backend, it gets a shiny new URL, and your site still doesn't work. Your frontend code is still pointed at localhost, the address that only ever existed on your own laptop.

Full-stack deployment is the one that takes the most pieces working together correctly. It's also the one this entire module is building you toward.

Frontend vs Backend Deployment: The Three-Question Test

You don't need to memorize any of the above to use it. Skip this test and you'll guess your way into the wrong platform, wasting an afternoon fighting a host that was never built for what you're asking it to do. Run any project, yours or anyone else's, through these three questions, in order, and stop at the first "yes."

The three-question deployment test

A portfolio page with your bio and project links stops at question one. A Python API that just returns a Claude-generated answer, with no visual interface, stops at question two. A full AI chat app, with a text box, a server calling Claude, and a database saving conversation history, needs all three questions answered together.

If any of this still feels shaky, the Getting Started path walks through the basics again from the top.

---

Your Task

FAQ

Common questions

• Do I need two different hosting accounts for frontend and backend?

  Usually yes, if you're keeping them on separate platforms, like Vercel for your frontend and Render for your backend. Each platform only handles the account you create on it. Some platforms can host both under one account, but they're still billed and configured as separate services.

• Can I deploy frontend and backend on the same platform?

  Sometimes. A few platforms, including Vercel, can run lightweight backend functions alongside a frontend in one project. For a full, always-on backend process like a FastAPI server, though, you'll usually still want a platform built for that, like Render, even if your frontend stays on Vercel.

• Why is my deployed site still calling localhost after I deploy the backend?

  Your frontend code probably still has your local backend address, something like localhost:8000, hardcoded into it. Once your backend is live at a real URL, you need to update your frontend to call that URL instead. This is one of the most common first-deploy mistakes, and it's an easy fix once you know to look for it.

• Does a database need its own deployment step?

  Not the way a frontend or backend does. A database like Supabase is already hosted and live from the moment you create it. What actually needs configuring is connecting your deployed backend to it, using the same URL and API key your local project already uses.