Deployment (Cloudflare & Alchemy)
Relevant source files
The following files were used as context for generating this wiki page:
- README.md
- AGENTS.md
- apps/web/src/app/(marketing)/dpa/page.tsx/dpa/page.tsx)
- apps/web/src/app/(marketing)/privacy/page.tsx/privacy/page.tsx)
- loops-email-collection.md
KudosWall leverages a modern cloud-native deployment strategy focused on edge computing and high-performance serverless infrastructure. The system is designed as a high-performance monorepo SaaS application that bridges the gap between web speed and enterprise reliability through localized edge requests and serverless connection pooling.
The deployment architecture primarily utilizes Cloudflare for edge computing, storage, and proxying, while integrating with Alchemy (via packages/infra) for infrastructure management and deployment configurations. This setup ensures zero-latency edge requests routed via a lightweight serverless proxy handler.
Sources: README.md:46-51, README.md:118-120, AGENTS.md:65-67
Infrastructure & Platform Providers
KudosWall distributes its service across several specialized cloud providers to ensure compliance with global data protection standards like GDPR and CCPA.
Core Cloud Stack
| Provider | Purpose | Deployment Context |
|---|---|---|
| Cloudflare | Edge Proxy, R2 Storage, DNS | Handles asset delivery and media signing |
| Vercel | Hosting & Edge Functions | Primary hosting for Next.js 16 application |
| Neon | Serverless PostgreSQL | Database client with connection pooling |
| Alchemy | Deployment Configs | Managed via packages/infra |
| Upstash | Redis / Rate Limiting | Global low-latency state management |
Sources: README.md:118-120, apps/web/src/app/(marketing)/dpa/page.tsx:112-132, apps/web/src/app/(marketing)/privacy/page.tsx:106-115
Deployment Architecture
The monorepo structure is governed by Turborepo, allowing for decoupled deployments of internal packages and the primary web application.
The system uses a custom src/proxy.ts instead of standard Next.js middleware.ts to ensure stable edge execution on Cloudflare and support custom domain routing.
Sources: README.md:118-120, AGENTS.md:65-67, README.md:92-113
Edge Request & Media Delivery
A critical component of the KudosWall deployment is the secure delivery of media assets from Cloudflare R2 using HMAC-signed tokens.
Media Signing Sequence
Testimonial video playback is secured through temporary signed paths with a 3600-second Time-To-Live (TTL).
Sources: README.md:126-146, README.md:63-65
Environment & Validation
The deployment process requires strict environment variable validation at compilation time using Zod. Environment variables are categorized by target scope (Server vs. Client).
| Variable | Scope | Requirement | Note |
|---|---|---|---|
DATABASE_URL | Server | Required | Neon PostgreSQL connection string |
R2_SIGNING_SECRET | Server | Required | HMAC-SHA256 seed for media |
STRIPE_SECRET_KEY | Server | Required | Backend billing integration |
NEXT_PUBLIC_STRIPE_KEY | Client | Required | Stripe client gateway |
Sources: README.md:175-195, AGENTS.md:74-76
Operational Workflows
Deployment and maintenance tasks are managed via Bun scripts within the Turborepo workspace.
Core Deployment Commands
- Infrastructure Setup:
packages/infrahandles Alchemy deployment configurations. - Production Build:
bun run buildcompiles edge-compatible bundles to verify zero build errors. - Database Synchronization:
bun run db:pushsynchronizes schema changes directly to the Neon instance.
Sources: README.md:213-217, README.md:243-245, AGENTS.md:113-115
Conclusion
The KudosWall deployment strategy prioritizes the "Edge-First" philosophy, utilizing Cloudflare's global network and Alchemy's infrastructure tools to minimize latency. By separating the proxy logic from standard middleware and utilizing serverless connection pooling via Neon, the application maintains high performance while managing complex media delivery and social proof schemas.
Sources: README.md:46-51, AGENTS.md:65-67