igny8/docs/DEPLOYMENT_ARCHITECTURE.md

Deployment Architecture Analysis

Current Setup

Domain Routing

• app.igny8.com → Vite dev server container (igny8_frontend:5173)

  • Live reload enabled
  • Development mode
  • Changes reflect immediately

• igny8.com → Static files from /var/www/igny8-marketing

  • Production marketing site
  • Requires manual build + copy to update
  • No containerization

Current Issues

1. ❌ Marketing site deployment is manual (not containerized)
2. ❌ No automated deployment process
3. ❌ Dev changes affect app.igny8.com but not igny8.com (confusing)
4. ⚠️ Marketing site not versioned with codebase

---

Option Comparison

Option A: Separate Containers (Recommended ✅)

Structure:

igny8_frontend_dev    → app.igny8.com (Vite dev server)
igny8_frontend_prod   → app.igny8.com (Production build, optional)
igny8_marketing       → igny8.com (Marketing static site)

Pros:

• ✅ Clear separation of concerns
• ✅ Independent scaling and updates
• ✅ Marketing site can be updated without affecting app
• ✅ Production app can be containerized separately
• ✅ Better security isolation
• ✅ Easier CI/CD automation
• ✅ Version control for marketing deployments

Cons:

• ⚠️ Slightly more complex docker-compose setup
• ⚠️ Need to manage 2-3 containers instead of 1

Implementation:

services:
  igny8_frontend_dev:
    # Current dev server for app.igny8.com
    image: igny8-frontend-dev:latest
    ports: ["8021:5173"]
    
  igny8_marketing:
    # Production marketing site for igny8.com
    image: igny8-marketing:latest
    build:
      context: ./frontend
      dockerfile: Dockerfile.marketing
    volumes:
      - marketing_static:/usr/share/caddy:ro

---

Option B: Current Approach (Keep Manual)

Structure:

igny8_frontend_dev → app.igny8.com (Vite dev server)
/var/www/igny8-marketing → igny8.com (Manual static files)

Pros:

• ✅ Simple (already working)
• ✅ No additional containers
• ✅ Fast static file serving

Cons:

• ❌ Manual deployment process
• ❌ No version control for marketing site
• ❌ Hard to rollback
• ❌ Not containerized (harder to manage)
• ❌ Deployment not reproducible

---

Option C: Unified Production Build

Structure:

Single container serves both app and marketing from same build

Pros:

• ✅ Single container to manage
• ✅ Both sites from same codebase

Cons:

• ❌ Can't update marketing without rebuilding app
• ❌ Larger container size
• ❌ Less flexible deployment
• ❌ Dev server still separate anyway

---

Recommendation: Option A - Separate Containers

Why This Is Better:

1. Production-Ready App Container

   • Can deploy production build of app to app.igny8.com when needed
   • Dev container for development, prod container for production

2. Containerized Marketing Site

   • Marketing site becomes a proper container
   • Easy to update: rebuild image, restart container
   • Version controlled deployments
   • Rollback capability

3. Clear Separation

   • Dev environment: igny8_frontend_dev → app.igny8.com
   • Production app: igny8_frontend_prod → app.igny8.com (when ready)
   • Marketing site: igny8_marketing → igny8.com

4. Better CI/CD

   • Can deploy marketing site independently
   • Can deploy app independently
   • Automated builds and deployments

5. Scalability

   • Each service can scale independently
   • Better resource management

---

Implementation Plan

Step 1: Create Marketing Dockerfile

# frontend/Dockerfile.marketing
FROM node:18-alpine AS builder
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build:marketing

FROM caddy:latest
COPY --from=builder /app/dist /usr/share/caddy
COPY Caddyfile.marketing /etc/caddy/Caddyfile
EXPOSE 8020
CMD ["caddy", "run", "--config", "/etc/caddy/Caddyfile"]

Step 2: Create Marketing Caddyfile

# frontend/Caddyfile.marketing
:8020 {
    root * /usr/share/caddy
    try_files {path} /marketing.html
    file_server
}

Step 3: Update docker-compose.app.yml

Add marketing service alongside frontend dev service.

Step 4: Update Main Caddyfile

Point igny8.com to igny8_marketing:8020 instead of static files.

---

Migration Path

1. Phase 1: Add marketing container (keep current setup working)
2. Phase 2: Test marketing container on staging domain
3. Phase 3: Switch igny8.com to use container
4. Phase 4: Remove manual /var/www/igny8-marketing setup

---

Conclusion

Separate containers (Option A) is the best long-term solution because:

• ✅ Production-ready architecture
• ✅ Better DevOps practices
• ✅ Easier maintenance
• ✅ Scalable and flexible
• ✅ Industry standard approach

The current setup works but is not ideal for production. Separate containers provide better separation, versioning, and deployment automation.