Part 2: From $68/month to $5/month - The "Lite" Deployment Strategy

TL;DR

My Cloud Portfolio Challenge implementation costs $68 per month on Digital Ocean. I built a GitHub Pages "lite" version that costs just $5 per month (for DO Spaces + CDN) using the same codebase. Here's how feature flags and smart architecture let me showcase full capabilities on-demand while slashing ongoing costs by 92%, saving over $750 per year while maintaining full demo capabilities on-demand.

This post is part of my #CloudGuruChallenge series. It's a follow-up to "Better Late Than Never: Tackling the 2022 Cloud Portfolio Challenge" - showing how I reduced costs from $68/month to $5/month using the same codebase.

The Problem: When Reality Hits Your Wallet

Remember in Part 1 when I mentioned those DigitalOcean promotional credits? Yeah, they expired. And that feeling when you realize your portfolio project is costing you $68 per month to keep running? That's... not ideal.

Let's break down what I was paying for:

• 
  Load Balancer: $12 per month


• 
  2 Droplets (full-stack servers): $18 per month each = $36 per month


• 
  Valkey Database: $15 per month


• 
  DO Spaces + CDN: $5 per month

Total: $68 per month for a portfolio project that might get viewed once a week during interview seasons.

That's when I had a thought: What if I could keep the impressive architecture for demos but run at minimal cost 99% of the time?

The Solution: GitHub Pages "Lite" Mode

Enter the dual-deployment strategy. Same codebase, two completely different deployment targets:

1. 
   Full Deployment (Digital Ocean): All the bells and whistles - AI generation, live voting, cross-session tracking


2. 
   Lite Deployment (GitHub Pages): Static site with gracefully degraded features - local voting, pre-generated images

The magic? Feature flags that configure everything at build time.

The Architecture Decision

Instead of maintaining two separate codebases (nightmare fuel), I built a feature flag system that lets Next.js adapt based on NEXT_PUBLIC_DEPLOYMENT_MODE:

Full Mode (frontend/.env.full):

NEXT_PUBLIC_DEPLOYMENT_MODE=full

NEXT_PUBLIC_API_URL=https://api.wheeleraiduel.online

NEXT_PUBLIC_USE_STATIC_DATA=false

Lite Mode (frontend/.env.lite):

NEXT_PUBLIC_DEPLOYMENT_MODE=lite

NEXT_PUBLIC_API_URL=

NEXT_PUBLIC_USE_STATIC_DATA=true

The frontend reads these flags and swaps out implementations:

// frontend/app/services/dataService.ts

export const dataService = config.useStaticData

  ? staticDataService  // Reads from JSON files

  : apiDataService;    // Calls backend API

Same React components, different data sources. Clean, testable, maintainable.

Why Cost-Conscious Matters

Here's the thing about cloud deployments: they're running 24/7 whether you're using them or not. My project gets meaningful traffic maybe 2-3 days a month during demo calls or when I share it on LinkedIn.

Old strategy: Pay $68 per month regardless of usage

New strategy: Pay $5 per month baseline + demo costs only when needed

• 
  The only ongoing cost: $5 per month for DO Spaces + CDN (stores all images)


• 
  GitHub Pages hosting: $0 per month (completely free)


• 
  Full infrastructure: Only spin up for demos (~$2-3 per day, prorated hourly)

That's a 92% monthly cost reduction ($68 → $5) while maintaining the ability to showcase full capabilities when it matters.

Why keep DO Spaces? Both deployments need the images anyway. Spaces serves as the single source of truth with built-in CDN, so it's worth the $5 whether I'm running full or lite mode.

Annual math: Base cost of $60/year ($5 × 12 months) plus occasional demo costs. Even with 10-15 demo days per year, you're looking at ~$90-120/year instead of $816/year.

The GitHub Actions Workflow

The cheap-deploy.yml workflow is beautifully simple:

name: Deploy to GitHub Pages (Lite)



on:

  workflow_dispatch:



jobs:

  build:

    name: Build Lite Frontend

    runs-on: ubuntu-latest



    steps:

    - name: Checkout code

      uses: actions/checkout@v4



    - name: Setup Node.js

      uses: actions/setup-node@v4

      with:

        node-version: '18'



    - name: Generate static data from DO Spaces

      run: |

        echo "📡 Fetching real image pairs from DO Spaces..."

        node .github/scripts/generate-static-data.js



    - name: Install frontend dependencies

      working-directory: frontend

      run: npm ci



    - name: Build frontend in lite mode

      working-directory: frontend

      run: npm run build:lite



    - name: Upload artifact

      uses: actions/upload-pages-artifact@v3

      with:

        path: frontend/out



  deploy:

    name: Deploy to GitHub Pages

    environment:

      name: github-pages

      url: ${{ steps.deployment.outputs.page_url }}

    runs-on: ubuntu-latest

    needs: build



    steps:

    - name: Deploy to GitHub Pages

      id: deployment

      uses: actions/deploy-pages@v4

Key insight: The static data is generated automatically from DO Spaces. I don't manually maintain two sets of images. The build script fetches metadata from my DO Spaces bucket (which I keep running at $5 per month for the CDN anyway) and generates the image-pairs.json file at build time.

The Demo-Ready Strategy

Here's my actual workflow when I have an interview or want to showcase the full project:

Before the demo (20 minutes):

# 1. Deploy full infrastructure

Actions → pricy-deploy.yml → Run workflow (droplet_count: 2)



# 2. Wait ~8 minutes for deployment



# 3. Switch DNS to Digital Ocean

Actions → dns-cutover.yml → Run workflow (target: digital-ocean)



# 4. Wait 5-10 minutes for DNS propagation

After the demo (5 minutes):

# 1. Switch DNS back to GitHub Pages

Actions → dns-cutover.yml → Run workflow (target: github-pages)



# 2. Tear down all DO infrastructure

Actions → pricy-teardown.yml → Run workflow (confirm: DELETE PRICY)

Two quick workflows, and you're back to the $5/month baseline. The whole demo cycle costs about $2-3 (hourly prorated billing), and I can repeat this as many times as needed.

What You Lose (and What You Don't)

Features removed in lite mode:

• ❌ AI image generation


• ❌ Cross-session vote tracking


• ❌ Live statistics across users


• ❌ Backend API

Features preserved in lite mode:

• ✅ Same UI/UX


• ✅ Local voting (localStorage)


• ✅ Real images from DO Spaces CDN


• ✅ Mobile-optimized swipe interface


• ✅ Winners tracking (per browser)

For a portfolio project, the lite version is perfectly sufficient 95% of the time. Nobody really needs to generate new AI images when browsing my portfolio at 2am. They just need to see that the project works and looks professional.

Production-Grade Practices (The Real Portfolio Value)

Here's what this dual-deployment strategy demonstrates to recruiters:

1. Feature Flags & Configuration Management

Build-time feature flags allow a single codebase to serve multiple deployment targets. This is how real companies handle staging/production differences.

2. Blue/Green Deployment

Both deployments run simultaneously. I can test the lite version independently before cutting over DNS. Zero-downtime switching between environments.

3. Cost Optimization

Understanding cloud economics and implementing strategies to minimize costs while maintaining capabilities shows business acumen, not just technical skills.

4. Infrastructure as Code

The full deployment uses Pulumi. The lite deployment uses GitHub Actions. Both are reproducible, version-controlled, and automated.

5. Graceful Degradation

The frontend adapts intelligently to available backend services. This is critical for resilient production systems.

The Numbers

*Plus demo costs if/when you spin up full infrastructure

Was It Worth It?

Absolutely. I now have:

• ✅ A $5 per month portfolio deployment running 24/7


• ✅ Full feature showcase available on-demand


• ✅ Real-world experience with feature flags


• ✅ Blue/green deployment practice


• ✅ Cost optimization case study for interviews

And I'm saving $63 per month (92% reduction) while maintaining the ability to demonstrate the full project during interviews.

The Challenge: Your Turn

Think this approach could work for your cloud portfolio project? The patterns here apply to any dual-deployment scenario:

• Full vs. lite


• Production vs. preview


• US region vs. EU region


• Premium features vs. free tier

The 2022 Cloud Portfolio Challenge is still out there, still relevant in 2025. And now you have a cost-effective strategy for keeping it running without breaking the bank.

Connect & Build

Want to discuss cloud architecture, cost optimization strategies, or your own portfolio projects? Find me on LinkedIn - I'm always happy to connect with fellow builders.

Or better yet: Attempt the challenge yourself. Build something, deploy it two ways, and show recruiters you understand both technical excellence and business value. That's the real portfolio flex.

Repository: github.com/wheeleruniverse/cgc-lb-and-cdn

This post is part of my #CloudGuruChallenge series. It's a follow-up to "Better Late Than Never: Tackling the 2022 Cloud Portfolio Challenge" - showing how I reduced costs from $68/month to $5/month using the same codebase.