Introduction to deployment
Deploying the
AI News API at Berlin Hauptbahnhof
Concepts first, then a complete Google Cloud Run walkthrough
FastAPI · Docker · Supabase PostgreSQL · Cloud Run · Cloud Scheduler
September 2026
Two sections connect deployment theory to a working application
02
SECTION 1
Introduction to deployment
What deployment means
Hosting options and trade-offs
The deployment workflow
Deployment pipelines and CI/CD
SECTION 2
Deploy it ourselves
Create the accounts
Prepare Docker and PostgreSQL
Deploy the API and pipeline job
Schedule and verify weekly execution
03
SECTION 1
Introduction to deployment
The concepts behind moving an application from a laptop to a live service
Deployment makes a locally developed application available to other users
04
Local development
Runs on your laptop
Accessible mainly to you
Used for development and testing
Stops when your machine stops
Server deployment
Runs on remote infrastructure
Accessible through the internet
Can serve multiple users
Designed for continuous availability
Deployment is the transition between these two states.
Cloud platforms offer three main levels of infrastructure management
05
1
Virtual machine
IaaS
You manage the operating system, Docker, networking, security and updates.
2
Managed container
CaaS
You provide a container. The platform manages servers, routing and scaling.
3
Serverless function
FaaS
You deploy a function that runs when an event or request triggers it.
More convenience usually means less infrastructure control.
Managed container platforms run Docker images without exposing the servers
06
What it is
You provide a Docker container. The platform handles orchestration, scaling, networking and infrastructure. You focus on the application while the provider handles the underlying servers.
Advantages
Easy scaling and load balancing
Built-in monitoring and logging
Automatic security updates
Pay for what you use
Trade-offs
Less customization than a VM
Platform-specific features
Less control over networking and logs
Examples: Google Cloud Run, AWS ECS with Fargate, Azure Container Apps
Serverless functions trade more infrastructure control for event-based execution
07
What it is
Code runs as an auto-scaling function triggered by requests or events. The provider manages the servers, but the application must fit runtime, memory and execution constraints.
Advantages
No server management
Automatic scaling to zero
Pay per execution
Built-in fault tolerance
Trade-offs
Execution time and memory limits
Cold-start latency
Poor fit for persistent models
Examples: AWS Lambda, Google Cloud Functions, Azure Functions
Cloud-provider selection depends on cost, location and organizational needs
08
1
Price
Compare compute, bandwidth and charges that appear outside the headline price.
2
Location
Choose a region near users and related services to reduce latency.
3
Documentation
Clear setup guides and active communities reduce troubleshooting time.
4
Compliance
Check SOC 2, ISO 27001 and any industry-specific requirements.
5
Existing infrastructure
Employer, client, billing or integration policies may decide the provider.
The deployment workflow moves tested source code into a running container service
09
1
Develop locally
Build and test the application on the development machine.
2
Commit to a repository
Push a known working version to GitHub or another version-control system.
3
Build the container
Create an image that contains the application and its dependencies.
4
Deploy the service
Upload source or an image to the managed container platform.
5
Update as needed
Repeat the build, deploy and verification steps when the code changes.
A successful deployment replaces localhost with an internet-accessible service
10
Before
http://localhost:8080/news/
Available only while the application runs on the developer's machine.
After
https://YOUR_CLOUD_RUN_URL/news/
Available to users through the managed HTTPS endpoint.
Users can now call the API from other machines and applications.
Deployment becomes a repeatable cycle after the initial cloud setup
11
1
Develop locally
Change the code and test it on the development machine.
2
Commit
Record the working version in source control.
3
Deploy
Build and release a new Cloud Run revision.
4
Verify
Test the live endpoints and inspect logs.
5
Repeat
Use the same process for the next application change.
Serious applications add controls before changes reach production
12
A single production environment teaches the basic deployment process, but it does not protect users from every release mistake.
Untested code can break the live service
Separate environments catch issues before production
Teams need a structured collaboration process
Rollbacks and hotfixes need predictable procedures
A deployment pipeline improves safety, reliability and release confidence.
A typical deployment pipeline moves changes through four environments
13
1
Development
Engineers write code, fix bugs and run initial tests in isolated environments.
2
Test
Automated tests and QA checks identify failures and edge cases.
3
Acceptance
A staging environment mirrors production so stakeholders can validate requirements.
4
Production
The approved application serves real users while monitoring checks its health.
Multiple environments add operational complexity beyond this project
14
A complete deployment pipeline can involve:
Separate development, test, acceptance and production environments
Independent settings, credentials and infrastructure for each environment
Controlled promotion of code between stages
Consistent configuration across all environments
Current scope
Master one production deployment first, then add environments and automation when the application needs them.
CI/CD automates testing and deployment after code reaches the repository
15
Continuous Integration
A push or pull request starts automated checks so the team finds failures before release.
Continuous Deployment
Approved code moves through staging and production without repeating every command manually.
git push -> tests -> acceptance -> production
Examples: GitHub Actions, Jenkins and Azure DevOps
This course first documents the manual process that future automation will reproduce.
09
SECTION 2
Deploy it ourselves
A simple, repeatable walkthrough for the AI News API�FOLLOW README FOR WEEK 5 HERE
The deployment separates web traffic from scheduled processing
02
Cloud Scheduler
Weekly timer
Cloud Run Service
FastAPI
/health · /news · /search
Cloud Run Job
app.pipeline
scrape · enrich · index
Supabase
PostgreSQL + pgvector
news_items · news_chunks
HTTPS requests
Database writes
Three accounts and two local tools cover the complete setup
03
1
Google Cloud
Runs containers, stores secrets, schedules the pipeline
cloud.google.com
2
Supabase
Hosts PostgreSQL and the pgvector extension
supabase.com
3
OpenAI
Provides enrichment and embedding API access
platform.openai.com
Local prerequisites
Docker Desktop
Google Cloud CLI
A billing account is required for Google Cloud, even when usage stays inside free allowances.
A working local application provides the baseline for deployment
04
1
Canonical schema
One NewsItem shape across scraping, enrichment, storage and API responses
2
Separate entry points
app.main serves HTTP; app.pipeline performs batch processing
3
Environment file
.env supplies DATABASE_URL and OPENAI_API_KEY during local development
uv sync
uv run python -m app.database.create_tables
uv run uvicorn app.main:app --reload
Local checks
Open http://127.0.0.1:8000/docs and verify the endpoints before introducing cloud infrastructure.
Docker creates one reproducible package for local and cloud execution
05
FROM python:3.12-slim
WORKDIR /app
RUN pip install --no-cache-dir uv
COPY pyproject.toml uv.lock ./
RUN uv sync --frozen --no-dev
COPY app ./app
ENV PATH="/app/.venv/bin:$PATH"
CMD ["sh", "-c", "uvicorn app.main:app --host 0.0.0.0 --port ${PORT:-8080}"]
Dependencies
uv installs the locked Python environment
Network
Uvicorn listens on 0.0.0.0 and Cloud Run's PORT
Entrypoint
The default container starts the FastAPI service
docker build -t ai-news-api .
docker run --rm --env-file .env -e PORT=8080 -p 8080:8080 ai-news-api
Supabase supplies PostgreSQL and pgvector without a Cloud SQL instance
06
1
Create
Free Supabase project
2
Enable
vector extension
3
Connect
Session pooler URI
4
Initialize
project tables
DATABASE_URL=postgresql://postgres.PROJECT_REF:PASSWORD@POOLER_HOST:5432/postgres?sslmode=require
uv run python -c "from sqlalchemy import text; from app.database.connection import engine; c=engine.connect(); print(c.execute(text('SELECT version()')).scalar()); c.close()"
uv run python -m app.database.create_tables
news_items
news_chunks
vector enabled
Enabling all required APIs
07
gcloud auth login
gcloud config set project YOUR_PROJECT_ID
gcloud services enable \
+ run.googleapis.com \
+ cloudbuild.googleapis.com \
+ artifactregistry.googleapis.com \
+ secretmanager.googleapis.com \
+ cloudscheduler.googleapis.com
1
Cloud Run
Container service and batch job
2
Cloud Build
Build image from source
3
Artifact Registry
Store container image
4
Secret Manager
Store credentials
5
Cloud Scheduler
Trigger weekly execution
Lesson learned
The Scheduler console showed “no access” until cloudscheduler.googleapis.com was enabled for this project.
Secret Manager keeps database and OpenAI credentials outside the image
08
●
database-url
Complete Supabase connection URI
Paste only the value
●
openai-api-key
OpenAI project API key
Paste only the value
Cloud Run
service account
gcloud secrets add-iam-policy-binding openai-api-key \
+ --member="serviceAccount:314655597972-compute@developer.gserviceaccount.com" \
+ --role="roles/secretmanager.secretAccessor"
gcloud secrets add-iam-policy-binding database-url \
+ --member="serviceAccount:314655597972-compute@developer.gserviceaccount.com" \
+ --role="roles/secretmanager.secretAccessor"
The service account represents the running container, not the human deploying it.
Cloud Run deploys the FastAPI service and provides a managed HTTPS endpoint
09
gcloud run deploy ai-news-api \
+ --source . \
+ --region europe-west1 \
+ --allow-unauthenticated \
+ --min-instances=0 \
+ --max-instances=1 \
+ --memory=512Mi \
+ --cpu=1 \
+ --set-secrets="DATABASE_URL=database-url:latest,OPENAI_API_KEY=openai-api-key:latest"
Cloud Run handles
✓
Server provisioning
✓
HTTPS certificate
✓
Public routing
✓
Restarts and scaling
curl https://YOUR_CLOUD_RUN_URL/health/
# Also verify /docs, /news/ and /search/
A separate Cloud Run Job runs the pipeline once and then exits
10
Cloud Run Service
Command: uvicorn app.main:app
Purpose: answer HTTP requests
Lifecycle: scales with traffic
Cloud Run Job
Command: python -m app.pipeline
Purpose: write fresh data
Lifecycle: runs and exits
gcloud run jobs execute ai-news-pipeline --region=europe-west1 --wait
5
articles
39
chunks
1
successful manual run
Cloud Scheduler triggers the pipeline through the Cloud Run Jobs API
11
Create a Scheduler job
Configure the execution
Target type
HTTP
URL
run.googleapis.com/.../ai-news-pipeline:run
HTTP method
POST
Auth header
Add OAuth token
Configure the scheduler target
Target type
HTTP
Method
POST
Authentication
OAuth token
Service account
314655597972-compute@developer.gserviceaccount.com
https://run.googleapis.com/v2/projects/YOUR_PROJECT_ID/locations/europe-west1/jobs/ai-news-pipeline:run
gcloud run jobs add-iam-policy-binding ai-news-pipeline \
+ --region=europe-west1 \
+ --member="serviceAccount:314655597972-compute@developer.gserviceaccount.com" \
+ --role="roles/run.invoker"
A short verification chain proves that every deployed component works
12
1
API
curl .../health/
2
Database
Check news_items and news_chunks
3
Pipeline
List Cloud Run executions
4
Schedule
Force-run the Scheduler job
gcloud run services logs read ai-news-api --region=europe-west1 --limit=100
gcloud run jobs executions list --job=ai-news-pipeline --region=europe-west1
gcloud scheduler jobs run ai-news-pipeline-weekly --location=europe-west1
Expected result: a new successful pipeline execution and fresh rows in Supabase
Free allowances help with learning, but explicit limits prevent surprises
13
1
Scale to zero
Keep Cloud Run minimum instances at 0
2
Cap instances
Keep maximum instances at 1 while testing
3
Budget alerts
Create alerts at 50%, 90% and 100%
4
Clean images
Remove old Artifact Registry revisions
Important
Budget alerts warn you; they do not automatically stop spending. OpenAI usage is billed separately.
The completed system now collects and serves AI news automatically
14
1
Collect
Hacker News scraper
2
Enrich
OpenAI summary + tags
3
Index
Chunks + embeddings
4
Store
Supabase pgvector
5
Serve
Cloud Run FastAPI
Deployed resources
ai-news-api · ai-news-pipeline · ai-news-pipeline-weekly
Next improvement: protect costly endpoints and add monitoring before broader use.
Front end..and simpler alternatives?
13
Try Streamlit