Zero-Downtime Deployment Plan

The Problem

Right now, the live website and the build process use the same AWS server.

When we build the app, it uses almost all available memory. The website can go down for 5–10 minutes, and builds can sometimes fail with “out of memory.”

The Plan

Separate the build server from the live production server.

How Deployment Works

1. Push code to GitHub.
2. A separate build machine builds the app.
3. The live server stays online during the build.
4. The finished build is copied to a new folder on the live server.
5. The current shortcut is switched to the new version.
6. PM2 reloads the app with minimal interruption.
7. If something goes wrong, switch current back to the previous version and reload PM2.

Testnet + Mainnet

Testnet and Mainnet are built separately because they use different:

• Networks
• Contract addresses
• Public URLs
• Build configuration

The build machine runs Testnet first, then Mainnet. They are not built at the same time.

What We Need

Production Server

Keep our existing AWS server.

It will:

• Run the live website
• Run PM2
• Serve production traffic
• Store releases

It will no longer build the app.

Build Machine

Add one Linux machine with:

• 8 GB RAM minimum
• Same CPU architecture as production
• GitHub self-hosted runner

This machine handles all builds.

SSH

The build machine needs SSH access to the production server so it can copy the finished build.

Production Folders

releases/   → Each deployed version
shared/     → .env and shared files
current     → Points to the live version

Example:

current → releases/version-003

PM2

Run 2 copies of the app so PM2 can reload the new version while keeping the site available.

Cost

The build machine does not need to run 24/7.

After deployment, we can shut it down and only keep the disk/storage.

GitHub Pro is not required. The builds run on our own machine using a GitHub self-hosted runner.

Goal

Build separately. Keep the website online. Deploy safely. Roll back quickly.