Boostr installation and deployment guide

Release: October 25, 2026 · Target: Linux x86_64 with glibc and Node.js 24

1. What this package contains

The current Prepare your space homepage, GlobalBoost attribution/logo, and Biconomy BSTY/USDT and FreiExchange BSTY/BTC links.
The Node.js/mediasoup conferencing application. The homepage generates same-origin room invitations and an enter-room link to the installed server's /join/ route.
Installed Node dependencies, an offline npm cache, bundled browser libraries/fonts/models and a Linux x64 media worker.
Source/license notices, dependency inventories, change history, installation helpers and deployment examples.

This is a self-hosted server package, not a Sites deployment. It requires no ChatGPT account or OpenAI API key to run. Documentation links can point to external websites, but required application assets are local. External service integrations remain optional/disconnected. Node.js, Linux system libraries, DNS, certificates, networking and optional FFmpeg are infrastructure prerequisites, not included operating-system components.

2. Choose the deployment target

Use a dedicated Linux x64 VM/server with a stable public IPv4 address and administrative access. Do not install the media server as a static site or on a hosting plan that cannot run persistent Node processes and expose UDP ports. The bundled native binary is not for Windows, macOS or ARM. For those platforms, provision a compatible Linux x64 VM; a new native build would otherwise be required.

Use meet.boostr.live for the conferencing hostname, or replace it consistently throughout this guide. Point its DNS A record directly to the server's public IPv4 address. Leave it DNS-only if your DNS provider offers an HTTP proxy; ordinary HTTP proxying does not carry this server's WebRTC UDP traffic. Do not point it to the Sites custom-domain target.

3. Provision system prerequisites

Install Node.js 24 from an official Node.js distribution and make it available system-wide. Verify:

bash

node --version
command -v node
uname -m

Expected: v24.x, a Node executable path, and x86_64. The bundled worker also needs compatible glibc and libstdc++. The preflight check below detects worker startup failures.

On a fresh Debian/Ubuntu system, these commands provision supporting packages; this step uses OS repositories:

bash

sudo apt update
sudo apt install nginx certbot python3 openssl ca-certificates libstdc++6

Optional conversion/RTMP prerequisite:

bash

sudo apt install ffmpeg

For an offline machine, pre-provision these OS packages and Node.js before disconnecting. The application dependency restore itself does not use the network.

4. Upload and extract

Transfer Boostr_Installation_Package_2026-10-25.tar.gz to the server. Extract it from a directory where there is no existing boostr folder:

bash

tar -xzf Boostr_Installation_Package_2026-10-25.tar.gz
python3 boostr/scripts/verify-package.py
sudo useradd --system --home /opt/boostr --shell /usr/sbin/nologin boostr
sudo mv boostr /opt/boostr
sudo chown -R boostr:boostr /opt/boostr
cd /opt/boostr

Run the integrity check on the freshly extracted package before creating configuration.

If a service account or /opt/boostr already exists, preserve it and use the upgrade procedure in section 13 instead. Do not overwrite an existing production installation with this first-install sequence.

5. Verify bundled dependencies

Installed node_modules are included. A normal online npm install is unnecessary.

bash

sudo -u boostr sh scripts/preflight.sh

If installed packages are missing or need restoring:

bash

sudo -u boostr sh scripts/install-offline.sh
sudo -u boostr sh scripts/preflight.sh

The offline installer restores from vendor/npm-cache, copies the bundled native media worker and rebuilds the local browser bundle. It deliberately skips network-dependent npm lifecycle scripts. If offline installation reports a cache miss, keep the lockfile unchanged and use the bundled installed dependencies; do not silently fall back to online installation.

6. Create private configuration

Replace YOUR_PUBLIC_IPV4 with the server's actual public IPv4 address:

bash

sudo -u boostr python3 scripts/configure-installation.py \
  --domain meet.boostr.live \
  --public-ip YOUR_PUBLIC_IPV4

This helper refuses to overwrite an existing .env. It creates:

.env with unique JWT/API secrets, explicit network settings and host protection enabled.
HOST-CREDENTIALS.txt containing the newly generated owner host login. Keep it private.
app/src/config.js from the bundled template.
Fresh internal TLS certificate/key files if neither exists. These are not a trusted public certificate.

Read the generated host credentials only in your own terminal:

bash

sudo -u boostr cat HOST-CREDENTIALS.txt

The defaults bind Node to 127.0.0.1:3010, expose media on ports 40000–40100, announce your public IP, and allow CORS only from your chosen public origin. Host login is required to create rooms; guest account enforcement is off. Recording, RTMP, telemetry, cloud speech, AI avatars and ChatGPT remain disabled. Review .env before launch.

Do not expose .env, HOST-CREDENTIALS.txt, TLS private keys or server source folders through a separate web-server document root. The provided Nginx example proxies the application instead of serving /opt/boostr as a directory.

7. DNS and firewall

Create an A record: meet.boostr.live → your server's public IPv4 address.

Allow these inbound ports in BOTH the cloud-provider firewall and the server firewall:

Port	Protocol	Purpose
Your SSH port, commonly 22	TCP	Administration; restrict by source IP if practical
80	TCP	HTTP redirect and certificate validation/renewal
443	TCP	Public HTTPS and WebSocket signaling
40000–40100	UDP	WebRTC audio/video
40000–40100	TCP	WebRTC TCP fallback

Do not expose port 3010 publicly. If using NAT, forward both media protocols to this VM and keep SFU_ANNOUNCED_IP set to the public address. Nginx does not replace the media-port firewall rules. Do not enable a new firewall without first allowing your SSH connection.

8. Obtain public HTTPS certificates

The internal TLS material created by the helper lets the application start. Browsers must connect through Nginx using a trusted certificate for the public hostname.

The following webroot flow avoids stopping an existing Nginx service. Use it on a fresh host or adapt it to your existing Nginx configuration. If a server block for the same hostname already exists, edit that block instead of creating a duplicate.

bash

sudo mkdir -p /var/www/letsencrypt
sudo tee /etc/nginx/conf.d/boostr.conf > /dev/null <<'NGINX'
server {
    listen 80;
    server_name meet.boostr.live;
    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }
    location / { return 404; }
}
NGINX
sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl reload nginx
sudo certbot certonly --webroot -w /var/www/letsencrypt -d meet.boostr.live

Complete Certbot's prompts locally. For a different hostname, replace it in both the Nginx configuration and certificate command. Public certificate issuance requires connectivity to the chosen certificate authority. A fully isolated deployment needs a separately provisioned certificate trusted by its clients.

Install the full proxy configuration, editing the example hostname/certificate paths first if necessary:

bash

sudo install -m 644 deployment/nginx.conf.example /etc/nginx/conf.d/boostr.conf
sudo nginx -t
sudo systemctl reload nginx

The example includes WebSocket upgrade headers, long proxy timeouts, a single trusted proxy hop, and the renewal challenge path. Verify certificate renewal and arrange Nginx reload after renewal:

bash

sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh > /dev/null <<'SH'
#!/bin/sh
systemctl reload nginx
SH
sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
sudo certbot renew --dry-run
systemctl list-timers --all | grep -i certbot

If your Certbot installation has no renewal timer, enable the appropriate timer/cron job for that installation. Keep port 80 reachable when using HTTP validation.

9. Start Boostr with systemd

Check command -v node. If it is not /usr/bin/node, update the ExecStart path in deployment/boostr.service before installing it. Use a system-wide executable readable by the boostr service user, not a private per-user Node installation.

bash

sudo install -m 644 deployment/boostr.service /etc/systemd/system/boostr.service
sudo systemctl daemon-reload
sudo systemctl enable --now boostr
sudo systemctl status boostr

The application's dotenv loader reads /opt/boostr/.env through its working directory. The service does not use systemd EnvironmentFile, avoiding differences in inline-comment parsing.

Check logs:

bash

sudo journalctl -u boostr -f

Open https://meet.boostr.live. The first section should be Prepare your space; the removed A little closer hero should not appear. The GlobalBoost support section should link to Biconomy BSTY/USDT and FreiExchange BSTY/BTC.

10. Validate real meeting operation

Check the public HTTPS certificate and absence of mixed-content errors.
Prepare a room and use Start or join room. Authenticate as the configured host when prompted.
Send the generated same-origin invite to a second device on a DIFFERENT internet connection.
Test audio, camera video, screen sharing, chat and reconnects in both directions.
Verify that unauthorized users cannot create protected rooms and that guest access matches your intended policy.
Restart the service and reboot the VM; confirm that Boostr returns automatically.
Test with the browsers and participant counts you intend to support before opening registration or accepting customers.

The helper prepares an invitation URL; it does not pre-create a persistent meeting record. Room creation/access is handled by the existing conferencing routes and socket logic. Frontend link checks alone are not proof of successful media transport.

Restrictive networks can require a self-hosted TURN service. This release does not provision TURN or claim that TCP fallback covers every network. Recording and broadcast pipelines are optional and require their own storage, consent, FFmpeg/provider configuration and testing.

11. Local development

The same configuration can be used behind a local trusted HTTPS proxy, or you can prepare a separate development directory. Do not weaken the public deployment's authentication or certificates for local testing. Browser media APIs require a secure context; localhost is treated specially by modern browsers. The generated internal certificate is self-signed and intended for the internal server, not as a reason to bypass browser certificate warnings.

For manual startup from an already configured directory:

bash

cd /opt/boostr
sudo -u boostr node app/src/Server.js

Stop the systemd service first if it already owns port 3010. scripts/start-local.sh is a legacy convenience helper that expects JWT_SECRET in its process environment; the supported production service starts Node directly and loads .env itself.

12. Troubleshooting

Symptom	Check
Service refuses to start	`journalctl -u boostr -n 100`, Node 24, `.env`, JWT_SECRET, host credentials and readable `app/ssl` certificate/key
`uv_interface_addresses` or incorrect private address	Set SFU_ANNOUNCED_IP explicitly to your public IPv4; do not rely on automatic detection
Native worker exits immediately	Run `scripts/preflight.sh`, then `ldd vendor/native/linux-x64/mediasoup-worker`; check architecture and compatible glibc/libstdc++
Nginx 502	Node process running, Node executable path, file ownership, and loopback port 3010
Site loads but calls have no media	Public announced IP, UDP/TCP firewall range, NAT rules and optional TURN
WebSocket connection fails	Nginx upgrade headers, public HTTPS and proxy timeouts
Camera unavailable	HTTPS/secure context, browser permission, OS privacy settings and another app using the camera
Old landing page appears	Confirm this release's public/views/landing.html and public/site assets were installed; clear browser cache; set BRAND_HTML_INJECTION=false
Invite uses wrong hostname	Open the correct public hostname; the new landing page uses its current origin
CORS/embed rejection	Match CORS_ORIGIN and ALLOWED_EMBED_ORIGINS to the actual allowed origins; allow partner embeds explicitly if required
Market page unavailable	Exchange availability is independent of Boostr. Verify the destination directly; no trading status guarantee is made

13. Backup, upgrades and rollback

Keep encrypted backups of .env, HOST-CREDENTIALS.txt, instance-specific configuration, recordings and other mutable data. Do not publish them with the source. Keep the previous release and a system snapshot before upgrading.

For an upgrade, extract into a new directory, copy the existing private configuration and mutable data with their permissions, and review configuration differences. Do not run the first-install initializer over production configuration; it deliberately refuses to overwrite it. Test offline dependency restoration and worker startup for the new release. During a maintenance window, stop the service, switch the deployment directory to the new release, restart and run the meeting checklist. Roll back to the previous directory/snapshot if checks fail.

No database/schema migration is introduced by this installation packaging update. Keep runtime data separate from future release archives wherever possible. In-memory rooms may be interrupted by a restart; no automatic session migration is promised.

14. Verification and limits

The base server previously passed 507 tests, offline restoration of 410 target-platform npm packages, and native worker startup. This installation release adds new checks for the configuration helper, integrated landing page, local assets, same-origin enter-room links, route responses, script syntax and archive integrity. See RELEASE-VALIDATION.md for the actual results of this release.

Two-device public media, TURN traversal, trusted public certificate issuance, production load, all optional integrations and your target server have not been verified by preparing this package. Provisioning examples require your hostname/IP and administrative review. No real secrets or production credentials are bundled.

Original licenses and copyright notices remain in LICENSE, UPSTREAM-NOTICES.md, dependency inventories and public/vendor/licenses. Review the included license terms and any separate commercial license you hold before distributing or operating a modified service.

Useful primary references:

Node.js distributions: https://nodejs.org/en/download
Nginx WebSocket proxying: https://nginx.org/en/docs/http/websocket.html
Certbot guide: https://eff-certbot.readthedocs.io/en/stable/using.html