Production Deployment

Deploying AnswerFlow for production is designed to be robust, scalable, and extremely flexible. We provide a complete, production-ready Docker Compose file (compose.prod.yaml) to get you running in minutes.

The “Batteries Included” Philosophy

Our default compose.prod.yaml is built on a “Batteries Included, But Removable” philosophy.

Out of the box, the Docker Compose file provisions the entire ecosystem:

• web: The Next.js frontend and API.
• worker: The Node.js background processor (running BullMQ).
• db: A PostgreSQL database.
• redis: A Redis instance for caching and job queues.
• migrator: A temporary container that safely applies Prisma database migrations before the application accepts traffic.

Option 1: The Single-Server Setup (VPS)

If you are deploying to a single server (like a DigitalOcean Droplet, Hetzner, or AWS EC2), you can use the batteries-included setup exactly as it is.

docker compose -f compose.prod.yaml up --build -d

docker compose -f compose.prod.yaml up --build -d

Option 2: The Enterprise Setup (Managed Services)

While running your own Database and Redis inside Docker is incredibly cost-effective, enterprise deployments at scale often require managed, highly available services like AWS RDS, Supabase, or Upstash.

You are actively encouraged to remove the local infrastructure “batteries” and plug in your own managed services.

How to remove the batteries:

1. Open compose.prod.yaml.
2. Delete the db and redis service blocks entirely.
3. Remove the depends_on array references for db and redis from the web, worker, and migrator services.
4. Update your .env file to point to your managed infrastructure:

# Example: Using Supabase and Upstash
DATABASE_URL="postgresql://postgres:password@db.your-supabase.supabase.co:5432/postgres"
REDIS_URL="redis://default:password@your-upstash-url.upstash.io:6379"

Because AnswerFlow strictly reads from your environment variables, the web and worker containers will seamlessly connect to your external managed services without any code changes!

Option 3: The Vercel / Serverless Route

If you prefer to deploy the Next.js frontend to an edge network like Vercel, you do not need to use Docker for the web application.

1. Vercel Configuration

Because AnswerFlow is a Turborepo monorepo, you must configure Vercel correctly so it knows which app to build.

• Import your GitHub repository into Vercel.
• CRITICAL: In the project settings, change the Root Directory to apps/web.
• Leave the Build Command and Install Command as their defaults (Vercel will automatically detect Turborepo and pnpm).
• Add all of your .env variables into the Vercel environment settings.

2. Handling the Background Worker

Serverless environments (like Vercel functions) spin up and down, meaning they cannot maintain a persistent connection to listen to a Redis queue. You have two options for your background worker:

Path A: Fully Serverless (Upstash QStash) To stay 100% serverless, switch your queue adapter to QStash. Add your QSTASH_URL, QSTASH_TOKEN, and signing keys to your Vercel environment variables. Vercel will act as the frontend, and QStash will trigger your Next.js webhook routes via HTTP to process background jobs.

Path B: The Hybrid Approach (Vercel + VPS Worker) You can host your Next.js frontend on Vercel for maximum edge performance, but run your background worker on a cheap $5 VPS (like DigitalOcean or Hetzner).

1. Deploy apps/web to Vercel.
2. On your VPS, use the compose.prod.yaml file but delete the web and caddy services.
3. Spin up the Docker cluster. Your VPS will now act as a dedicated background processor (running Redis, the Worker, and optionally Postgres), while Vercel handles all user-facing web traffic!