Back to path
ExpertTradepost · Project 12 of 12 ~12h· 6 milestones

Ship the API and run it in production

Continues from the last build: It is measured, tested, cached, rate limited and observable. It has never left your laptop.

Last rung you made it fast and honest: p99 latency under load, a Redis cache with a real hit rate, rate limiting that sheds abusive traffic instead of falling over.

Render blueprint deploys (render.yaml)Zero-downtime schema migrations (expand and contract)Database backup and restore drillsOWASP API Security Top 10 threat modelingEnvironment and secrets management across staging and prodAPI versioning and deprecation policyProduction readiness writeups and demo scripts

What you'll build

A production Tradepost running on Render: web service and worker as separate processes, managed Postgres and Redis, a render.yaml blueprint anyone on the team can redeploy from cold, a completed expand and contract migration that renamed a live column without a blip, a restore drill you ran yourself with a written RPO and RTO, a 10-line threat model with BOLA, injection, rate limiting and over-exposure checked off, and a README with the final architecture diagram plus a 90 second demo script you could give in an interview tomorrow.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

render.yamlyaml
services:
  - type: web
    name: tradepost-api
    env: node
    buildCommand: # TODO
    startCommand: # TODO
    healthCheckPath: # TODO
    preDeployCommand: # TODO run drizzle migrations here
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: tradepost-db
          property: connectionString

  - type: worker
    name: tradepost-worker
    env: node
    buildCommand: # TODO
    startCommand: # TODO

databases:
  - name: tradepost-db
    postgresMajorVersion: 16

Reading this file

  • preDeployCommand: # TODO run drizzle migrations herethis is what makes migrations run before new code, never bundled into buildCommand
  • type: workera separate service, no healthCheckPath, no public URL
  • healthCheckPath: # TODOfill this with a route that checks Postgres and Redis, not just process liveness

The web service is missing its build, start and health check commands, and the preDeployCommand that should run migrations before traffic cuts over. Fill these in during the first milestone.

That's 1 of 10 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Wire the production deploy with render.yaml

    6 guided steps

    A deploy that only exists as clicks in a dashboard cannot be reviewed, reproduced, or handed to a teammate. A blueprint file is the difference between 'someone remembers how we set this up' and infrastructure that lives in git next to the code it runs.

  2. 2

    Separate secrets and environments so staging never touches prod data

    5 guided steps

    The first time someone pastes a production connection string into a staging config, or a secret ends up in a commit, is the last time anyone trusts your deploy process. Environments and secrets need a boundary that survives a tired engineer at 11pm.

  3. 3

    Rename a live column with zero downtime, the expand and contract way

    5 guided steps

    A single ALTER TABLE RENAME COLUMN deployed alongside new code that expects the new name will 500 every request between the migration running and the new code rolling out, because Render replaces instances one at a time and old code is still running against the new schema for a few seconds. Expand and contract turns that gap into nothing.

  4. 4

    Run a real backup and restore drill

    6 guided steps

    A backup nobody has restored from is a rumor, not a backup. The only way to know your recovery time is to time it, and the only way to know your restore actually produces a working database is to point a real API at it and run real queries.

  5. 5

    Run a security pass against the OWASP API Security Top 10

    5 guided steps

    BOLA, broken object level authorization, is the single most common real-world API breach, it is what happens when your authorization check is 'does a row with this id exist' instead of 'does a row with this id exist and belong to the caller'. A threat model that fits in 10 lines forces you to name your actual attack surface instead of gesturing at 'security' in general.

  6. 6

    Launch: docs, an uptime monitor and the production writeup

    5 guided steps

    An API nobody outside your team can discover or trust the uptime of is not really launched, it is just deployed. Docs, monitoring and a clear deprecation policy are what let a stranger integrate with confidence, and a tight demo script is what turns 12 rungs of work into something you can actually talk about.

What's inside when you start

4 starter files, ready to clone
6 guided milestones
6 full reference solutions
10 code blocks explained line-by-line
6 "is it working?" checks
6 interview questions it prepares you for

You'll walk away with

render.yaml blueprint deploying a web service and a separate worker, both backed by managed Postgres 16 and managed Redis, with a health check gating traffic
.env.example as the single source of truth for required variables, staging and production environment groups in Render, and a written zero-downtime key rotation procedure
A completed three-deploy expand and contract migration that renamed a live orders column with zero request failures, using drizzle migrate as a preDeployCommand
A restore drill: a manual pg_dump restored into a scratch database, a local API verified against it, and RECOVERY.md recording measured RPO and RTO
A security pass against the OWASP API Security Top 10 with merchant scoping (BOLA), rate limiting, injection and serializer over-exposure fixed, plus a 10-line THREAT_MODEL.md
Public /docs, an external uptime monitor on /health, VERSIONING.md, and a README production section with the final architecture diagram and a rehearsed 90 second demo script

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building