Docs

Build on Navon.

Technical documentation for engineers, procurement, and compliance teams. Engagement paths, pod specifications, network fabric, certifications, and the methodology behind every claim on this site.

Get started · 01

Quickstart.

Three minutes to know whether Navon is the right answer for your workload. If after reading this you think the answer is yes, jump to engagement paths.

  1. Confirm the workload class. Navon is purpose-built for sovereign AI training, HPC simulation, regulated enterprise platforms, and government digital infrastructure. Latency-insensitive, low-density, no-sovereignty workloads are usually cheaper on a hyperscaler.
  2. Confirm the jurisdiction. Navon's first site is Hells Gate, Naivasha SEZ, Kenya. Phase 2 brings Uganda; Phase 3 brings Tanzania and South Africa. If your data must be resident in one of these, the math works.
  3. Pick a starting layer. Most customers start with a single product line and grow into the rest. Browse products for the four lines.
Get started · 02

Engagement paths.

There are three ways to engage with Navon. Pick the one that fits where you are.

Pilot

For small-team workloads or PoC. Single 20 kW rack, 1–3 month commitment, fixed pricing. Onboarding in 6–10 weeks once Hells Gate is live (Q3 2026).

MOU

For institutions exploring a longer commitment with non-binding intent. Standard MOU template covering scope, timing, and exclusivity. We sign these in 2–4 weeks.

Anchor

For governments, DFIs, or enterprises committing to a multi-MW deployment. Sequenced commissioning, dedicated module(s), bespoke SLA. Diligence cycle is 90–120 days.

Architecture · 01

20 kW rack.

A single 42U cabinet pre-configured for proof-of-concept and small-team workloads. Three CPU compute nodes, two GPU compute nodes, one NAS, Asterfusion leaf fabric.

Power budget

ComponentPSUFeed AFeed BTotal
GPU node ×22× 3 kW6.50 kW6.50 kW13.00 kW
CPU node ×32× 1.6 kW2.25 kW2.25 kW4.50 kW
NAS2× 1.6 kW0.50 kW0.50 kW1.00 kW
Asterfusion fabric2× PSU0.28 kW0.27 kW0.55 kW
Feed totals9.53 kW9.52 kW19.05 kW

Feed totals assume balanced dual-corded operation; on single-feed failover the surviving feed carries the full ~19 kW, so both PDUs are sized to 20 kW (32 A @ 240 V or 48 A @ 415 V 3-phase derated).

Network

Asterfusion leaf fabric, dual-switch HA: 25 GbE to compute, 100 GbE NAS uplink. Dual-corded, primary on feed A, redundant on feed B.

Lead time

14–16 weeks from PO. Cluster cost on Navon preferred pricing; refer to commercial pack under NDA.

Architecture · 02

90 kW pod.

Five direct-liquid-cooled racks at 90 kW each, with N+N power and a dedicated DLC loop. Built for next-generation GPU clusters and HPC workloads where rack density is the binding constraint.

Form factor

  • 5 × DLC racks, 42U each
  • Total IT load: 450 kW
  • UPS: 2 × 500 kVA (N+N)
  • Cooling: closed-loop direct-liquid + N+1 air handlers for residual

Use cases

  • GPU training (B200, H100, MI300x, MI355x)
  • HPC: climate, genomics, CFD
  • Inference fleet at scale

Lead time

9–12 months for the first pod (factory build); 6–9 months for repeats once tooling is stood up.

Architecture · 03

400 kW pod.

The Hells Gate flagship configuration: three steel enclosures (two IT rooms + one power-and-cooling room) with twenty 42U racks at 20 kW+ each. Tier III throughout.

Layout

  • IT Room 1 — 10 × 42U racks, 200 kW
  • IT Room 2 — 10 × 42U racks, 200 kW
  • Power & cooling — 2 × 500 kVA UPS (N+N), 2 × MDB 1600 A, 18 × BlueBox DX, meet-me room

Power & cooling

SpecValue
RedundancyTier III · N+N power · N+1 cooling
PUE (validated)1.29 at 400 kW constant IT load
Cooling18 × BlueBox DX with hot-aisle containment
Rack PDUDual 32 A · A+B redundant

Connectivity

Carrier-neutral meet-me room with Safaricom and dual fibre entry. Customer cross-connects on request, no lock-in.

Architecture · 04

Network fabric.

Asterfusion leaf-spine across all pod variants, with dual-switch HA at every layer.

  • Compute access: 25 GbE
  • Storage uplink: 100 GbE
  • External: dual fibre into the meet-me room, BGP peering with customer ASNs available
Operations · 01

DCIM.

Every Navon site runs on an integrated Data Centre Infrastructure Management platform — the operations layer that monitors, manages, and optimises the modular DC in real time. Capacity decisions, change management, and energy reporting all flow through it.

What it covers

ModuleFunction
OperationReal-time temperature, humidity, and environmental telemetry across the floor.
IncidentEvent classification, work-order dispatch, repeat-event analysis, case closure.
PUE EnergyLive PUE dashboard with historical trend, validated against meter data.
AssetRack-level inventory and asset module — every U accounted for, QR-tagged.
CapacityAutomatic availability calculation; cold/hot aisle utilisation by zone.
Work OrderEnd-to-end change-management workflow: Submit → Plan → Approve → Implement → Review → Close.
AnalyticsEnergy hierarchy analysis, capacity forecasting, anomaly detection.

Why it matters

For sovereign customers, DCIM means auditable operations — every change tracked, every kilowatt accounted for, every rack unit visible. For Navon's own engineering team, it means deployment 2 is faster than deployment 1 because the operating playbook is in software, not in someone's head.

Operations · 02

Optimisation cycle.

The DCIM platform runs a continuous four-phase loop. Every site, every week.

  1. Measurement — overall data centre environment captured in real time from a central dashboard.
  2. Analytics — virtual model of the infrastructure mapping relationships between every component.
  3. Plan — historical trend analysis informs capacity and operational planning decisions.
  4. Action — actionable configurations and SOPs executed via the Work Order workflow.

This is the same loop our customers see in their access view of the platform. Sovereign customers get a tenant-scoped slice; Navon operations sees the campus-wide view. Same underlying data.

Compliance · 01

Compliance frameworks.

Navon's compliance posture maps to local statute first, with international alignment where useful.

FrameworkStatusScope
Kenya DPA 2019CompliantAll Kenyan workloads, data residency, breach notification, DPO appointed
GDPRAlignedArchitecture and audit logs aligned for EU customers; not certified
SEZ gazette (Naivasha)ActiveTax, customs, and operating incentives under Kenyan SEZ Act
ISO 27001RoadmapTargeted post-commissioning
SOC 2 Type IIRoadmapTargeted post-commissioning
Compliance · 02

Tier III mapping.

The 400 kW pod is engineered to Uptime Institute Tier III standards. Concurrent maintainability without taking the IT load offline.

  • Multiple independent distribution paths (N+N power)
  • Dual-powered IT equipment
  • Redundant cooling infrastructure (N+1)
  • Concurrent maintainability for all critical components
Methodology · 01

Energy claim.

Hells Gate's "95% geothermal" headline number is the result of a specific calculation that we publish so it can be challenged.

What's in scope

The percentage refers to delivered electrical energy at the meter over a calendar year, sourced via the Olkaria-Suswa 220 kV corridor under a power purchase agreement that traces electrons to geothermal generation assets.

What's not in scope

Embodied energy in equipment (steel, copper, silicon) is not counted. Diesel emergency-backup runtime is excluded from the headline number but tracked separately and reported quarterly.

Verification

The claim is verifiable against KPLC meter readings and the corridor's published generation mix. We commit to publishing the annual reconciliation in the year after Hells Gate's first full year of operation.

Methodology · 02

PUE measurement.

The 1.29 PUE figure is validated under specific conditions; we publish them so the comparison is apples-to-apples.

  • Load: 400 kW constant IT load (full module commissioned)
  • Method: 1-minute interval averaging across a representative week
  • Boundary: includes UPS losses, cooling, lighting, BMS; excludes external transformers
  • Standard: aligned with The Green Grid PUE Category 2

PUE numbers measured at 30% load or in spec-sheet idealised conditions are not comparable to ours. Always ask vendors for boundary, load, and method before comparing.

Reference · 01

Inference API.

Native model serving on owned silicon, exposed behind an OpenAI-compatible endpoint. Not a routing layer over third-party model APIs — the inference runs on Navon hardware, in your jurisdiction, with weights and traffic that never egress the country.

Bring your stack.

The endpoint is drop-in compatible with the SDKs and runtimes engineering teams already use:

Serving runtimesvLLM · TGI · TensorRT-LLM · Ollama (self-hosted open weights)
SDKs & clientsOpenAI Python/JS · LangChain · LiteLLM · LlamaIndex · OpenRouter SDK · Cursor
Open-weight modelsLlama 3.x · Mistral · Qwen · DeepSeek · Phi · plus customer fine-tunes
Inference modesStreaming · batched · function-calling · vision · embeddings
ResidencyWeights, prompts, and outputs stay inside the customer's jurisdiction

Full API reference: Q3 2026

Formal API reference publishes alongside Hells Gate commissioning — covering inference, compute provisioning, storage operations, IAM, sovereign HSM, and audit log export. Subscribe to news to be notified.

Reference · 02

Changelog.

Coming with v1 of the platform

Public changelog will track customer-facing changes to the sovereign cloud platform, the modular pod product line, and compliance posture. Until v1 launches, follow News for milestones.