Deployment Overview
Hyperscape uses a split deployment architecture with separate environments for production and staging:Production Architecture
- Frontend: Cloudflare Pages (hyperscape.club)
- API/Server: Railway (api.hyperscape.club)
- Database: PostgreSQL on Railway
- Assets/CDN: Cloudflare R2 (assets.hyperscape.club)
Staging Architecture
- Frontend: Cloudflare Pages (staging.hyperscape.club)
- API/Server: Railway (staging-api.hyperscape.club)
- Database: PostgreSQL on Railway (separate staging database)
- Assets/CDN: Cloudflare R2 staging bucket (staging-assets.hyperscape.club)
Deployment Triggers
| Branch | Environment | Frontend | API | Assets |
|---|---|---|---|---|
main | Production | Auto-deploy to Pages | Auto-deploy to Railway | Auto-upload to R2 |
staging | Staging | Auto-deploy to Pages | Auto-deploy to Railway | Auto-upload to R2 staging |
The staging environment provides a complete isolated instance for testing changes before production deployment.
Environment Variables
Server Environment Variables
- Production
- Staging
Client Environment Variables
- Production
- Staging
Railway Deployment (Backend/API)
Railway hosts the game server with automatic deployments via GitHub Actions.Automated Deployment
The repository includes a GitHub Actions workflow that automatically deploys to Railway on every push tomain:
- Push to
mainbranch triggers workflow - GitHub Actions calls Railway GraphQL API
- Railway rebuilds using Nixpacks configuration
- Server restarts with new code
- Manifests fetched from CDN at startup
Manual Setup
Hyperscape includes automated Railway deployment via GitHub Actions. The server is deployed using Nixpacks with automatic manifest fetching from CDN.Architecture
The production deployment uses a split architecture:- Frontend: Cloudflare Pages (
hyperscape.club) - Server/API: Railway (
hyperscape-production.up.railway.app) - Assets/CDN: Cloudflare R2 (
assets.hyperscape.club) - Database: Railway PostgreSQL
Automated Deployment
Deployments trigger automatically on push tomain when these paths change:
.github/workflows/deploy-railway.yml) uses Railway’s GraphQL API to trigger redeployments.
Manual Deployment
Railway deployment is automated via GitHub Actions (.github/workflows/deploy-railway.yml).
Railway deployment is automated via GitHub Actions for both production and staging environments.
Automated Deployment
The.github/workflows/deploy-railway.yml workflow automatically deploys when you push to:
mainbranch → Production environmentstagingbranch → Staging environment
packages/shared/**packages/client/**packages/server/**packages/plugin-hyperscape/**package.json,bun.locknixpacks.toml,railway.server.json,Dockerfile.server
Railway Configuration
The deployment uses nixpacks for building (configured innixpacks.toml):
The build phase creates the manifests directory but does NOT download manifests. Manifests are fetched from the CDN at server startup.
Manual Railway Setup
Create Railway project
- Connect your GitHub repository to Railway
- Create two environments:
productionandstaging
Configure service
Railway automatically detects
nixpacks.toml and railway.server.json.Build settings:- Builder: Nixpacks
- Config path:
nixpacks.toml - Watch patterns: Defined in
railway.server.json
- Start command:
cd packages/server && bun dist/index.js - Healthcheck path:
/status - Healthcheck timeout: 300s
Set environment variables
Configure environment variables for each environment (see tabs above).Required secrets:
DATABASE_URL(auto-populated by Railway PostgreSQL)JWT_SECRETPUBLIC_PRIVY_APP_IDPRIVY_APP_SECRETPUBLIC_CDN_URL
Manifest Fetching at Startup
The server automatically fetches manifests from the CDN at startup:- Production/Staging: Always fetches latest manifests from CDN
- Development: Skips fetch if local manifests already exist
- Caching: Compares content and only writes changed files
Cloudflare Pages Deployment
Cloudflare Pages automatically deploys the frontend via GitHub integration.Automatic Deployment
Production (main branch):
- URL: hyperscape.club
- Custom domain configured in Cloudflare Pages settings
staging branch):
- URL: staging.hyperscape.club
- Preview deployments:
*.hyperscape.pages.dev
Manual Setup
Connect repository
- Go to Cloudflare Pages dashboard
- Create new project from GitHub
- Select the Hyperscape repository
Configure build
Framework preset: None (custom)Build settings:
- Build command:
cd packages/client && bun install && bun run build - Build output directory:
packages/client/dist - Root directory:
/(repository root)
PUBLIC_PRIVY_APP_IDPUBLIC_API_URLPUBLIC_WS_URLPUBLIC_CDN_URLPUBLIC_APP_URL
Configure custom domains
Production branch (
main):- Primary:
hyperscape.club - Alternate:
www.hyperscape.club
staging):- Primary:
staging.hyperscape.club
Database Setup
Railway PostgreSQL is automatically configured when you add the database service.Railway PostgreSQL (Recommended)
Add database service
In your Railway project:
- Click “New” → “Database” → “PostgreSQL”
- Railway automatically sets
DATABASE_URLenvironment variable - Database is ready immediately
Alternative: Neon PostgreSQL
For serverless PostgreSQL with better free tier:- Create database at neon.tech
- Copy connection string
- Set as
DATABASE_URLin Railway environment variables
CDN & Assets Setup
Cloudflare R2 (Production)
Hyperscape uses Cloudflare R2 for asset storage with global CDN distribution.Create R2 bucket
- Go to Cloudflare dashboard → R2
- Create bucket named
hyperscape-assets - Enable public access
Local CDN (Development)
For local development, use the Docker CDN:Cloudflare R2 Asset Deployment
CDN Architecture
Hyperscape uses a CDN-based architecture for serving game assets (models, textures, audio, manifests): Required Manifests:npcs.json- NPC and mob definitionsworld-areas.json- Zone configuration with station spawnsbiomes.json- Biome definitionsstores.json- Shop inventoriesitems.jsonORitems/{weapons,tools,resources,food,misc}.json- Item definitions
Development CDN Fallback
In development, if local CDN is incomplete, the server automatically falls back to production CDN:Option 1: Self-Hosted
Automatic Upload
The.github/workflows/deploy-cloudflare.yml workflow uploads assets when:
- Manifests change:
packages/server/world/assets/manifests/** - Assets change:
assets/** - Manual trigger via workflow dispatch
- Production:
hyperscape-assets→assets.hyperscape.club - Staging:
hyperscape-assets-staging→staging-assets.hyperscape.club
Manual R2 Upload
CDN Configuration
The server fetches manifests from the CDN at startup:- Root manifests:
npcs.json,stores.json,world-areas.json, etc. - Items:
items/weapons.json,items/tools.json,items/resources.json, etc. - Gathering:
gathering/woodcutting.json,gathering/mining.json, etc. - Recipes:
recipes/cooking.json,recipes/smithing.json, etc.
- Manifests cached locally in
packages/server/world/assets/manifests/ - Only updated files are written (content comparison)
- Development mode skips fetch if local manifests exist
- 5-minute cache headers for manifest HTTP requests
This architecture allows updating game content by uploading new manifests to R2 without redeploying the server.
Local CDN (Development)
For local development, use the Docker CDN:packages/server/world/assets by default.
Configure PUBLIC_CDN_URL to point to your CDN host.
Option 2: Cloud Storage (Cloudflare R2)
Upload assets to Cloudflare R2 or similar:- Ensure assets are present:
bun run ensure-assets - Upload
packages/server/world/assets/to R2 bucket - Set
PUBLIC_CDN_URLto bucket URL (e.g.,https://assets.hyperscape.club)
- Automated via
.github/workflows/deploy-r2.yml - Triggers on push to
mainbranch - Uses
wranglerto sync assets to R2
Asset Management
The
ensure-assets script detects if you have manifests-only vs full assets and automatically downloads missing content via Git LFS.Production Checklist
- PostgreSQL database provisioned
- Environment variables configured
- Privy credentials set (both client and server)
- CDN serving assets
- WebSocket URL configured
- SSL/TLS enabled
- CORS allowlist includes production domains