Node operator handbook

A practical overview for an institution considering running a Sub-regional Hub, National Hub, or Spoke — a node — in the African DSI DataBank federation. See Governance for how node admission and administrative decisions work.

What running a node means

Every tier — Sub-regional Hub, National Hub, Spoke — runs the same underlying software, configured differently. Your node holds your own institution's data as the source of truth, and decides for itself whether and what to sync upward to the rest of the federation.

Hardware & bandwidth

There is no fixed hardware requirement — the node software itself is small. What actually drives sizing is your own data:

A Spoke capturing genome assemblies, proteins, or raw eDNA/metagenomic reads needs disk space proportional to what it captures — plan around your own expected data volume, not a platform-wide number.
A National or Sub-regional Hub additionally aggregates what its own children sync upward — metadata and derived results are far smaller than the raw files a Spoke may hold locally and never sync.
A single small server is enough to run the software itself; size disk and bandwidth to your own data, not the compute.

Getting a node running

Register the node's existence — a new Sub-regional Hub applies directly to the Continental Hub; a new National Hub or Spoke applies to its intended parent instead. This starts pending until approved.
Request an operator account — separately, request the account that lets you manage your node day to day. This can happen before or after step 1.
Deploy the software. Three genuinely supported options: a Docker-based deployment, a native (non-Docker) install via a script or a .deb/.rpm package, or plain local processes for development only. Pick whichever fits your own comfort level and infrastructure.
Verify it's healthy— a real health check confirms your node's database and storage are genuinely reachable, not just that the process started.

Bringing your own node backend

You don't have to run this platform's own reference software. The federation's node protocol is a documented, versioned contract — if your institution already runs its own bioinformatics infrastructure, you can implement that contract directly against your own systems instead of standing up a second stack. The minimum to be a working node is small; everything beyond that is optional and degrades gracefully if you don't implement it — that one feature simply doesn't work for your node, nothing else is affected. The Continental Hub will label your node by its own reported software name rather than assuming it runs the reference implementation — purely informational, never a gate on anything.

Backup

Your node's database (metadata) and object storage (actual file bytes) are two separate things and both need regular backups — losing either loses real data your node is the source of truth for. Content checksums, computed when a file reaches the Hub, are one way to later verify a restored copy matches what was originally captured.

Upgrading

Database schema changes apply automatically on startup — in practice, get a newer version and restart the service, and the schema updates itself before the software starts serving requests. Take a backup before any version upgrade regardless.

Getting help

A security vulnerability — see Security for how to report it privately.
A dispute over an administrative decision — see Governance.
Everything else— contact the Continental Hub operator through the channel published in this site's footer.