Multi-Cloud Deployment in Production: Cloud Run, Railway, Oracle Cloud

Published on: 2026-06-06

Reading time: 10 min

Tags: #devops #cloud #fastapi #production

Situation

I deployed 3 FastAPI projects to 3 different clouds. Here's what actually happened (not marketing speak):

contest-agent      → Google Cloud Run
ai-insight-curator → Railway
ai-lifelogger      → Oracle Cloud Always Free

1. Google Cloud Run: 20+ Deployments Before Discovering the Real Problem

Issue: "Container Failed to Start"

Deployed 20+ times, same error every time:

Build: SUCCESS ✅
Push: SUCCESS ✅
Start: TIMEOUT ❌
Port 8080 binding: TIMEOUT ❌

Root cause: FastAPI startup was blocking port binding with I/O operations

# ❌ Problem code (startup blocks port binding)
@asynccontextmanager
async def lifespan(app: FastAPI):
    await telegram_client.send_message("Starting...")  # I/O blocking
    db_check = await db.test_connection()              # I/O blocking  
    scheduler.start()                                   # Heavy init
    yield

Cloud Run waits for port binding to complete before health checks. Startup blocking = timeout.

Solution: Lazy Loading

# ✅ Fixed code (startup returns immediately)
_initialized = False

async def lazy_init():
    global _initialized
    if _initialized:
        return
    _initialized = True
    await telegram_client.send_message("Started")
    scheduler.start()

@app.post("/webhook")
async def webhook(request: Request):
    await lazy_init()  # Init on first actual request
    ...

Result: Startup 100ms (was 60s+ timeout), port binding immediate, health check passes.

Key Lesson: Start Minimal

Don't deploy a complex system all at once. Lessons learned:

# Phase 1: Just "/" endpoint
@app.get("/")
async def root():
    return {"status": "ok"}
# → Deploy, test, pass ✅

# Phase 2: Add health check
@app.get("/health")
async def health():
    return {"status": "healthy"}
# → Deploy, test, pass ✅

# Phase 3-N: Gradually add features
# Each phase = one deployment test

2. Railway: The "Simple" Illusion

Advantages

Git push → auto-deploy (very fast)
PostgreSQL, Redis built-in
Intuitive dashboard

Reality Check

Cost surprises:

Expected: $10/month
Actual: $25/month (250% overage)

Reason:
- 1 vCPU + 512MB RAM always running
- No cold start = memory always consumed
- Bandwidth costs added up

Memory leak detection is hard:

Hour 1: 150MB ✅
Hour 2: 180MB
Hour 3: 220MB
Hour 4: 260MB (OOM incoming)

Cause: RSS feed crawler not releasing memory

Auto-deploy is a double-edged sword:

Con: Changes go live without testing
Con: Need fast rollback procedure

How I Actually Operate It

# Before pushing to main:
pytest              # Run tests
pylint             # Lint check
docker build && docker run  # Local test

# Only push after passing:
git push origin main  # Auto-deploys

3. Oracle Cloud Always Free: Free but Demanding

Advantages

Completely free (4 CPU, 24GB RAM, 200GB storage)
No limits
Full SSH control

Real Problems

Problem #1: 1GB instance, pip install fails

MemoryError during pip install

Reason: 1GB RAM instance can't handle 
all packages at once

Solution:

# Add swap
sudo fallocate -l 8G /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Or: Install only essentials
pip install --no-cache-dir anthropic supabase python-telegram-bot

Problem #2: Docker vs Local Mismatch

Local: anthropic==0.40.0 (already installed)
Docker: Fresh install reads requirements.txt
  - anthropic==0.40.0
  - langchain-anthropic needs anthropic>=0.41.0
  → pip can't resolve

Solution: Remove version pins, let pip resolve

DON'T: anthropic==0.40.0, supabase==2.0.0, ...
DO: anthropic, supabase (let pip figure it out)

Problem #3: SSH Deployment Needs Automation

# Manual (every time):
ssh oracle@your-ip
cd /opt/ai-lifelogger
git pull && systemctl restart

# Better (automated via GitHub Actions):
ssh -i $key oracle@$ip "cd /opt && git pull && systemctl restart"

Performance Comparison (3-Month Data)

Metric	Cloud Run	Railway	Oracle
Deploy time	2-3 min	30 sec	5 min
Cold start	3-5 sec	0 sec	<1 sec
Monthly cost	$15	$25	$0
CPU limit	2 cores	1 core	4 cores
RAM limit	2GB	512MB	24GB
Stability	✅ Solid	⚠️ Memory issues	✅ Solid

Practical Advice

1. Start Minimal, Add Gradually

Deploy "/" endpoint first
Test, pass, add next feature
Repeat

2. Always Test Locally

docker build -t myapp .
docker run -p 8080:8080 myapp

3. Choose Based on Use Case

High traffic: Cloud Run (autoscales)
Medium traffic: Railway (simple)
Low traffic: Oracle (free)

4. Monitoring is Non-Negotiable

Cloud Run: GCP Logs + Cloud Monitoring
Railway: Built-in dashboard (limited)
Oracle: SSH → journalctl + tail -f

What I Learned

There's no "perfect" platform.

Cloud Run: startup timeout (solvable with lazy loading)
Railway: memory leaks (code issue, not platform)
Oracle: operational overhead (worth it for free tier)

The real skill: Understanding each platform's constraints and designing around them.

The 20+ Cloud Run deployment failures? They taught me more than 10 successful deployments would have.

Final Deployment Architecture (June 7, 2026)

Production Status

🦅 Oracle Cloud (Always Free Tier)
├─ ai-lifelogger (port 8000)
│  ├─ FastAPI + APScheduler
│  ├─ Daily summaries: 05:00 KST
│  ├─ Weekly reviews: Sunday 08:00 KST
│  └─ Memory: 111MB / 954MB
│
└─ ai-insight-curator (port 8001)
   ├─ FastAPI + Telegram Bot
   ├─ RSS collection: Daily 06:00 KST
   ├─ Auto-summarization (Claude/Gemini/Groq fallback)
   └─ Memory: 22MB / 954MB

🌐 Vercel (Free Hosting)
└─ Curator Web Dashboard
   ├─ React + Vite frontend
   ├─ Article search & filtering
   ├─ Image downloads
   └─ https://curator-web-ui.vercel.app

📊 Total Memory: 537MB / 954MB (56% usage, 44% available)

What Changed

Initial Plan:

contest-agent → Cloud Run ❌ (dependency conflicts)
ai-insight-curator → Railway ❌ (over-engineered)
ai-lifelogger → Oracle Cloud ✅

Actual Production:

ai-lifelogger → Oracle Cloud ✅ (running)
ai-insight-curator → Oracle Cloud ✅ (1 instance = better)
Curator Web UI → Vercel ✅ (new, auto-deployed)

Key Insight: Single server + Web UI > Multi-cloud complexity

Performance Metrics

API Response Times:
- Lifelogger /health: < 50ms ✅
- Curator /api/v1/articles: < 100ms ✅
- Curator /api/v1/insights: < 100ms ✅

System Health:
- Memory: 537MB (56%) - 417MB free for scaling
- Availability: 99.9%
- Uptime: Continuous (Always Free tier)

Cost Analysis (Final)

Platform	Cost	Status
Oracle Cloud	$0/month	✅ Always Free
Vercel	$0/month	✅ Free tier
Supabase DB	$0/month	✅ Free tier
Claude API	Needs reset*	⚠️ Using Gemini/Groq backup
TOTAL	$0/month	Forever Free

*Anthropic tokens exhausted → fallback to Gemini/Groq working

Lessons Learned

Multi-cloud Isn't Always Better

Cloud Run: Good for high-traffic APIs
Railway: Convenient but expensive
Oracle: Best for low-traffic, cost-sensitive projects

Single Server Wins Here

2 concurrent FastAPI services
Database included (PostgreSQL via Supabase)
Web dashboard on separate CDN (Vercel)
Total cost: $0

Design Around Constraints

Memory: 954MB available → deployed with 537MB usage
Can still run 300MB+ additional services
Monitoring via SSH (not ideal, but works)

Conclusion

Don't chase multi-cloud complexity.

The optimal deployment turned out to be:

1 Oracle Cloud instance (FastAPI services)
1 CDN (Vercel for web)
1 Database (Supabase)
Everything free

Cost: $0/month ✅
Reliability: 99.9% ✅
Maintainability: Simple ✅

Sometimes simpler is better.