MyZubster Onion Decentralization Is Now Working Across Multiple Hosts
Today we reached an important milestone in the MyZubster infrastructure: the Onion layer is no longer just a local Docker experiment.
It is now actively working across multiple independent hosts, with real Tor reachability, health monitoring, and automatic node selection.
This matters because “three containers on one machine” is not real decentralization. If that machine goes down, everything goes down with it.
The new architecture removes that limitation.
What is live now
MyZubster currently has two independent Onion environments:
Host A — Windows / Docker
├── local Onion HA cluster
├── multiple Tor-backed nodes
└── automatic local failover
Host B — Aruba Cloud / Ubuntu
└── independent persistent Onion service
The Aruba node exposes its own persistent Onion identity:
r34e7wmvekdsonvq2uxi4yhtwbb553lahikajjdiphxpnm24fzfm3syd.onion
Its Tor state is stored in a persistent Docker volume, and the service has been verified as healthy with no failing health checks.
The Tor process has also remained active for multiple days, maintaining circuits and handling continuous network activity.
Real Tor reachability, not just “container is running”
The most important validation was performed from the Windows environment.
A Tor-enabled probe container connected through SOCKS to the remote Aruba .onion endpoint.
The result:
HTTP/1.1 200 OK
and the response was the real MyZubster Gateway application.
So the verified path is:
Windows host
↓
Tor SOCKS client
↓
Tor network
↓
Aruba Onion service
↓
MyZubster Gateway
↓
HTTP 200
This proves real cross-host Onion communication, not just local container health.
Automatic health probing is now active
We also introduced a dedicated Onion health probe.
The probe boots Tor, waits for full bootstrap, and then checks both configured Onion nodes.
In the live test, Tor reached:
Bootstrapped 100% (done)
and then repeatedly reported:
[OnionProbe] healthy=windows-ha,aruba-vps
The generated health snapshot showed both nodes returning HTTP 200:
{
"windows-ha": {
"healthy": true,
"statusCode": 200
},
"aruba-vps": {
"healthy": true,
"statusCode": 200
}
}
That means node availability is now derived from real Tor reachability, not from a hardcoded flag.
Discovery and automatic node selection
The new Gateway discovery layer exposes:
GET /api/onion/nodes
The endpoint returns the current multi-host state and automatically selects a healthy node using a fail-closed priority strategy.
In the successful runtime test, the response was:
{
"transport": "onion",
"multiHost": true,
"selectionMode": "priority-health-fail-closed",
"selectedNode": "windows-ha"
}
Both nodes were healthy:
windows-ha
priority: 10
healthy: true
aruba-vps
priority: 20
healthy: true
So the system selects the preferred node while keeping Aruba available as the fallback.
If the primary becomes unhealthy, stale, or unreachable, it is not supposed to be selected.
Why this is a stronger architecture
We are deliberately keeping separate Onion identities on separate machines.
We are not copying one hidden-service private key across multiple servers just to preserve one .onion hostname.
That reduces the blast radius of a key compromise and keeps the infrastructure genuinely independent.
The architecture is therefore:
MyZubster / Zorgax
│
▼
Onion Discovery Layer
│
┌────────────┴────────────┐
│ │
▼ ▼
Windows Onion Aruba Onion
priority: 10 priority: 20
healthy healthy
│ │
└──────── Tor Network ────┘
What has been verified
At this point, these are not theoretical capabilities:
Local Onion high availability: working
Local node failover: working
Remote Onion service on independent VPS: working
Persistent Onion state: working
Tor bootstrap: working
Cross-host Tor reachability: working
HTTP 200 through Tor: working
Real Onion health probe: working
Shared health snapshot: working
Multi-host discovery endpoint: working
Automatic node selection: working
Fail-closed health strategy: implemented and validated
The Gateway runtime test successfully selected windows-ha while confirming that aruba-vps was simultaneously healthy and available as a secondary node.
Why this matters
The important shift is architectural.
Before:
one host
↓
multiple containers
↓
single physical failure domain
Now:
multiple hosts
↓
independent Onion identities
↓
real Tor communication
↓
health-based discovery
↓
automatic routing
That means MyZubster is moving away from asking:
“Is the server online?”
toward asking:
“Which healthy MyZubster node is reachable right now?”
That is the behavior we actually want from a decentralized transport layer.
Next step
The next phase is to add more independent nodes across different providers or community-operated hosts.
The model scales naturally:
node-a → Windows
node-b → Aruba
node-c → another cloud provider
node-d → community host
The discovery layer does not need all nodes to share the same identity.
It only needs to know which public Onion endpoints are healthy.
That gives MyZubster a path toward a more resilient, distributed, privacy-preserving network without introducing unnecessary shared-secret risk.
Final milestone
Today we can say something much more concrete than “we are experimenting with Tor.”
MyZubster Onion decentralization is active, multi-host, measurable, and working.
The Windows environment can reach the Aruba Onion node through Tor, both nodes are independently healthy, the health probe verifies them in real time, and the Gateway discovery layer can select the best available node automatically.
That is the foundation for a real decentralized MyZubster transport network.
Top comments (0)