You Might Not Need Posit Connect

1 Three jobs, no license required

Strip the branding and a commercial Posit deployment does three jobs. Workbench is a session broker - it launches an IDE as you, on shared compute. Package Manager serves curated, prebuilt packages, fast. Connect hosts the apps and reports you make. Every one of those jobs is real, and every one of them deserves a serious answer. The insight this whole page rests on: those are infrastructure patterns, not products - session brokering, package distribution, and publishing all have open, battle-tested implementations, and the interesting work is connecting them well.

What you give up is real too - pro drivers and push-button publishing - and if those carry your business, buy them (we teach a Posit-on-EKS install at technicalguide.ndexr.io built on this same software base). Note what is not on that list: a support contract. Support is the one item an open stack covers by construction - when the source is in front of you, a blocking bug is an afternoon of reading and a fix, not a ticket and a roadmap (§4 is exactly that story).

And then the part that usually separates a persuasive article from a usable one. Most “you could build this yourself” pieces end at the diagram, leaving the reader a year of integration work and a fair suspicion that the author's version only runs on the author's machine. This one ends at a download . The archive in §10 is the source of the platform you are reading, with the credentials and build state removed and nothing else held back: the recipes, both RStudio fixes, the portal and its launch forms, the CVMFS and S3 publishing scripts, the package-repo pipeline, the database schema, the edge tier, and the CLI that deploys the lot. A team that starts with an empty Ubuntu host and this zip ends with browser sessions on shared compute, governed packages, and published apps - the three jobs, all of them, none of them bought.

Be clear about which direction the rigour runs, too, because the usual framing has it backwards. The open stack here is not the budget substitute you settle for; it is the more exacting foundation . Every binary is produced by a reviewable recipe you can re-run (§4), the software tree is content-addressed, versioned and cryptographically signed before any machine may mount it (§5), the runtime carries its own libc and loader so a host OS upgrade cannot silently change your numbers (§3), and every package enters through one auditable door (§7). Those are reproducibility and supply-chain properties in the strict sense - the kind a regulated validation exercise actually asks for - and a licensed appliance whose build you cannot inspect cannot offer them at any price. That is the claim: for interactive R on shared compute with governed packages , the open stack is not merely sufficient. It is the sturdier place to start.

2 One platform, many domains

Before the software story, the organizing idea that makes this page possible. Everything at ndexr lives in the multi-domain model : one running application serves many subdomains, and each subdomain is one directory that is at once a git repository, a live website, and the code that stands its subject up . The layer that builds compilers lives at eb.ndexr.io - and so do its build recipes. The distribution layer lives at cvmfs.ndexr.io - and so do its scripts. The portal lives at ood.ndexr.io - and so do its app definitions. The documentation is the deployment, in the same directory, under the same version control.

That model is why handing the whole platform to someone else - a colleague, a client, or a Claude instance - is a download rather than a consulting engagement . There is no separate “deployment package” to assemble and no wiki to keep in sync, because the directory that serves each layer's page is the directory that deploys it. The archive in §10 is simply that tree, zipped.

3 Own your foundation: Gentoo Prefix

Every shared-software story begins with the same painful question: “will it run on your Linux?” The usual answers are a compatibility matrix, a fleet of containers, or an ops team that rebuilds everything for every OS upgrade. We chose a different answer, borrowed from the world-class scientific computing shops (this is the Compute Canada pattern): ship your own foundation . A Gentoo Prefix is a complete userland - C library, loader, core tools, compiler - installed under one directory that travels with the software tree. A binary from this stack borrows exactly two things from the machine it runs on: the kernel, and the mount . Nothing else.

readelf -l <any stack binary> | grep interpreter
#   -> /cvmfs/software.ndexr.io/.../ld-linux-x86-64.so.2
#
# even the dynamic loader is ours - the host OS is just a kernel to us.

Why this is worth it: the question “will it run on your Linux?” stops existing . Ubuntu, Rocky, Amazon Linux, this year's release or last year's - the stack behaves identically, because it brought its own everything. OS upgrades stop being software migrations. New machines need no software install. And the same discipline extends across CPU families: we maintain the foundation for both x86-64 and ARM , side by side, so the fleet can mix Intel and Graviton without anyone noticing. The honest trade: owning your foundation means owning the seam where it meets the host - a real engineering cost, paid once, recorded in this page's bundle so you do not pay it twice.

4 Recipes, not snowflakes: EasyBuild and the fix

On the foundation, EasyBuild builds everything else - compilers, math libraries, R, and RStudio Server itself. The idea to steal is not the tool but the discipline: every piece of software is a recipe - a small, reviewable text file (an “easyconfig”) that states exactly what is built, from what sources, with what dependencies. Builds stop being artifacts someone once produced and become code you can re-run : auditable in review, repeatable on a new machine, diffable across versions. That is what makes the stack transferable at all - the recipes in this page's bundle rebuild it on your hardware, for your chosen versions.

And then the payoff, which is the best argument for open infrastructure we can offer. Note the word used here, because it is chosen: we did not patch RStudio, we fixed it. A patch is a modification to something that works. This was software that did not run on current R, because the vendor had not kept up. When R 4.6 shipped, RStudio was not ready for it - the current IDE still pins the previous R. A commercial customer waits on a vendor roadmap, or on whatever the vendor's licensing policy happens to be that year. We did not have to: the IDE is open source and the build is a recipe, so we fixed it - two small, careful fixes that let RStudio 2024.12 run on R 4.6, restoring what changed in R's interfaces and reviving the Plots pane. The fixes sit beside the recipe in the same directory, and that build has been the platform's production IDE ever since - serving current R while the vendor's own release still does not. That is the power being demonstrated : when your platform is recipes on open source, the answer to “the vendor has not caught up yet” is an afternoon of engineering, not a year of waiting.

There is a stranger postscript, and it is worth stating plainly here rather than burying it. We proved we could fix it, and then largely stopped using it ourselves - the agentic interface in §8 took over most of our own working day. That changes nothing about this section's claim, and arguably sharpens it: the fixed IDE is still built, still published for both architectures, and still one click away in the portal. The capability is real whether or not the people who built it happen to use it.

# the same recipe, patches, and hooks that built our tree - on your machine:
eb RStudio-Server-2024.12.0+467-foss-2024a-R-4.6.1.eb --robot --rpath \
   --sysroot="$EPREFIX" --hooks=eb/hooks.py

# or skip the build: prebuilt trees are published for BOTH architectures
$ ls /cvmfs/software.ndexr.io/
aarch64-linux-gnu/   x86_64-linux-gnu/

Two build rules keep the result universal, and both are worth copying. Everything is compiled for the generic baseline of each architecture, with math libraries that pick the fast code path at runtime - so a binary built here runs on any x86-64 or ARM machine a client might own. And every binary carries its library paths inside itself , pointed at the tree - so nothing depends on environment variables being just right. Boring rules, chosen deliberately: they are what let one published tree serve every machine.

5 Publish once, run anywhere: CVMFS from S3

A build on one machine is not a platform. The usual next step - install it everywhere - is where shared software goes to die: drift, partial upgrades, snowflake nodes. The pattern that scales is the one CERN invented to feed software to hundreds of thousands of machines: stop installing, start publishing . The built tree is published into CVMFS - a read-only, versioned, cryptographically signed file system that every machine simply mounts. Publishing is one transaction on one machine; consuming is one mount everywhere else. Nodes cannot drift, because nodes do not install anything.

Our twist is where the published bytes live: the origin of the tree is Amazon S3 . Not S3 pretending to be a disk - S3 doing what S3 is best at, serving immutable content durably and cheaply. The platform host passes requests through to the bucket; clients carry a second URL pointing straight at it. The pleasant consequence: the software outlives the servers . The distribution machine can be rebuilt from the bucket; every running session keeps working while it happens.

CVMFS_SERVER_URL="http://cvmfs.ndexr.io/cvmfs/@fqrn@;https://ndexr.s3.us-east-2.amazonaws.com/cvmfs/@fqrn@"

One boundary is drawn deliberately here, and it is worth stating outright because it is easy to get wrong: the tree ships interpreters and libraries; packages are served, not shipped (§7). Distribution and package management are two independent problems. They move at different speeds - a toolchain changes a few times a year, a package index changes daily - and they have different consistency requirements, so binding them together makes both worse. Keeping them apart is what lets the tree stay small enough to publish quickly and lets the repository stay current without republishing anything. You may recognize that split as exactly the line the commercial suite draws between two separate products; it is the same boundary, reached from the architecture rather than the price list.

6 Sessions in the browser: Open OnDemand

Now the part your users actually see. A scientist opens ood.ndexr.io , signs in once, picks an R version, cores, and hours, and clicks Launch. A few seconds later RStudio is in their browser tab - running not on their laptop but on cluster compute, with their home directory exactly where they left it, on every machine, every time. That experience is Open OnDemand - the open portal that universities and national labs run at enormous scale - doing the job teams usually buy Workbench for: sessions as a service , scheduled onto shared compute by Slurm.

Under the hood there is one elegant handshake worth understanding, because it is the whole philosophy in miniature. The session pairs two builds of RStudio working together : a thin server from the host handles sign-in and identity - the things a host does well - and immediately hands the actual R session to our fixed RStudio from the mounted tree . Each side does only what it is best at. And the direction of travel is even better: the container variant already drafted in the portal runs everything from the tree, so the endgame is a compute node with nothing installed but a kernel and the mount - add a machine, and it can serve sessions.

Security-wise the portal follows the same trust shape as the commercial product: sessions sit behind the platform's single sign-on and are reachable only through the portal's authenticated proxy. One sign-in, one identity, one home directory - from the portal to the cluster to the session.

7 Packages that just install: repo.ndexr.io

The quietest layer is the one users would riot without. In a session on this platform, install.packages() returns in seconds - because what arrives is a prebuilt, validated binary , compiled by the same recipes on the same toolchain as the R that is asking, served from the platform's own repository. No compilation at the desk, no “please install these system libraries first”, no version roulette. This is the job Posit Package Manager is bought for, done by repo.ndexr.io : an internal repository of R and Python packages, organized by architecture, with S3 behind it.

> install.packages("jsonlite")
trying URL 'https://repo.ndexr.io/eb/...'    # <- the default, baked into R
# no setup, no .Rprofile, no instructions to follow. it is just where
# packages come from on this platform.

The detail that makes it governance rather than convenience: the repository address is baked into R itself at build time. Every session, however launched, resolves packages to the internal repository by default - which means the organization has one door through which packages enter. One door is a validation story (qualify a package once, everyone gets the qualified build), an air-gap story (the platform does not need the public internet at install time), and an audit story (what is available is what you published). This is the other half of the boundary drawn in §5: packages are not cargo for the software tree, they are a service with its own home, its own cadence, and its own governance.

8 The interface, reconsidered: exec, agents, and the side panel

Everything so far has treated “the IDE” as the destination: schedule a session, load the tree, land in RStudio. That is still the right answer for interactive analysis on shared compute, and §4 is the proof we take it seriously - we fixed the thing ourselves to keep it alive on current R. Here is the honest postscript to that story: we proved we could, and then we mostly stopped using it . Not for another editor - for an agentic IDE we built into the platform itself : a conversation sitting next to the thing being changed, an agent that already knows which domain it is looking at, with the repository, the terminal, and the live site one tile away.

Say the obvious thing before anyone has to ask it: none of that strands the people who want the IDE . RStudio here is not a legacy path being quietly retired - it is the unencumbered one. It is fixed, built from the recipe, published in the tree for both architectures, and one click from the portal, running a version of R that customers of the commercial product are still waiting on. That is the odd shape of this whole page, and we would rather point at it than hide it: the layer we personally use least is the layer where the open stack is furthest ahead . Choosing not to use a capability is a very different thing from not having it.

Two domains carry the agentic side. exec.ndexr.io is the agent runner: one conversation per surface , where the surface arrives in the URL and is never guessed at. The composer around it is deliberately small - attach a file, pick a run mode (build, plan, or ask, where plan and ask are enforced read-only), pick a model, pick a skill, or just talk to it. agents.ndexr.io is the wall: the same domains viewed through lenses - Exec, Terminal, Code, Site, Git - one at a time, or all at once as a grid you leave running on a second monitor.

The mechanism underneath is one query parameter, and it is the part worth stealing. A page loaded with ?pane=1 renders as a tile : the shared shell does not merely hide the navigation, the operator bar and the deploy watcher - it never builds them , and their servers never mount. So the side panel is not an application someone wrote. It is a mode that every page on the platform already has , which is why any surface can be embedded beside any other.

# every lens is a URL; embedding one just adds a flag
https://exec.ndexr.io/?domain=ymnnpc.ndexr.io&pane=1     # the agent, scoped to this site
https://terminal.ndexr.io/domain/?arg=ymnnpc.ndexr.io    # a persistent shell in the same tree
https://code.ndexr.io/?domain=ymnnpc.ndexr.io&pane=1     # the files

# ?pane=1 is read by the SHARED shell, not by any one app:
#   nav, operator bar, deploy watcher -> never built, servers never mount
#   so a tile costs a fraction of a full page, and any page can be a tile

That is where the multi-domain model (§2) pays off a second time. Because every domain is one directory that is at once a site, a git repository, and its own code, the panel needs to know exactly one thing about a domain: its name. There is nothing per-site to configure, no plugin to register, no workspace file. Which means a custom IDE here is a choice about layout, not a build - decide which lenses go in which tiles for the way you work, and that arrangement translates to every site you own, including the ones that do not exist yet.

9 How it all connects

Read bottom-up, the whole design is one sentence per layer, each one existing so the next can be simple. The prefix owns the foundation, so nothing depends on the host OS. EasyBuild turns software into recipes, so the stack is reproducible anywhere - including an RStudio we fixed when the vendor would not. CVMFS with S3 behind it turns installation into publication, so a thousand machines are as easy as one. Lmod makes the tree discoverable ( module load R ). Open OnDemand turns all of it into a button a scientist clicks. And repo.ndexr.io feeds every session validated packages through one governed door. Above all of it sits the interface layer - exec, agents, and pane mode - which is the only layer that is not borrowed from research computing, and the one that changed how the platform is actually operated.

Wrapped around all of it, the multi-domain model keeps every layer honest: each is a living directory - site, repo, and code together - so the platform documents itself and travels as files. That is also why the layers decouple cleanly. Adopt the tree without the portal, and your users get module load R on every machine. Adopt the portal without the tree, and browser sessions come to whatever software you have. Adopt the repository pattern alone, and package governance improves overnight. Together, they are the platform this page is named after.

10 What is in the archive

The download is not an excerpt of this page - it is the platform source . One archive, one top-level ndexr/ folder, and inside it the repository in its true hierarchy: the router and the shared module library, the Postgres schema, the edge tier, the compose stack, the Rust CLI that deploys all of it, and the research-computing tier this page is about - the easyconfigs, both RStudio fixes, the portal and its apps, the CVMFS and S3 scripts, and the small system files that usually live only in prose. Unzip it into your home directory and you have ~/ndexr , which is exactly what every path in the documentation assumes.

The whole tree is in the zip, so anything named anywhere on this page is on disk once it unpacks; there is no second download and no component left as an exercise. Each job a Posit deployment is bought for has its counterpart inside: Workbench → the Open OnDemand portal, its apps, and the node provisioning script; Package Manager → the repo pipeline and the R build that makes it the default; RStudio Pro → the recipe and the two fixes that keep the open IDE current; Connect → the multi-domain router, the shared module library, and the CLI that deploys a new site in one command. Plus the parts no vendor ships you at all: the Gentoo Prefix recipe, the signed CVMFS distribution, and the agent interface from §8.

What to do with it. INSTALL.md brings the platform up on a clean Ubuntu host: build the CLI, write your own .env , ndexr deploy , point a wildcard record at the box, then add your first domain as three files and a registry row. CLAUDE-DEPLOY.md does the same for the HPC tier, and records the sharp edges we already paid for - which session ABI to standardize on, which drafts are not production yet - so your team does not pay for them again. Neither document assumes you keep our stack: mount ours while you get going - prebuilt trees are published for x86-64 and ARM, and a new machine needs only the mount - then build your own from the same recipes, on your hardware, at your versions.

10.1 What the archive assumes you have

Two tools are assumed, and it is fairer to say so here than to let you discover it in the runbook. The first is the AWS CLI , because the distribution layer's origin is a bucket (§5) and the deploy path expects credentials that can reach it. The second is Claude Code , or an equivalent coding agent: CLAUDE-DEPLOY.md is written to be handed to one, and the interface layer in §8 is built around one. Neither is load-bearing for the stack itself - the software tree, the portal and the repository have no opinion about who typed the command - but the runbooks read as though an agent is doing the typing, because here one usually is.

A word on the credentials you give either of them, since this is where the pattern matters more than our particular file. Do not hand an agent your own console-grade keys. Scope a role to the job - the bucket prefix that holds the tree, the hosted zone for the subdomain you are standing up, the cluster you are deploying to - and keep the policy JSON in the repository, next to the thing it governs, so it reviews like code and diffs like code. That is the same discipline §4 applies to builds and §7 applies to packages, pointed at permissions: if it is not a reviewable file, it is not governance . An agent working under a narrow role is a normal automation account. An agent working under your credentials is an audit finding.

And it is a foundation, not a finished product - deliberately. What you unzip is a platform we run every day, which means it is opinionated where we had to decide and unfinished where we have not needed something yet. The runbook says which parts those are. But the properties that are hard to retrofit are already in place from the first command: reproducible builds, a signed and versioned software tree, one governed door for packages, and a runtime that does not inherit the host's libraries. Those are the expensive things to retrofit. The work left after that is configuration and policy, which is work only you can do anyway.

No git history travels with it, by choice. What you get is the tree; INSTALL.md has the two commands that make it a repository of yours, per domain or all at once. The argument itself travels two more ways, both at the top of this page and both generated from the same source: the slide deck , which you read here rather than download - it is the whole case in twenty slides, for the architecture meeting you are about to be in - and the audio narration for the commute. The artifact pattern is shared with technicalguide.ndexr.io and pkgvalidation.ndexr.io , and is itself packaged as reusable skills at skills.ndexr.io .

11 Standing it up: the staged path

There is no installer here, and that is not an omission. An installer assumes a finished product with a fixed shape, which it copies onto your machine. This is not that. What is being handed over is a way of working - so the honest form is a guided path rather than a curl | sh . Nine stages, each one bringing a repository from the archive to life inside your own environment, and each ending in one checkpoint command with an expected output . A stage you have not passed is a stage you cannot skip, because the next one depends on it and will fail later and more confusingly than it would have failed here.

The assumption throughout is that you and an agent do this together (§10.1). CLAUDE-DEPLOY.md in the archive is addressed to an agent rather than to a person, which is why the steps below are described rather than scripted: the runbook is the script, the agent reads it, and you supply the judgement and the credentials.

The order is the dossier's own argument pointed at your machine. Stage 1 is mount, not install - a laptop with a CVMFS client gets a complete validated R toolchain in minutes, having compiled nothing and created no cloud resources. A reader who does only stage 1 has still watched the thesis work on their own hardware. Everything after it is about becoming a publisher instead of a consumer, and that is the point where you need a machine of your own.

test -d ~/ndexr/src/domains && test -f ~/ndexr/LICENSE && echo ready

ls /cvmfs/software.ndexr.io/ && module load R && R --version

aws sts get-caller-identity

curl -sI https://<your-first-domain> | head -1

readelf -l $(which R) | grep interpreter

ls /cvmfs/<your-repo>/

Rscript -e 'install.packages("jsonlite"); cat(getOption("repos")[[1]])'

open the portal, pick R and cores, click Launch

sign in as a second, non-admin person