The Deployment Pillar — From “Localhost” to the Global Edge

In Article 1, we built the brain and the face of our RAG app. It worked perfectly on my machine. But as every developer knows, “it works on my machine” are the famous last words of a project.

The second pillar of application development is Deployment. My goal was simple: I wanted a “Push to Deploy” workflow. I didn’t want to manually click around the AWS Console every time I fixed a typo. Here is how I built a professional CI/CD pipeline and survived the “Cloud Bosses” (AWS App Runner and CloudFront).

1. The Hands-Free Workflow: GitHub Actions & OIDC

I didn’t want to store permanent AWS Access Keys in GitHub Secrets — that’s a security nightmare. Instead, I opted for OIDC (OpenID Connect). This allows GitHub to “handshake” with AWS using short-lived, temporary tokens.

But here’s the secret: I didn’t manually write the complex YAML configurations for this. I used Agentic tools to generate my entire CI/CD pipeline.

• The Backend YAML: The AI generated a script that builds my Docker image, pushes it to Amazon ECR, and triggers an App Runner deployment.
• The Frontend YAML: A separate agentic-generated script that builds my React app and syncs the static files to Amazon S3.

2. AWS App Runner: The “Goldilocks” of Compute

I chose AWS App Runner because it’s the perfect middle ground. It’s easier than managing a full Kubernetes cluster but more powerful than a simple Lambda function.

• Auto-Scaling: If 100 people suddenly start asking questions to my RAG app, App Runner spins up more instances automatically.
• Health Checks: This is where my /health endpoint from Article 1 saved me. App Runner uses this "heartbeat" to verify the container is healthy before routing traffic.

3. The Performance Multiplier: Amazon CloudFront

To ensure the app loaded instantly worldwide, I placed Amazon CloudFront in front of everything.

• The Unified Domain: CloudFront serves my React files from the “Edge” and routes any request starting with /api/* to the App Runner backend.
• Consistency: This setup ensures that the URL my users see stays the same, even if I restart or update the backend services.

4. The “Trial by Fire”: 502 Errors & CORS Wars

Deployment is never “one-and-done.” I hit two major roadblocks that almost made me quit:

The 502 Bad Gateway Mystery

After my first deploy, I got a 502 Bad Gateway.

• The Discovery: It wasn’t my code; it was the Port. App Runner expects your container to listen on port 8080 by default, but my FastAPI app was “talking” on 8000.
• The Fix: I used an AI agent to help me reconfigure my Docker environment variables, and the 502 vanished.

The CORS Preflight Battle

Even after the 502 was gone, my frontend couldn’t talk to my backend. The browser would block the request because of CORS.

• The Solution: I had to configure CloudFront to forward the “Origin” header to the backend. Without that header, my FastAPI CORSMiddleware didn't know the request was coming from a trusted source and would reject it.

The “Agentic” Infrastructure

I’m not a DevOps engineer. Setting up IAM roles and CloudFront Cache Behaviors is dense, high-stakes work. By using AI as my Infrastructure-as-Code consultant, I moved from a broken deployment to a live URL in record time. I provided the error logs, and the AI pointed out exactly which AWS toggle was misconfigured.

Deployment isn’t about knowing every AWS service; it’s about knowing how to debug the connection between them.

In the final article, we’ll move from the “how” to the “show.” I’ll talk about the Storytelling Pillar: how I used AI to build a high-impact slide deck to pitch this entire project.