01 The AI-Native Engineer's Toolkit: Git, Linux, Docker and AI Coding Tools/1.5 Shipping a Full-Stack App with Postgres to the Cloud

§ 1.5section 5 of 5·~20 min

Shipping a Full-Stack App with Postgres to the Cloud

Gushwork names a deployed full-stack app as the minimum portfolio artefact. Handshake expects fluency with Postgres, APIs and the cloud. This section takes the app you have been building, a FastAPI or TypeScript API with Postgres and a small React frontend, and ships it to a public URL with CI, migrations and a health check. Every later chapter adds AI features to this exact codebase, so the time you spend getting the foundation right pays off repeatedly.

1. The target architecture

code

Browser

|

v

React static build (static host / CDN)

  |  HTTPS, JSON

v

API container (FastAPI on a container PaaS)

  |  TLS, DATABASE_URL

v

Managed Postgres

Recommended path: a container-friendly PaaS such as Render, Railway or Fly.io for the API, the platform's managed Postgres (or Neon or Supabase), and a static host such as Vercel, Netlify or Cloudflare Pages for the frontend. You get HTTPS, logs and automatic deploys with almost no ops work, and the same Docker image you built earlier runs unchanged.

Alternative: a single VM running your compose.yaml behind nginx. You learn more ops this way, since everything from the Linux section applies directly. In exchange, TLS, backups, OS updates and restarts become your job. Either choice is acceptable for the portfolio. Pick one and finish it.

Free tiers change often, and some of them sleep or expire. Check the current terms before you commit to a platform.

2. Make the app cloud-ready

Configuration from the environment

Nothing environment-specific belongs in the code. Read it from environment variables:

code

from pydantic_settings import BaseSettings

class Settings(BaseSettings):

    database_url: str

    cors_origins: list[str] = []

    environment: str = 'dev'

settings = Settings()

Locally these values come from .env through Compose. In the cloud you set them in the platform's dashboard. .env stays out of Git and out of the image.

Respect the platform's port

Most PaaS platforms tell your container which port to listen on through a PORT variable. Set a default in the Dockerfile and use it in a shell-form CMD so the variable expands:

code

ENV PORT=8000

CMD exec uvicorn app.main:app --host 0.0.0.0 --port $PORT

Postgres connection strings

Two gotchas cause most first-deploy failures:

Many providers hand out URLs that begin with postgres://. SQLAlchemy 1.4 and later rejects that scheme. Use (or with the default driver) and normalise the scheme in your settings if needed.

LABOPS-318· hands-on

Recover the lost hotfix and triage the crash-looping deploy

Fix a real ticket in a small codebase you didn't write: read the code, change only the functions you're given, pass the tests, then submit for hidden checks and a score.

Open the lab →

Shipping a Full-Stack App with Postgres to the Cloud

1. The target architecture

2. Make the app cloud-ready

Configuration from the environment

Respect the platform's port

Postgres connection strings

A real health check

Migrations, not create_all

CORS for a separately hosted frontend

Frontend API URL

3. CI: nothing reaches main without passing tests

4. The first deploy, step by step

5. When the deploy fails

6. Production basics

7. Make it a portfolio artefact

Definition of done