A workbench for data‑science teams, with a deploy command¶

Hub puts RStudio, VS Code and JupyterLab in the browser, with Claude Code and Posit Assistant set up to know the platform. When a project is ready, hub deploy turns it into a running app, report, API or pipeline that colleagues open with their company login. It runs on a machine we operate for you, or on your own Kubernetes cluster, and it is built from open-source parts.

Installation Configuration Release notes

Who it is for¶

Teams that work in R and Python and need their code, their data and their apps to stay inside the company: a data-science group in a mid-sized company, a research unit, a consultancy with several clients. The people who use it are analysts and data scientists; the people who run it are an IT department or us. Nobody has to learn Docker, Kubernetes or YAML to get an app in front of a colleague.

What you get¶

Three IDEs, one home¶

RStudio Server, VS Code and JupyterLab, started from one page. Every user has a persistent home directory that all three share, and picks a size for each session. Several sessions of one IDE can run side by side.

A coding agent that knows the hub¶

Claude Code in VS Code and JupyterLab, Posit Assistant in RStudio. Both get the same instructions, rules and skills from the platform: how projects are laid out, how a deploy works, what to do when a build fails. You add your own without rebuilding an image. A hub without any AI is one setting.

Deploy from the IDE¶

hub deploy builds the project in the current directory, pushes the image and registers it: Shiny in R and Python, Quarto and R Markdown, Plumber and FastAPI APIs, MCP servers, targets pipelines on a schedule. Who may open an app is a list of groups in hub.yaml. The last ten versions stay available for hub rollback.

Your identity provider¶

Keycloak, Microsoft Entra ID, Okta, Auth0 and Cognito over OpenID Connect, LDAP and Active Directory, or SAML. The groups the provider sends decide who is an admin and who sees which app. APIs accept the provider's tokens too, so a script or another service calls them with a real identity.

Your packages, your network¶

The R and the Python package stack are a text file each, pinned to a snapshot date. A private mirror, company CA certificates and extra system packages go into the configuration and reach every image. The layer that carries them is built inside your network.

Releases you can roll back¶

A release is one versioned artifact. install.sh upgrade moves a hub to a version, with a backup first; rollback goes back. Backups go to an S3 bucket, dashboards show usage and app logs, alerts arrive by mail, and diagnose writes one archive for us when something is wrong.

A deploy, start to finish¶

Open RStudio or VS Code on the hub and start a project: hub::new_app("sales", template = "shiny"), the New Project dialog, or ask the agent.
Work as usual. renv or uv record the dependencies; the agent knows the layout of the project and the commands of the hub.
Run hub deploy in the project directory. The hub builds an image with your packages and their system libraries, pushes it to its registry and registers the app. The first build takes minutes, a redeploy with the same dependencies seconds.
Colleagues open the app with their company login. hub.yaml says which groups may.

What that looks like in the terminal, build output left out:

$ hub deploy
hub: packing /home/rstudio/sales as 'sales'
hub: building sales as registry.hub.acme.example/apps/sales:latest (shiny; mode: renv, Dockerfile: generated, renv.lock: yes)
hub: system packages: libcurl4-openssl-dev libssl-dev
...
hub: pushed registry.hub.acme.example/apps/sales:latest (sha256:3f9c1a7e2b04)
hub: app registered; the apps instance is rolling out (about a minute)
hub: https://apps.hub.acme.example/app/sales

Hosted, or on your own infrastructure¶

A machine we run for you¶

A dedicated server per customer, never shared. We install it, upgrade it and watch it; your team logs in with your identity provider and works. The configuration is yours and travels with you.

Your own server or cluster¶

One command on a fresh Ubuntu server, or the same installer from a jump host for a Kubernetes cluster you already have. Your data, your network, your identity provider. The platform images come from our registry with your account; the layer with your packages and certificates is built where you are.

Built from open-source parts¶

ShinyProxy and the ShinyProxy Operator run the sessions and the apps; k3s, Caddy, BuildKit, a container registry, Redis, Velero, Grafana, Loki and Prometheus do the rest. There is no proprietary runtime in the path of your code: what hub deploy builds is a container image you could run anywhere, and what you write is an ordinary R or Python project.

Getting it¶

A trial is one command on any Ubuntu server, no DNS needed, with an account from us. Write to stefan@linnerprogramming.com for an account, a hosted machine, or a quote.