- Replace fake-site footer with dark-web launch CTA; fix HubChatter inside AppProviders (client crash) - Add /launch, DEPLOY.md, onions:list|status|health, list-onion-urls, install-systemd, onion-status - start.sh CYBERLUX_PREPARE_ONLY; copy pass on satellite pages; Navbar launch link - README: operator cheat sheet, phone Tor note, systemd via install-systemd.sh Made-with: Cursor
8.0 KiB
CYBERLUX
One Next build. Dozens of v3 onions. Nginx in the middle. Tor does the rest.
CyberLux is a single Next.js app projected through nginx loopbacks into one Tor hidden service per vertical — hub, forum, exchange, market, wiki, syndicate, shadow /w nodes, and the rest of scripts/onion-nodes.json. Same codebase, same deploy, different .onion front doors with host-aware rewrites (proxy.ts + X-Cyberlux-Node).
Not a toy route list: stable HiddenServiceDir names, backup/restore for onion keys, generated Tor + nginx from one JSON source of truth. Built to boot, survive operator mistakes, and stay readable under stress.
Operator cheat sheet:
| Command | What |
|---|---|
./start.sh |
Full pipeline: generate → build → Tor/nginx → print every .onion URL → next start on 127.0.0.1:3000 |
npm run onions:list |
Print all http://….onion URLs from /var/lib/tor/*/hostname (use sudo if needed) |
npm run health:stack |
Terminal A: keep npm run start:onion running · Terminal B: curl Tor/nginx/Next loopbacks |
npm run onions:status |
URLs + HTTP probe each nginx vhost |
sudo bash scripts/install-systemd.sh |
Install cyberlux.service for boot-time Next |
See DEPLOY.md |
Firewall posture, compliance reminder, full systemd notes |
Tor Browser on phone: use Onion Browser (iOS) or Tor Browser for Android — Safari/Chrome will never resolve .onion. Paste the full http:// + 56-char host + .onion; cellular networks sometimes block Tor (try Wi‑Fi).
This repo ships:
43Tor v3 services- stable loopback range
127.0.0.1:8080–8122 - Next bound only to
127.0.0.1:3000 - one
.onionper major surface - persistent hidden-service identity keyed by
HiddenServiceDir - self-healing backup / restore of onion key directories
What It Does
CyberLux boots a single Next.js app and projects it through multiple onion entry points.
hubis the main storefrontforumis Void Aggregateexchangeis the classifieds stackmarketis the full catalog verticalsearchis Void Crawlerwikiis the hidden-wiki layerwis the syndicate shell network- dozens of additional dedicated onions map directly to top-level app routes
The routing layer uses host-aware rewrites so a dedicated onion feels like its own property without forking the app into 43 separate deployments.
One-Command Launch
Install system deps first on Debian/Ubuntu:
sudo apt install tor nginx
Then run:
chmod +x start.sh
./start.sh
What ./start.sh does:
- regenerates Tor / nginx / app route maps from
scripts/onion-nodes.json - runs
git pull --ff-onlyif the repo has.git(failure is non-fatal) - runs
npm install - repairs
.nextownership if a root-owned build left it unwritable - runs a production build
- restores backed-up onion keys if any hidden-service directories are missing
- installs Tor + nginx config only when it actually changed
- waits for all onion hostname files, not just the hub
- refreshes the onion key backup set
- prints every live
.onionURL - starts Next on
127.0.0.1:3000
Use Tor Browser and open the printed URLs as:
http://<56-char-v3-address>.onion
Persistent Onion Addresses
Yes: the onion addresses are meant to persist.
Each service uses a fixed Tor directory:
HiddenServiceDir /var/lib/tor/<service-dir>
HiddenServicePort 80 127.0.0.1:<loopback-port>
That means the .onion address remains stable as long as:
- the
torDirnames inscripts/onion-nodes.jsondo not change /var/lib/tor/<service-dir>is preserved- or the backup set can restore those directories
Addresses do not rotate on normal app restarts, rebuilds, or standard Tor restarts.
Self-Healing Onion Identity
CyberLux now includes automatic onion key persistence tooling:
scripts/backup-onion-keys.shscripts/restore-onion-keys.sh
Backup location:
/var/backups/cyberlux-onion-keys/current
Behavior:
- after boot, ready onion service directories are backed up
- on next boot, if a service dir is missing from
/var/lib/tor, it is restored from backup - Tor identity is preserved across ordinary host mistakes, partial deletions, or service-dir drift recovery
This is the difference between “looks cool in a screenshot” and “survives operator error.”
Tor / nginx Topology
Source of truth:
scripts/onion-nodes.json
Generated artifacts:
tor/cyberlux-nodes.confnginx/cyberlux-onion-servers.inclib/onionRoutes.generated.tsscripts/generated/tor-dirs.txtscripts/generated/onion-labels.tsvscripts/generated/onion-port-range.txt
Install path:
/etc/tor/cyberlux-nodes.conf/etc/nginx/cyberlux-server-common.inc/etc/nginx/cyberlux-onion-servers.inc/etc/nginx/sites-available/cyberlux-onion
Runtime:
- Next.js:
127.0.0.1:3000 - nginx onion vhosts:
127.0.0.1:8080–8122 - Tor exposes the public
.onionendpoints
Manual Ops
Install or refresh Tor/nginx config:
sudo bash scripts/install-tor-onion.sh
Back up onion keys immediately:
sudo bash scripts/backup-onion-keys.sh
Restore missing onion keys:
sudo bash scripts/restore-onion-keys.sh
Run local-only, skipping Tor/nginx:
CYBERLUX_SKIP_TOR=1 ./start.sh
Start app without the helper:
npm run build
npm run start:onion
Boot at startup (systemd)
Generate the real unit with your Unix user and repo path (don’t hand-edit placeholders):
sudo CYBERLUX_USER=$USER bash scripts/install-systemd.sh
sudo systemctl enable --now tor.service nginx.service cyberlux.service
# use `tor@default.service` instead of `tor.service` if your distro names it that way
The installer writes /etc/systemd/system/cyberlux.service and /etc/default/cyberlux. Legacy template notes live in scripts/cyberlux.service (prefer the generator).
Tor + nginx must already be configured (./start.sh or sudo bash scripts/install-tor-onion.sh at least once).
Verification
Run the full local verification suite:
npm run verify
That checks:
- onion config generation
- TypeScript
- shell syntax for boot / install / backup / restore scripts
- full Next production build
Common Failure: .next Permission Hell
If you previously ran a build with sudo, .next may be root-owned and Next will fail with EACCES during unlink / diagnostics writes.
Fix once:
sudo bash scripts/fix-next-perms.sh
Then rerun:
./start.sh
Security Notes
CyberLux is hardened for a demo stack, not sold as magic invisibility.
- Next and nginx bind to loopback only
- Tor exposes the onion endpoints
- do not publish
3000or8080–8122to the public internet - optional host firewall script:
sudo bash scripts/classroom-ufw.sh - the app can still be insecure if the app code is insecure
- operational mistakes still matter more than branding
Tor hides service reachability better than raw-IP hosting. It does not redeem bad application logic, bad operator habits, or bad judgment.
Site Map
Core verticals:
/hub storefront/marketfull catalog/forumVoid Aggregate/exchangeclassifieds/barterAsh Pit/searchVoid Crawler/hidden-wikiwiki layer/darknet-atlastaxonomy / atlas/syndicateshell network/dashboardpersonal relay/account/hidden-servicesmirror map
There are additional dedicated onions for many top-level routes beyond those.
Stack
- Next.js
16 - React
19 - Tailwind CSS
4 - nginx
- Tor hidden services
- generated route / host mapping
Final word
If you’re running this, you’re past LARP. The stack is designed to:
- keep onion identities across rebuilds when you respect
torDirnames and backups - expose only what Tor publishes — not your loopback ports to the raw internet
- fail loud in verification (
npm run verify) instead of silently rotting
Read DEPLOY.md before you point real people at it. You own jurisdiction, opsec, and what you ship.