deploying-applications

# Deploying Applications

Production deployment patterns from Kubernetes to serverless and edge functions. Bridges the gap from application assembly to production infrastructure.

## Purpose

This skill provides clear guidance for:
- Selecting the right deployment strategy (Kubernetes, serverless, containers, edge)
- Implementing Infrastructure as Code with Pulumi or OpenTofu
- Setting up GitOps automation with ArgoCD or Flux
- Choosing serverless databases (Neon, Turso, PlanetScale)
- Deploying edge functions (Cloudflare Workers, Deno Deploy)

## When to Use This Skill

Use this skill when:
- Deploying applications to production infrastructure
- Setting up CI/CD pipelines and GitOps workflows
- Choosing between Kubernetes, serverless, or edge deployment
- Implementing Infrastructure as Code (Pulumi, OpenTofu, SST)
- Migrating from manual deployment to automated infrastructure
- Integrating with `assembling-components` for complete deployment flow

## Deployment Strategy Decision Tree

```
WORKLOAD TYPE?

├── COMPLEX MICROSERVICES (10+ services)
│   └─ Kubernetes + ArgoCD/Flux (GitOps)
│       ├─ Helm 4.0 for packaging
│       ├─ Service mesh: Linkerd (5-10% overhead) or Istio (25-35%)
│       └─ See references/kubernetes-patterns.md

├── VARIABLE TRAFFIC / COST-SENSITIVE
│   └─ Serverless
│       ├─ Database: Neon/Turso (scale-to-zero)
│       ├─ Compute: Vercel, AWS Lambda, Cloud Functions
│       ├─ Edge: Cloudflare Workers (<5ms cold start)
│       └─ See references/serverless-dbs.md and references/edge-functions.md

├── CONSISTENT LOAD / PREDICTABLE TRAFFIC
│   └─ Containers (ECS, Cloud Run, Fly.io)
│       ├─ ECS Fargate: AWS-native, serverless containers
│       ├─ Cloud Run: GCP, scale-to-zero containers
│       └─ Fly.io: Global edge, multi-region

├── GLOBAL LOW-LATENCY (<50ms)
│   └─ Edge Functions + Edge Database
│       ├─ Cloudflare Workers + D1 (SQLite)
│       ├─ Deno Deploy + Turso (libSQL)
│       └─ See references/edge-functions.md

└── RAPID PROTOTYPING / STARTUP MVP
    └─ Managed Platform as a Service
        ├─ Vercel (Next.js, zero-config)
        ├─ Railway (any framework)
        └─ Render (auto-deploy from Git)

IaC CHOICE?

├─ TypeScript-first → Pulumi (Apache 2.0, multi-cloud)
├─ HCL-based → OpenTofu (CNCF, Terraform-compatible)
└─ Serverless TypeScript → SST v3 (built on Pulumi)
```

## Core Concepts

### Infrastructure as Code (IaC)

Define infrastructure using code instead of manual configuration.

**Primary: Pulumi (TypeScript)**
- Context7 ID: `/pulumi/docs` (Trust: 94.6/100, 9,525 snippets)
- TypeScript-first (same language as React/Next.js)
- Multi-cloud support (AWS, GCP, Azure, Cloudflare)
- See references/pulumi-guide.md for patterns and examples

**Alternative: OpenTofu (HCL)**
- CNCF project, Terraform-compatible
- MPL-2.0 license (open governance)
- Drop-in Terraform replacement
- See references/opentofu-guide.md for migration

**Serverless: SST v3 (TypeScript)**
- Built on Pulumi
- Optimized for AWS Lambda, API Gateway
- Live Lambda development

### GitOps Deployment

Declarative infrastructure with Git as source of truth.

**ArgoCD** (Recommended for platform teams):
- Rich web UI
- Built-in RBAC and multi-tenancy
- Self-healing deployments
- See references/gitops-argocd.md

**Flux** (Recommended for DevOps automation):
- Kubernetes-native
- CLI-focused
- Simpler architecture
- See references/gitops-argocd.md

### Service Mesh

Optional layer for microservices communication, security, and observability.

**When to Use Service Mesh**:
- Multi-team microservices (security boundaries)
- Zero-trust networking (mTLS required)
- Advanced traffic management (canary, blue-green)

**When NOT to Use**:
- Simple monolith or 2-3 services (overhead not justified)
- Serverless architectures (incompatible)

**Linkerd** (Performance-focused):
- 5-10% overhead
- Rust-based
- Simple, opinionated

**Istio** (Feature-rich):
- 25-35% overhead
- C++ (Envoy)
- Advanced routing, observability

See references/kubernetes-patterns.md for service mesh patterns.

## Quick Start Workflows

### Workflow 1: Deploy Next.js to Vercel (Zero-Config)

```bash
# Install Vercel CLI
npm i -g vercel

# Link project
vercel link

# Deploy to production
vercel --prod
```

See examples/nextjs-vercel/ for complete example.

### Workflow 2: Deploy to Kubernetes with ArgoCD

1. Create Helm chart
2. Push chart to Git repository
3. Create ArgoCD Application
4. ArgoCD syncs automatically

See examples/k8s-argocd/ for complete GitOps setup.

### Workflow 3: Deploy Serverless with Pulumi

```typescript
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// Create Lambda function
const lambda = new aws.lambda.Function("api", {
    runtime: "nodejs20.x",
    handler: "index.handler",
    role: role.arn,
    code: new pulumi.asset.FileArchive("./dist"),
});

export const apiUrl = lambda.invokeArn;
```

See examples/pulumi-aws/ and references/pulumi-guide.md for patterns.

### Workflow 4: Deploy Edge Function to Cloudflare Workers

```typescript
import { Hono } from 'hono'

const app = new Hono()

app.get('/api/hello', (c) => {
  return c.json({ message: 'Hello from edge!' })
})

export default app
```

Deploy with Wrangler:
```bash
wrangler deploy
```

See examples/cloudflare-workers-hono/ and references/edge-functions.md.

## Integration with assembling-components

After building an application with `assembling-components`, this skill provides deployment patterns:

**Frontend (Next.js/Vite) → Deployment**:
1. Review deployment decision tree
2. Choose platform: Vercel (Next.js), Cloudflare Pages (static), or custom (Pulumi)
3. Set up environment variables
4. Deploy using chosen method

**Backend (FastAPI/Axum) → Deployment**:
1. Containerize application (Dockerfile)
2. Choose platform: ECS Fargate, Cloud Run, or Kubernetes
3. Set up IaC (Pulumi or OpenTofu)
4. Deploy with GitOps (ArgoCD/Flux) or CI/CD

See references/pulumi-guide.md for integration examples.

## Reference