Deployment Guide

Relevant source files

The following files were used as context for generating this wiki page:

• DEPLOYMENT.md
• frontend/DEPLOYMENT.md
• INFRASTRUCTURE_SETUP_COMPLETE.md
• INFRASTRUCTURE_SUMMARY.txt
• docker-compose.yml
• railway.toml
• vercel.json

The GoHighLevel Clone is a multi-tenant marketing automation platform designed for high scalability and production readiness. This guide outlines the comprehensive procedures for deploying the platform's distributed architecture, which consists of a FastAPI backend, a Next.js frontend, and various supporting services including PostgreSQL and Redis. The deployment strategy leverages modern cloud-native practices, specifically utilizing Docker containerization for consistency across environments and managed platforms like Railway and Vercel for production hosting.

Sources: DEPLOYMENT.md:1-25, INFRASTRUCTURE_SETUP_COMPLETE.md:8-15

System Architecture

The platform utilizes a decoupled architecture where the frontend and backend are hosted on separate specialized platforms to optimize performance and developer experience.

Component Overview

Component	Technology Stack	Deployment Platform
Frontend	Next.js 14 (React 19, TypeScript)	Vercel (Global CDN & Edge)
Backend API	FastAPI (Python 3.12)	Railway (Docker Container)
Primary Database	PostgreSQL 16	Railway Managed Postgres
Cache & Queue	Redis 7	Railway Managed Redis
Background Jobs	Celery Workers	Railway

Sources: DEPLOYMENT.md:18-35, INFRASTRUCTURE_SUMMARY.txt:38-48, INFRASTRUCTURE_SETUP_COMPLETE.md:18-22

Deployment Flow Diagram

The following diagram illustrates the relationship between the different hosting providers and the data flow between system components.

This diagram shows the distributed nature of the deployment, with the frontend at the edge via Vercel and the core logic/data residing in Railway.
Sources: DEPLOYMENT.md:18-32, INFRASTRUCTURE_SUMMARY.txt:38-48

Production Deployment Platforms

Railway (Backend & Infrastructure)

Railway is the primary platform for the backend API and stateful services. It is chosen for its container-based deployment model, managed databases, and zero-downtime capabilities.

• Build Configuration: Railway uses the Dockerfile located in the /backend directory for multi-stage builds.
• Scaling: The system is configured for horizontal scaling based on CPU utilization.

Railway Deployment Configuration (railway.toml):

[deploy]
healthcheckPath = "/health"
restartPolicyType = "ON_FAILURE"
numReplicas = 1

[deploy.scaling]
minReplicas = 1
maxReplicas = 5
targetCPUUtilization = 70

Sources: railway.toml:1-12, DEPLOYMENT.md:37-45, INFRASTRUCTURE_SETUP_COMPLETE.md:88-100

Vercel (Frontend)

Vercel hosts the Next.js frontend, providing global CDN distribution and automatic SSL management.

• Optimization: Configured specifically for Next.js App Router and Edge Functions.
• Regions: Deployed across multiple regions (e.g., iad1, sfo1) for low latency.

Vercel Configuration (vercel.json):

{
  "framework": "nextjs",
  "regions": ["iad1", "sfo1"],
  "functions": {
    "memory": 1024,
    "maxDuration": 10
  }
}

Sources: vercel.json:1-10, DEPLOYMENT.md:47-50, INFRASTRUCTURE_SETUP_COMPLETE.md:102-110

Environment Configuration

Production environments require specific secrets and configuration variables that must never be committed to version control.

Required Secrets (GitHub Actions)

For automated CI/CD, the following secrets must be configured in the GitHub repository:

• RAILWAY_TOKEN: Deployment token generated via Railway CLI.
• VERCEL_TOKEN: Authentication token for Vercel CLI.
• VERCEL_ORG_ID: Vercel Organization identifier.
• VERCEL_PROJECT_ID: Vercel Project identifier.

Sources: DEPLOYMENT.md:75-85, INFRASTRUCTURE_SETUP_COMPLETE.md:55-61

Application Variables

Variable	Description	Source/Default
ENVIRONMENT	Deployment stage (e.g., production)	Manual
DATABASE_URL	PostgreSQL connection string	Railway (Automatic)
REDIS_URL	Redis connection string	Railway (Automatic)
SECRET_KEY	Cryptographically secure string for JWT	Manual
NEXT_PUBLIC_API_URL	Public URL of the Railway Backend	Manual
CORS_ORIGINS	Allowed frontend domains for API access	Manual

Sources: DEPLOYMENT.md:155-175, INFRASTRUCTURE_SETUP_COMPLETE.md:65-75

Docker Deployment

The platform provides Docker configurations for both local development and standardized production builds.

Multi-Stage Build Sequence

The following sequence diagram represents the multi-stage build process used for the frontend to ensure minimal image sizes.

This multi-stage process ensures that build tools and dev-dependencies are excluded from the final production image.
Sources: frontend/DEPLOYMENT.md:95-135, INFRASTRUCTURE_SETUP_COMPLETE.md:30-45

Local Orchestration (docker-compose.yml)

For local development, the entire stack can be launched using a single command:

docker-compose up -d

This orchestrates the backend, frontend, postgres, and redis services with shared networking and persistent volumes.
Sources: docker-compose.yml:1-120, INFRASTRUCTURE_SUMMARY.txt:130-135

CI/CD Pipeline

The project implements an automated pipeline via GitHub Actions (.github/workflows/ci-cd.yml) that triggers on every push to the main branch.

Pipeline Stages

1. Test: Executes pytest, ruff, and mypy for the backend; vitest and eslint for the frontend.
2. Build: Generates Docker images for both services and pushes them to the GitHub Container Registry (GHCR).
3. Deploy: Automatically updates the Railway service and Vercel project.
4. Verify: Runs post-deployment integration tests and health check validation.

Sources: INFRASTRUCTURE_SETUP_COMPLETE.md:47-53, INFRASTRUCTURE_SUMMARY.txt:55-65

Monitoring and Health Checks

Comprehensive health check endpoints are implemented to facilitate automated monitoring and zero-downtime deployments.

Health Endpoints

• GET /health: Returns a full status report including Database and Redis connectivity.
• GET /health/live: Liveness probe for orchestration platforms.
• GET /health/ready: Readiness probe ensuring all dependencies are operational.

Sample Response:

{
  "status": "healthy",
  "database": "connected",
  "redis": "connected",
  "timestamp": "2026-02-07T12:00:00Z"
}

Sources: INFRASTRUCTURE_SETUP_COMPLETE.md:115-130, DEPLOYMENT.md:205-220

Rollback Procedures

If a deployment failure occurs, the following procedures are available:

Railway Rollback

# Rollback to the immediate previous deployment
railway rollback

# Rollback to a specific deployment ID
railway rollback --deployment-id <id>

Sources: DEPLOYMENT.md:245-252, INFRASTRUCTURE_SUMMARY.txt:150-155

Vercel Rollback

# List all previous deployments
vercel ls

# Rollback to a specific URL
vercel rollback <deployment-url>

Sources: frontend/DEPLOYMENT.md:215-225, DEPLOYMENT.md:254-260

Summary

The GoHighLevel Clone deployment architecture is optimized for stability and scale. By utilizing Railway for containerized backend services and Vercel for the frontend CDN, the platform achieves high availability and global performance. The integration of Docker and GitHub Actions ensures that every production update is thoroughly tested and deployed through a repeatable, secure pipeline.

Sources: INFRASTRUCTURE_SETUP_COMPLETE.md:295-310, INFRASTRUCTURE_SUMMARY.txt:220-230