When ndexr is the right call.
Self-hosted R infrastructure used to require a DevOps team and months of setup. That complexity is gone. The stack — multi-tenant routing, a versioned package mirror, LLM-assisted deploys — is something one engineer now assembles and operates. ndexr is that stack, proven on the same infrastructure you're looking at.
Three players, three trade-offs
Most R teams interact with all three at different points. The question isn't which one is right — it's knowing which problem each one solves, and where the boundary is.
Hosted IDEs, hosted publishing, managed package mirrors. Trades operational simplicity for vendor dependence — pricing, roadmap, and uptime are the vendor's. Strong fit when the alternative is a team you do not have.
Bespoke build, bespoke advisory. Trades scope-control for cost and time. Strong fit when the project's surface area is genuinely novel and the team needs the lift.
The substrate is in the operator's account; the source is open; the team carries the on-call. Trades the comfort of a vendor for ownership of every layer.
Where prices are hitting floors
Managed platform pricing was set when running this yourself was genuinely hard. Every layer that justified that price has since gotten cheaper or easier. The market hasn't caught up yet.
| Layer | Direction | What it means for self-hosting |
|---|---|---|
| Compute (CPU, RAM) | $/hr falling for 15+ years; ARM and Spot widen the floor. | A production EC2 with 10 Shiny replicas costs less per month than a single managed-service seat. |
| Storage (S3) | Per-GB has dropped roughly 10× this decade. | Pinning ndexr's renv.lock to S3 — exact versions, kept forever — is cents per month. |
| Egress (within region) | Free for in-region GETs; cross-AZ is pennies. | Package installs from your own bucket are faster and cheaper than from the public internet. |
| LLM inference | Falling roughly 4× per year for capable models at the small-and-fast tier. | Pipelines that depend on LLM classification are now within a hobby budget; LLM-augmented features stop needing approvals. |
| Open IDE upstreams | Mature Code-OSS-derived browser IDEs are now well-established. | Building an IDE used to mean writing one. It now means picking an upstream and adapting it. |
| Auth + identity | OAuth, OIDC, HMAC tokens are commodity primitives. | Cross-subdomain SSO is a 200-line service and a parent-domain cookie, not a vendor. |
| Maintenance complexity | LLMs can now read, write, and reason about infra code. | Config changes, commit messages, and deploy pipelines that used to need a second engineer now run inside the platform itself. |
Where ndexr is the right call
Green is a clean fit. Blue means ndexr complements what you already use. Grey means a different category of provider is probably the right answer first.
TLS, multi-domain routing, package mirror, deploy CLI — wired up in hours, not months. The substrate this whole site runs on.
Every CRAN version that ships during your time on the platform is preserved in your bucket. Apps that have to be reproducible in five years stay reproducible.
One Shiny pool serves arbitrarily many subdomains by Host header, with per-tenant code and state isolation. Adding a product is a file plus an nginx block.
The CLI orchestrates podman, nginx, AWS, and the local Claude CLI through one binary. The LLM is a tool, not architecture.
ndexr is happy to sit next to it: the same bucket can mirror packages for both, and ndexr can host the apps that don't fit the vendor's pricing model. We are not asking you to migrate.
If your differentiator is a polished single-product UI, a UX-led shop is a better first call. ndexr is the substrate underneath such a thing, not the design.
How to try it
ndexr is in production and taking customers. The package mirror at repo.ndexr.io and the operations stats at stats.ndexr.io run on the same stack we provision for customers — your domain, your AWS account, the same infrastructure. Sign in to start provisioning.