Skip to content
Interfaces for every business user · every domain, every way in

Every business system, every way of working with it — one visual surface.

aws.ndexr.io hpc.ndexr.io git.ndexr.io
The launch pad

Logged in — here's where to go

One authenticated door. When you land here you are already signed in, and every place you might need is one obvious click away — write code , get approved packages , or deploy an application . Nothing to figure out, nothing to install first.

Posit Workbench

Your development environment for R and Python, with the validated stack already mounted — open it and start working.

How you get in: Sign in with your company account; a session launches on controlled compute.

Open Workbench

Posit Package Manager

One approved, versioned source for every package, so every install is reproducible and traceable.

How you get in: Point your installer at the internal repository URL — it's pre-configured in Workbench.

Get packages

Posit Connect

Publish an application, report, dashboard, or API once — it's hosted, authenticated, and shareable.

How you get in: Push-button deploy from Workbench, or publish directly from your project.

Deploy to Connect
This is the single starting point — get in, get pointed, get working. The sections below explain what sits behind it: validated compute, an immutable software stack, and an audit trail on everything.
What ndexr is

Interfaces for every business user

ndexr turns every part of the business into something a person can actually reach and operate — and it is not just for scientists with code . Whatever someone's role, there is an interface that fits how they work: a visual page, the code, Git, a terminal, or an executive agent that does the work for them. Each domain offers all of these at once, and together they form one visual surface over the whole business .

01

For every user, not just engineers

Whatever a person's role, there is an interface that fits how they work — a visual page, the code, a terminal, or an agent that operates the system for them. Nobody is locked out for not being technical.

02

Every domain, every way in

Each part of the business exposes all of its interfaces at once — the visual UI, the code, Git, a terminal, and an executive agent — wherever that domain happens to run.

03

One visual surface over the business

Those interfaces roll up into a single surface. A business user reaches finance, infrastructure, code, or operations from one place, without knowing where any of it runs.

The access model

Every domain, five ways in

Every domain exposes the same set of interfaces at once . You are looking at one of them now — the visual UI — but the code, an editor, a terminal, Git, and an executive agent all reach the same domain, wherever it runs. Pick the one that fits the task; they are views onto the same thing, not separate tools.

Any domain wherever it runs hpc · aws · billing · … Visual UI the web page — this surface Code / IDE ide.ndexr.io Terminal a shell on the box Git & release git.ndexr.io Executive agent operates it for you
A domain is reachable five ways at once: its visual UI , a code editor ( ide.ndexr.io ), a terminal on the box it runs on, Git & release ( git.ndexr.io , version control and a proper release process), and an executive agent that can operate it on your behalf. Same domain, five doors.
The surface

One visual surface over the business

Roll every domain up and you get a single surface a business user can browse — infrastructure, code, finance, and operations side by side. The point of the surface is that you reach the information without needing to know which system holds it or where it runs.

One visual surface every business user browses here — without knowing where each system runs aws hpc git billing costs people compute software stack code & releases revenue cloud spend the org
Technical and business domains sit on one surface — aws and hpc beside billing , costs and people . A user reaches any of them from the same place; each still carries its own five ways in underneath. This page is one tile on that surface.
Under the surface

One server, every domain, isolated

That single surface is not a monolith. Every *.ndexr.io enters one server through nginx , hits app.r — the router — and branches by host to the domain that owns it. Each domain is its own isolated unit: its own directory, its own agent , its own git repository and release process — and from there it can reach into the rest of the business.

ONE EC2 SERVER nginx :443 · the one entrypoint app.r the host router branches by host every *.ndexr.io enters here hot-reloads on the next request workflow — content / UI own agent · isolated git dev-NNNN · release hpc — compute own agent · isolated git dev-NNNN · release aws — infrastructure own agent · isolated git dev-NNNN · release billing — business own agent · isolated git dev-NNNN · release The rest of the business · other domains · postgres registry · the audit ledger · the CVMFS stack · AWS · Route 53 each domain reaches out here
One nginx entrypoint and one router — app.r — fan out to every domain, grouped by type (content, compute, infrastructure, business). Each domain is a self-contained unit with its own agent , isolated git on a dev-NNNN branch, and a release process — and each reaches the rest of the business: other domains, the registry, the audit ledger, the compute stack. Add a domain and nothing else changes; it is one more branch off the same entrypoint.
A worked example — the scientist

One business user, in depth: the path to validated code

Take a single user and follow their interface all the way down. A scientist 's way in is code and a terminal on validated compute; because their results must be reproducible and defensible , their slice shows the platform at its most demanding. They never assemble the environment — they receive one. Four steps, left to right; underneath, the control plane records the provenance of everything they touch.

1 2 3 4 Scientist begins a piece of work aws.ndexr.io provisions isolated, controlled compute CVMFS mounts the validated stack, read-only Validated work every result traces to one fixed environment hpc.ndexr.io · append-only, hash-chained audit ledger every build variable recorded · any run replays from its recorded inputs
The scientist starts work and launches a session at aws.ndexr.io ; that gives them isolated compute with the validated stack mounted read-only from CVMFS . Everything from the environment down is recorded by hpc.ndexr.io in an append-only, hash-chained ledger — so the result they produce is tied to a fixed, reproducible environment and an evidence trail, without the scientist managing either.
aws.ndexr.io — where the compute comes from

Isolated compute, provisioned from one validated image

aws.ndexr.io is the cloud-infrastructure surface: it provisions and manages the machines. Each scientist gets their own server — independent compute, not a shared login node — launched from a single controlled base image.

Controlled base image (AMI) one validated starting point · carries the CVMFS client Scientist A Scientist B Scientist C own EC2 instance own EC2 instance own EC2 instance isolated · no shared state isolated · no shared state isolated · no shared state one validated /cvmfs stack mounted read-only by every instance — byte-identical everywhere
One controlled base image is the only starting point, so every instance begins from the same validated state. Each scientist runs in an isolated EC2 instance — no shared state to cross-contaminate a result — and every instance mounts the same read-only /cvmfs stack . The instance type (and therefore the exact CPU a build or job runs on) is itself a controlled variable, recorded per launch.
Isolation removes a whole class of “it worked on the shared box” failures; provisioning from one image removes “the machine was set up differently.” Both are decisions made once, centrally — see aws.ndexr.io .
hpc.ndexr.io — the validation engine

How the validated stack is produced — and proven

hpc.ndexr.io is the control plane. It builds the software stack from the bottom up, proves every artifact clean as it is built, and records every variable — so “validated” is a fact on disk, not a claim.

kernel prefix eb cvmfs software repo built bottom-up, one layer at a time — a gate blocks each layer until the one below it is complete each layer pins its inputs and retains its outputs · nothing floats on ‘latest’ Build-time proof every binary is audited (readelf) as it is built it may resolve only to /cvmfs — zero host leakage a contaminated build fails; it never ships Hash-chained audit ledger append-only — the single write path every variable of every build step recorded any artifact replays from its recorded inputs A validated, immutable software stack published once · versioned forever · a published revision never mutates
The stack is built bottom-up through a gated chain — a layer cannot start until the one below it is complete, and each layer pins its inputs and retains its outputs. As every binary is built it is audited : it may resolve only to the controlled /cvmfs tree, so a contaminated build fails rather than shipping. Every variable of every step is written to an append-only, hash-chained ledger , and the result is a validated, immutable stack that is published once and never mutated.
This is what lets a result stay defensible: the environment behind it can be replayed from its recorded inputs, and the record that it was built clean is tamper-evident. hpc.ndexr.io orchestrates and proves the whole chain.
The payoff

Reproducible across systems, and across years

Because the stack is immutable and versioned, the environment a result ran in is a named artifact that still exists. Reproducing an old result is mounting the same version — not rebuilding the world.

/cvmfs/…/2024a one immutable epoch read-only · content-addressed A scientist’s laptop same software, resolved the same way An on-prem / HPC cluster mounted in minutes, no rebuild The cloud — aws.ndexr.io provisioned on demand byte-identical byte-identical byte-identical 2024 2031 the same epoch still mounts — reproducing a result is mounting it and loading the module
One immutable epoch mounts byte-identical on a laptop, an on-prem cluster, or the cloud — the same software, resolved the same way, everywhere. And because a published version never changes, that epoch still mounts years later : a result computed today can be reproduced by mounting the version it named and loading the same module.
How the decisions are made

The controls, distilled

The guarantees above are not a matter of care or preference — they are enforced by a small set of controls every part of the platform is held to. Each closes a specific way a result could quietly become irreproducible.

One way in
Every environment is entered the same single way. No hand-rolled paths, no second activation route — one door means one thing to validate.
Controlled where-it-runs
The machine a build or job runs on is a recorded variable. Compute is provisioned from one validated image, never a hand-configured box.
Proven at build time
Every binary is audited as it is built. Anything that reaches outside the controlled tree fails the build — it is impossible to ship a contaminated artifact.
Pin inputs, retain outputs
Every layer fixes what it consumes and keeps what it produces. Nothing depends on 'latest', so any result can be rebuilt from its recorded inputs.
An immutable, hash-chained record
Every variable of every build step is written to an append-only, tamper-evident ledger — the evidence that the environment is what it claims to be.
An established model, not a bespoke one
The whole approach mirrors a national-scale research-computing stack proven across dozens of systems — validated prior art, deliberately not reinvented.
The model is deliberately borrowed, not invented: it mirrors the Digital Research Alliance of Canada research-computing stack, which serves one identical software environment across dozens of national systems. Choosing proven prior art over a bespoke design is itself one of the controls.