Skip to content

DEPLOY.md

Latest commit

 

History

History
151 lines (118 loc) · 6.48 KB

DEPLOY.md

File metadata and controls

151 lines (118 loc) · 6.48 KB
Raw

Deployment Guide: bobsgame.com

The current live public frontend for bobsgame.com is served from the Hetzner nginx host at /srv/www/bobsgame.com. DreamHost notes below remain useful historical fallback guidance, but the primary live deployment path is now the tracked Hetzner upload + verification workflow.

Hetzner Frontend Deploy (Current Live Path)

From bobsgameweb/:

VITE_SERVER_URL=https://ws.bobsgame.com npm run build
FRONTEND_HOST=5.161.250.43 FRONTEND_USER=root BACKEND_URL=https://ws.bobsgame.com ./scripts/deploy-frontend-hetzner.sh
BACKEND_URL=https://ws.bobsgame.com FRONTEND_URL=https://bobsgame.com ./scripts/verify-production-stack.sh

The production verification step now also scans the deployed JS bundles to ensure they actually contain https://ws.bobsgame.com. It additionally checks for expected custom-editor markers in the live asset set and verifies that critical lazy-loaded scene chunk families remain discoverable and fetchable from production without relying solely on interactive browser automation.

Legacy DreamHost Notes

The Omni-Engine web port is ready for deployment to DreamHost.

Current Observed Blockers

From the agent sandbox environment on 2026-07-01:

  • sshpass is installed and usable.
  • rsync is installed locally (v3.2.7).
  • CRITICAL BLOCKER: The local sandbox infrastructure enforces a network policy that completely blocks outgoing SSH traffic on port 22. Any attempt to ssh, scp, or rsync over SSH from this environment (whether targeting DreamHost or Hetzner) will result in a hard connection timeout.
  • LIVE PARITY BLOCKER: The local sandbox is completely decoupled from the production deployment due to the SSH blocks. We have confirmed the verify-production-stack.sh execution parses WebGPU particle chunks, lazy-loaded scene chunks, and FFT visualizer markers inside the output properly. However, since we cannot physically connect to 5.161.250.43, the output of scanning the live host returns a failure because the v3.0.12 code does not exist there. The live host MUST be deployed to manually for the scan to succeed.

Because of this environment-level network constraint, configuring SSH key authentication or running automated deployment scripts directly from the agent environment is impossible. Deployments must be run manually by the user outside of the sandbox.

1. Prerequisites

Recommended:

  • SSH key auth configured for DreamHost.

Optional:

  • sshpass installed if you truly want password-driven automation.
  • rsync installed for faster incremental uploads.

If rsync is not installed, the Bash deploy script now automatically falls back to tar-over-ssh so dist/renderer/ contents land directly in the target directory instead of nesting an extra renderer/ directory.

2. Automated Deployment

Bash / Git Bash

Run from bobsgameweb/:

./scripts/deploy.sh

PowerShell

Run from bobsgameweb/:

./scripts/deploy.ps1

3. Useful Environment Variables

Both deploy scripts support:

  • DEPLOY_USER — defaults to robertpelloni
  • DEPLOY_HOST — defaults to pdx1-shared-a1-33.dreamhost.com
  • DEPLOY_REMOTE_PATH — defaults to ~/bobsgame.com
  • DEPLOY_PASSWORD — optional; used with sshpass if available
  • DEPLOY_SKIP_BUILD=1 — skips rebuilding before upload
  • DEPLOY_FORCE_SCP=1 — disables rsync even if present and forces the non-rsync fallback path (Bash uses tar-over-ssh)
  • DEPLOY_INSTALL_SERVER=1 — optionally runs npm install remotely in server/
  • DEPLOY_RESTART_SERVER=1 — optionally attempts pm2 restart index.js remotely

Example:

DEPLOY_PASSWORD='your-password' DEPLOY_INSTALL_SERVER=1 DEPLOY_RESTART_SERVER=1 ./scripts/deploy.sh

Example for a prebuilt frontend where you want to avoid an extra build and force the non-rsync fallback path:

DEPLOY_SKIP_BUILD=1 DEPLOY_FORCE_SCP=1 ./scripts/deploy.sh

4. Manual Deployment Steps

If you prefer manual deployment:

  1. Build the project: 
    npm run build
  2. Create remote directories: 
    ssh robertpelloni@pdx1-shared-a1-33.dreamhost.com "mkdir -p ~/bobsgame.com ~/bobsgame.com/server"
  3. Transfer static files: 
    scp -r dist/renderer/* robertpelloni@pdx1-shared-a1-33.dreamhost.com:~/bobsgame.com/
  4. Transfer server files: 
    scp -r server/* robertpelloni@pdx1-shared-a1-33.dreamhost.com:~/bobsgame.com/server/
  5. Optional server setup: 
    ssh robertpelloni@pdx1-shared-a1-33.dreamhost.com "cd ~/bobsgame.com/server && npm install && (pm2 restart index.js || pm2 start index.js)"

5. Server Configuration

Ensure your DreamHost panel is configured to:

  • Point bobsgame.com to ~/bobsgame.com/.
  • Allow WebSocket connections (usually enabled by default on shared hosting, but might require Passenger/Node configuration).
  • Permit SSH login for the target user.

6. Recommended Production Backend Shape

Based on live probing of the DreamHost environment:

  • the static site is deployable to bobsgame.com
  • /socket.io on https://bobsgame.com currently returns 404
  • node exists remotely, but shell tooling is limited and Apache is not currently proxying Socket.io
  • Passenger tooling exists, but does not appear to be actively running for this site right now

Recommended setup

Use a dedicated backend subdomain, for example:

  • ws.bobsgame.com

Suggested DreamHost shape:

  1. Create subdomain ws.bobsgame.com
  2. Point its web directory/app root at ~/bobsgame.com/server
  3. Configure it as a Node/Passenger app if DreamHost panel supports that for the subdomain
  4. Use server/app.js as the startup entrypoint
  5. Verify backend health with: 
    curl -i https://ws.bobsgame.com/healthz
  6. Build the web client with: 
    VITE_SERVER_URL=https://ws.bobsgame.com npm run build

The web client now supports this via .env.production.example and src/shared/Config.ts. A dedicated step-by-step checklist is available in WS_BACKEND_SETUP.md.

7. Easiest Future Setup

For the easiest one-command deploys, the best improvement is:

  1. Add an SSH key to DreamHost for robertpelloni
  2. optionally install rsync locally
  3. configure a dedicated backend host/subdomain such as ws.bobsgame.com
  4. then run: 
    VITE_SERVER_URL=https://ws.bobsgame.com DEPLOY_INSTALL_SERVER=1 ./scripts/deploy.sh

That avoids interactive password prompts and gives the cleanest separation between static frontend hosting and websocket backend hosting.