Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
The first deploy is the moment your agent stops being a notebook and becomes a service. The smoothest path: a managed PaaS (Fly/Render/Railway) with auto-HTTPS, env-var secrets, and a built-in CI/CD. From 'works on my machine' to 'serves a real URL' in under an hour. Resist the urge to spin up your own VM + nginx + Caddy on Day 1.
Concretely: write a Dockerfile (or use buildpacks), push to a managed PaaS, set env vars (DATABASE_URL, REDIS_URL, ANTHROPIC_API_KEY), deploy. The PaaS handles TLS, scaling (within limits), and routing. You get a *.fly.dev URL. Map a custom domain. Done. Total setup: 30-60 minutes from clean repo to public URL.
Use these three in order. Each builds on the one before.
Compare 3 ways to deploy a Day-1 agent: PaaS (Fly), serverless (Vercel), raw VM. When does each fit?
Walk me through Fly's auto-stop / auto-start. How does it reduce cost at low traffic?
Design a Day-1 deploy with rollback: every deploy stamped with a git SHA; one-click revert. What's the workflow?
# fly.toml
app = "capstok-agent"
primary_region = "iad"
[build]
image = "python:3.13-slim"
[env]
PORT = "8080"
[http_service]
internal_port = 8080
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 1
# Set secrets (NOT in fly.toml)
# fly secrets set ANTHROPIC_API_KEY=sk-...
# fly secrets set DATABASE_URL=postgres://...
# fly secrets set REDIS_URL=redis://...
# Deploy
# fly launch # one-time
# fly deploy # each subsequent push
# CI/CD via GitHub Actions
# .github/workflows/deploy.yml
name: Deploy
on: { push: { branches: [main] } }
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: superfly/flyctl-actions/setup-flyctl@master
- run: flyctl deploy --remote-only
env: { FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }} }python3 main.py