Deploy a backend to the cloud

What you will do: put your FastAPI backend on the internet with a public HTTPS address, connected to a managed Postgres database, configured through environment variables.

Prerequisites: the project from *Containerise your backend with Docker* (a Dockerfile, requirements.txt and app/main.py), a free GitHub account, and Git installed.

We use Render as the worked example because it deploys straight from a GitHub repository and has a free plan for learning. The names of buttons change over time, but the ideas are the same on every host: Railway, Fly.io, Azure App Service, Google Cloud Run, AWS (App Runner, Elastic Beanstalk, ECS) and a plain Linux server. Learn the ideas, not the buttons.

Deploying means running your code on a computer that is always on, reachable from the internet, with the right settings. Compare with your laptop:

The server has no .env file you made by hand, so configuration must be supplied as environment variables.

It is not localhost. Users reach it by a domain name over HTTPS, usually through a load balancer or proxy that handles the certificate.

Its disk may be wiped on every deploy, so data belongs in a managed database or object storage, never in local files (this includes SQLite files).

Nobody is watching the terminal, so you need logs and health checks (see *Logging, metrics and health checks*).

Start with a platform that deploys from Git. It teaches the essentials without drowning you in infrastructure.

Three small changes make the app friendly to hosting platforms.

1. Listen on the port the platform gives you. Most platforms set a PORT environment variable and expect your app to listen on it. Change the Dockerfile CMD to the shell form so the variable is expanded, with 8000 as the local default.

2. Accept the database URL the platform provides. Many hosts give a URL starting with postgres:// or postgresql://, but SQLAlchemy with the psycopg driver needs postgresql+psycopg://. Normalise it in code.

3. Never depend on local files. The SQLite default in our code is fine on your laptop, but on the server we always set DATABASE_URL.

CMD ["sh", "-c", "uvicorn app.main:app --host 0.0.0.0 --port ${PORT:-8000}"]

Replaces the earlier CMD line. ${PORT:-8000} means: use PORT if set, otherwise 8000. The rest of the Dockerfile stays the same.

import os

from sqlalchemy import create_engine


def get_database_url() -> str:
    url = os.getenv("DATABASE_URL", "sqlite:///./brewbean.db")
    # Hosts often give postgres:// or postgresql://; SQLAlchemy + psycopg needs this prefix
    for prefix in ("postgres://", "postgresql://"):
        if url.startswith(prefix):
            return "postgresql+psycopg://" + url[len(prefix):]
    return url


engine = create_engine(get_database_url(), pool_pre_ping=True)

Use this in place of the earlier create_engine lines. Everything else in main.py (tables, routes, /healthz, /readyz) stays as it was.

The exact screens differ by host, but the order is always: database first, then the service that uses it, so you have a URL to give the service.

The port number in your log may differ. That is fine: it is the value the platform put in PORT.

With Git-based hosting, deploying a change is just git push. The platform rebuilds the image, starts the new version, waits for the health check to pass and then switches traffic. If the health check never passes, the old version keeps running. That is why /healthz matters.

Most platforms keep earlier deploys so you can roll back with one click. Know where that button is before you need it.

Database changes need care. Our demo creates tables at startup, which is fine for learning. In a real project use migrations (Alembic for SQLAlchemy, see *ORMs and migrations*) and run them as a separate step before the new version starts. Make changes in small, backwards-compatible steps: add a column first, deploy code that uses it, and only later remove the old one.

How this comes up in interviews. You may be asked: how would you deploy this API; what is the difference between staging and production; why not store uploads or data on the server's disk; how do you manage secrets; what is a rolling deployment; how do you roll back a bad release. Answer from your own experience of having deployed the Brew & Bean API.

My [FastAPI / Express] app deployed on [Render / Railway / other host] fails to start. Here are the last 40 lines of the deploy log:

[paste log]

My start command is: [command]
Environment variables I set (names only, not values): [list]

Explain the most likely cause in plain English, then give the exact change to fix it. If you need more information, ask me one question first.

What to expect: Never paste real passwords or API keys into an AI chat; replace them with placeholders. A good answer points to a specific line of the log.