BetaOperate · Guide
Run a Mobazha Node under your control
Decide whether self-hosting fits, then reach a healthy and recoverable evaluation Node.
Check the requirementsEstimated time6 minutes
Trust, applicability, and sourcesMobazha v0.3 release candidate
Choose the operating path
Evaluation quick start
The current release candidate requires Go 1.26.4, Git, and a supported macOS or Linux environment. Use testnet while evaluating payment flows.
text
git clone --branch main https://github.com/mobazha/mobazha.git
cd mobazha
go build -tags goolm -o mobazha .
./mobazha init --testnet
./mobazha start --testnet --openWhat a ready evaluation Node looks like
| Boundary | Evidence to keep |
|---|---|
| Build and identity | Exact source commit, build command, version, service account, network, and data directory |
| Local health | Successful service status, doctor --json, embedded UI, and runtime-config checks |
| Exposure | Intended listener, firewall, proxy, DNS, and TLS configuration with no accidental public administrator surface |
| Commerce | One disposable listing, quote, payment-observation, fulfillment, and recovery journey on supported testnet rails |
| Recovery | Timestamped backup plus an isolated restore test using a compatible build |
| Operations | Named alert recipient, update owner, rollback owner, and a safe first response for storage, dependency, and payment failures |
Booting the process is only the first proof. A Node is not operationally ready when its only store copy is on the running host, when runtime capabilities are assumed from source code, or when no one owns an alert or rollback.
Operator responsibilities
- Secure the host, administrator access, secrets, and network boundary.
- Back up data and recovery material before upgrades.
- Monitor storage, availability, payment integrations, and release notes.
- Expose only the interfaces your users and agents actually need.
Operating loop
- Before accepting work: confirm health, storage, backup age, effective capabilities, and external payment or delivery dependencies.
- During an incident: stop advertising unavailable new work, preserve current order evidence, and isolate the failing boundary before retrying.
- Before an upgrade: read release evidence, make and test a recovery point, and define the maintenance and rollback decision.
- After a change: verify diagnostics and one representative buyer, seller, payment, webhook, and recovery path affected by the change.
Optional hosted connection
An operator may bind a self-hosted node to an optional Mobazha account for hosted capabilities when offered. Binding does not transfer custody of local recovery material and is not required for independent operation.