Sign inBook a briefing
Support
Version 1.0.0-alpha.1latest

Documentation

Adverant Nexus documentation

Release 1.0.0-alpha.1. Start with Part 1 if you're new to Nexus; Part 2 is for the people who install and run it.

Part 1: For everyone

  • 1.1What Nexus is, and who it's forWhat Adverant Nexus does for an organisation, who it is built for, and how its parts fit together, told in plain words with Harrow Port Authority as the example. It ends with the three editions in one paragraph.
  • 1.2A working day with NexusOne working day at Harrow Port Authority, from the first look at Today to the last approval, showing what people actually do in Nexus and where each kind of work lives.
  • 1.3Your organisation, its people, and what stays privateHow Nexus models an organisation and the roles its people hold, who may buy and claim on the Adverant account, and the line between what administrators can see and what stays private to each person.
  • 1.4AI on your termsHow Nexus uses artificial intelligence (AI) on the organisation's own terms. The organisation brings and owns its model keys, one switchboard routes every model call to providers it chose, local models run on its own servers, and nothing is sent to Adverant behind its back.
  • 1.5Trust and complianceThe parts of Nexus a compliance officer lives in. It covers the audit log and sealed records, approvals that need a second person and artificial intelligence (AI) decisions waiting for review. It ends with personal-data requests and the compliance pages that keep evidence ready before an auditor asks.
  • 1.6Editions and licences in plain termsThe three editions of Nexus and the 19 add-ons and domain packs on top, then how a licence works for a business. It covers the offline check and what each licence state means in practice, the promises every licence keeps, and moving from Community to Enterprise without reinstalling.
  • 1.7Domain packs and verticalsWhat a domain pack adds to Nexus for one industry, the ten packs Adverant offers, how a pack is switched on for one unit, and what a pack needs in your licence.
  • 1.8Where Nexus runsThe places Nexus can run, from Adverant's EU cloud to a site with no internet and devices in the field, what sovereignty means in practice, and how to choose.
  • 1.9Getting startedThe two decisions before you start, what your IT team does, the first run as the first administrator sees it, and a checklist of what to have ready on day one.
  • 1.10Away from the deskUsing Nexus on a phone, from the console's phone layout in every edition to the native iPhone and Android apps. Covers what works without signal and how a company manages the phones.
  • 1.11Making it yoursThe ways an organisation shapes Nexus, from a single setting to a vertical of its own. Also how to brief developers or a partner, and what the platform guarantees whatever gets built.
  • 1.12Questions people askPlain answers to the questions buyers, managers and data protection officers ask most, including the uncomfortable ones about money and access to your data.

Part 2: For IT, DevOps and developers

  • 2.1ArchitectureWhat each service in the Nexus chart owns and which stores sit beneath it, then the rules that hold them together, from identity between services to the path every model call takes.
  • 2.2Editions under the hoodHow Community and Enterprise are built from one product, how a licence switches feature groups on at run time, what a Community install shows for an Enterprise page, and what that means for the images you pull and the extensions you build.
  • 2.3Planning an installationWhat a Kubernetes install of Nexus needs before you type a command, how big it is, and the two decisions you can't take back, the installation name and the key custodians. It ends with Harrow Port Authority's filled-in planning worksheet.
  • 2.4Getting and verifying a releaseWhere each part of a Nexus release lives, how Enterprise images are fetched with a pull token, and how to prove every image, chart and download came from Adverant unchanged, offline, before you install anything.
  • 2.5Preflight with nexusctlEvery check `nexusctl preflight` makes, what each one reads and how it fails, the report it prints and saves, how that report reaches the console's preflight page, and every flag.
  • 2.6Installing Community on KubernetesA numbered install of the Community edition with Helm, from cert-manager to every workload ready, with the values file explained key by key, why there is no --wait, the order the chart's hooks run in, and the nexusctl install route as an alternative.
  • 2.7Installing Enterprise and applying a licenceWhat changes when you install the Enterprise edition, how to request a licence from your Adverant account, the three ways to import it with every refusal code, and how Harrow Port Authority moved its Community pilot to Enterprise in place without losing anything.
  • 2.8Single-machine installsInstall Nexus on one Linux server with nexusctl, or evaluate it on a laptop with k3d, and reach the console over HTTPS so that sign-in and passkeys work.
  • 2.9The installer disk imageBoot a bare server or a virtual machine from the Nexus installer image and it installs the operating system, k3s, cert-manager and Nexus with no network, checking every file before it is used.
  • 2.10Air-gapped installationCarry a signed offline bundle into a site with no internet, verify it against a key you brought in separately, load it into your own registry and install. Licences, updates and revocation lists cross the gap by hand too.
  • 2.11Variations: external stores, TLS and ingressThe values that fit Nexus to a cluster that isn't a blank one, TLS (Transport Layer Security) included, along with databases you already run, your own certificates, another ingress controller, storage classes, mail, proxies, replicas and managed Kubernetes.
  • 2.12The first runFrom an unclaimed installation to people at work. Make the claim code, claim the installation in a browser, create the first administrator with a passkey, then connect company sign-in and invite everyone else.
  • 2.13LicencesWhat a Nexus licence file contains, how the installation checks it offline, the six states it can be in, and how you request, import, renew and withdraw one.
  • 2.14AI providers and modelsHow the artificial intelligence (AI) Provider Router picks a model from the organisation's own pool of keys, and how scripts and AI tools reach Nexus from outside.
  • 2.15Day two: operating NexusThe routine work of running an installation after the first week. It starts with unsealing the key store after a restart and ends with uninstalling.
  • 2.16Security and networkingWhat an installation lets in and out, how its services prove who they are to each other, and the controls an operator sets or inherits for sign-in and the database.
  • 2.17TroubleshootingThe problems operators meet most often, organised by what you see. Each one gives the cause, the command that confirms it and the fix, and the chapter ends with sending a support bundle.
  • 2.18The extension modelThe six ways to extend Nexus, from a setting to a domain pack, the limits of each, and how trust and isolation levels decide where your code runs. Read it before you open the software development kit (SDK).
  • 2.19The rules every extension inheritsIsolation on three axes, compute through UNO, AI (artificial intelligence) through the router, organisation-owned keys and licence checks. What each rule means for your code and which gate enforces it, and why you inherit it instead of writing it.
  • 2.20SkillsHow to write, test and publish a Skills Engine skill, where it shows up once it's live, and how manifest skills in a plugin differ. Includes a worked berth-allocation summary for Harrow Port Authority.
  • 2.21The Plugin SDKInstalling the Plugin SDK (software development kit), its command-line tools, a tour of the full-service template, the v2 manifest field by field, and the twenty-two gates that hold a plugin to the rules.
  • 2.22The plugin runtimeThe SDK (software development kit) modules your plugin runs on, from the scope guard and the database fence to UNO dispatch, the AI (artificial intelligence) route read and licence checks. Then testing against a real database, registering your skills and onboarding.
  • 2.23Domain packsWhat a domain pack is made of and what its pack.json says; lenses and the lens registry; knowledge models, connectors and mobile overlays; how a pack is licensed and switched on for a unit; and the ten packs Adverant ships.
  • 2.24Building a custom vertical end to endA worked build of the Cold chain domain pack, from the first brief to a release running for every unit, with its knowledge model, lenses, a skill, a full-service plugin and sample data. Then how to extend a pack that already exists and how to add a lens to one that has shipped.
  • 2.25Building for each editionWhat changes when one extension has to work in every edition, on an air-gapped site, on a Nexus Edge payload or behind a customer's own brand. Covers the licence line for Enterprise modules and signed offline delivery, with a matrix of what to do differently for each target.
  • 2.26Building with AI coding toolsHow to build Nexus extensions safely with Claude Code and other AI (artificial intelligence) coding tools. It starts with connecting your IDE (integrated development environment) to the Workbench and a project CLAUDE.md that carries the platform rules, and ends with six worked prompts and the gate that proves each one.
  • 2.27Build scenariosA cookbook of thirteen builds, from a single skill to an air-gapped delivery. Each recipe gives the goal, the building blocks, the steps and commands, the gate that proves it worked, and what changes by edition and delivery form.
  • 2.28Releasing your extensionHow a plugin or pack goes from a green build to the units that run it, and how it comes back out again. Versions, release review, channels and installs, signing, change approvals, the delivery identity record, migrations, rollback and retiring a version.

Appendices: Reference

Download