Enterprise Deployment

Trackr is designed with flexibility in mind. While we offer a fully managed Cloud version, many enterprise customers require self-hosting for compliance, data sovereignty, or deep internal network integration. This document details the architectures, deployment strategies, and best practices for running Trackr in a production environment.

Architecture Overview

Trackr is a modern decoupled web application consisting of three main tiers:

1. Frontend / SSR Edge: Built with Next.js. Handles React Server Components, client-side rendering, and API routing.
2. Backend API Workers: Node.js microservices handling heavy asynchronous tasks (e.g., AI resume parsing, webhook dispatch, email notifications).
3. Data Layer: PostgreSQL (primary database) and Redis (caching, session store, and background job queues).

Deployment Strategies

We support two primary modes of deployment for self-hosted and enterprise customers: Modern PaaS (Vercel + Managed DBs) and Full Infrastructure as Code (Docker / Kubernetes).

Option 1: PaaS (Vercel + AWS RDS) - Recommended

For teams wanting the lowest operational overhead, combining Vercel for the compute layer and managed AWS services for the data layer is the recommended path.

1. Frontend & API (Vercel)

Connect your Vercel account to your Trackr repository fork.

• Configure the build command: npm run build
• Set up Vercel Environment Variables securely.
• Ensure Edge Functions are enabled for middleware (routing, rate limiting).

2. Database Layer

• PostgreSQL: Provision an Amazon RDS PostgreSQL (v16+) instance. Ensure it is placed in a private subnet. Use a tool like PgBouncer for connection pooling.
• Redis: Provision an Amazon ElastiCache Redis cluster for sessions and queue management.

3. Storage

Provision an Amazon S3 bucket for storing user uploads (resumes, profile pictures). Ensure block public access is enabled, and the Vercel application communicates via pre-signed URLs.

Option 2: Self-Hosted Containerized (Docker / Kubernetes)

For strict compliance requirements, Trackr can be entirely containerized and run inside your VPC, on bare metal, or on Kubernetes clusters (EKS/GKE).

The Docker Compose Stack

We provide an enterprise docker-compose.yml for single-node deployments or local testing. It spins up the Trackr app, PostgreSQL, Redis, and a reverse proxy (Caddy or Nginx).

version: '3.8'
 
services:
  web:
    image: trackrhq/trackr-web:latest
    restart: always
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/trackr
      - REDIS_URL=redis://redis:6379
      - NEXTAUTH_SECRET=${NEXTAUTH_SECRET}
    depends_on:
      - db
      - redis
 
  worker:
    image: trackrhq/trackr-worker:latest
    restart: always
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/trackr
      - REDIS_URL=redis://redis:6379
    depends_on:
      - redis
      - db
 
  db:
    image: postgres:16-alpine
    restart: always
    volumes:
      - trackr_db_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=trackr
 
  redis:
    image: redis:7-alpine
    restart: always
    volumes:
      - trackr_redis_data:/data
 
volumes:
  trackr_db_data:
  trackr_redis_data:

Kubernetes (Helm Charts)

For highly available deployments, we provide official Helm charts. The Helm deployment separates the Web tier (Next.js) from the Worker tier (Node.js background jobs) so they can be scaled independently using Horizontal Pod Autoscalers (HPA).

helm repo add trackr https://charts.trackr.io
helm install trackr-prod trackr/trackr \
  --set web.replicaCount=3 \
  --set worker.replicaCount=2 \
  --set ingress.enabled=true \
  --set ingress.hosts[0].host=trackr.yourcompany.com

Reverse Proxy and SSL

Regardless of your infrastructure, Trackr requires a reverse proxy to terminate SSL/TLS and handle standard HTTP headers.

If deploying via Docker, we recommend Caddy for automatic SSL via Let's Encrypt, or Nginx if you are supplying your own enterprise wildcard certificates.

Nginx Configuration Example:

server {
    listen 443 ssl http2;
    server_name trackr.internal.company.com;
 
    ssl_certificate /etc/ssl/certs/trackr.crt;
    ssl_certificate_key /etc/ssl/private/trackr.key;
 
    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Continuous Integration / Continuous Deployment (CI/CD)

We strongly encourage fully automated deployment pipelines. A standard GitHub Actions workflow for Trackr involves:

1. Lint & Test: Run ESLint, Prettier, Jest (unit tests), and Playwright (e2e tests).
2. Build Docker Image: Build the mult-stage Dockerfile to compile Next.js.
3. Push to Registry: Push the immutable image to ECR or Docker Hub tagged with the Git SHA.
4. Database Migrations: Execute npx prisma migrate deploy in an ephemeral container.
5. Rolling Update: Update the Kubernetes deployment or restart Docker containers to pull the new image seamlessly.

Scaling Strategies

As your user base grows, Trackr is designed to scale horizontally.

1. Stateless Web Tier: The Next.js web instances are entirely stateless. Sessions are stored in Redis. You can scale the web containers infinitely behind a Load Balancer (e.g., AWS ALB).
2. Worker Queues: Background tasks (AI processing, emails) are processed via BullMQ on Redis. If the queue backs up, simply increase the replica count of the worker service.
3. Database Read Replicas: For read-heavy analytical dashboards, configure Trackr to use a database read replica by setting the DATABASE_URL_READ environment variable. The Prisma ORM will automatically route safe reads to the replica.

Backups & Disaster Recovery

Data loss is catastrophic. Ensure you have the following configured:

• Database Backups: Use pg_dump via a cron job or rely on AWS RDS automated snapshots. Retain daily backups for 30 days.
• S3 Versioning: Enable versioning on your S3 buckets to prevent accidental deletion of resumes and artifacts.
• Redis Durability: While Redis is primarily a cache, configure it with AOF (Append Only File) to ensure background job queues are not lost during a node restart.

By following these architecture blueprints, your deployment of Trackr will be resilient, secure, and ready to scale to thousands of active users.