OpenCPU: an HTTP API for running R in production and in the notebook

R functions as HTTP endpoints, with RPC and data interchange

OpenCPU is a system for embedded scientific computing and reproducible research with R, and its core idea is simple enough to state in one line: the server exposes a small HTTP API for RPC and data interchange with R.

The point of that design is separation of concerns. A statistical routine stays an ordinary R function in an ordinary R file, and the server makes it callable over HTTP without the function being rewritten as a web service, and without the caller needing to speak R. A browser app, a Python script or a JavaScript client can all call the same endpoint.

The documentation list points to the layers of the system. There is official API documentation, a paper titled Towards a Universal Interface for Scientific Computing through Separation of Concerns on arXiv, a set of example apps, a separate JavaScript client named opencpu.js, and a server manual distributed as a PDF.

The stated audience is anyone building statistical services or R web applications. The phrase embedded scientific computation is doing specific work there: the routines are meant to be called as part of a larger system, not to be a monolithic service in their own right.

Two deployment shapes: a session server and an Apache2 stack

The same package runs in two very different ways, and the distinction is the most important operational fact about OpenCPU.

The first is a single-user development server that runs inside the interactive R session. This is the mode a developer uses while writing an app, and it is started from R itself:

library(opencpu)
ocpu_start_server()

There is also a start command for a specific app:

ocpu_start_app("rwebapps/stockapp")

The second is the multi-user cloud server, described as a Linux stack based on Apache2, installed as a package on Ubuntu Server:

#requires Ubuntu 22.04 (Jammy) or 20.04 (Focal)
sudo add-apt-repository -y ppa:opencpu/opencpu-2.2
sudo apt-get update 
sudo apt-get upgrade

#install opencpu server
sudo apt-get install -y opencpu-server

#optional
sudo apt-get install -y rstudio-server 

That block is the whole installation story on Linux, and it says several things at once. The server is distributed as a Personal Package Archive dedicated to the 2.2 series, so the version of the server you get is tied to that line. It requires a specific pair of Ubuntu releases, 22.04 Jammy or 20.04 Focal. And RStudio Server is listed as optional, which tells you the intended workflow is editing R code on a remote machine and calling the endpoints from elsewhere.

The RStudio integration is the reason the Apache2 stack exists in this form rather than as a bare R process. Apache2 terminates HTTP and dispatches to R, which is what makes the difference between a development server bound to your laptop and something that can serve several people.

The version split between the R package and the server

There are two version lines in this project and they are not the same line.

The R package is published on CRAN, and the badge in the readme points at the CRAN package page. Its recent releases are v2.2.12 from 2024-05-24, v2.2.11 from 2023-08-06 and v2.2.8 from 2022-05-18.

The server is a separate installable artefact, and the apt command adds a PPA named for the 2.2 series, so the server distribution is also on a 2.2 line. The example app path in the readme, rwebapps/stockapp, is from the same rwebapps repository, and the example files in this repository include examples/apps.R, which is the R source for at least one of those apps.

Keeping the package on CRAN and the server on a PPA is a deliberate split with a practical consequence. The R package side gets a broad audience and a slow, careful release cadence, and the server side can move faster. The cost is that the two must be kept compatible, and the readme does not document the supported pairings the way other projects publish a compatibility matrix. If you are pinning versions in a deployment, the news file and the changelog are where to look, not a table.

On maintenance: the repository is not archived, and the last push was on 2026-05-31. The code is still being touched even though the newest tagged package release is more than two years old, which is typical of a CRAN-published package where a new version needs to clear review before it appears.

What the HTTP API gives you, and what it does not

It is worth being precise about the interface, because the term API covers a lot here.

The readme describes it as a simple but powerful HTTP api for RPC and data interchange with R, and points to the official API documentation for the details. The JavaScript client, opencpu.js, is a separate repository, and the presence of a first-party client for one language is a hint about the calling convention: the server is meant to be invoked programmatically from another runtime, with JSON as the interchange format.

What the system gives you is a uniform way to call a named R function with arguments and get a result back, plus a mechanism to ship data alongside the computation. The example apps hosted on the project website show the shape of a real application, and the paper on separation of concerns is the argument for why the interface is shaped that way.

What it does not give you is a specification for the semantics of your statistics. A response can carry a warning, an error or a value, and the caller has to handle all three. Nor does it give you a versioned contract for your own functions, since the contract is whatever your R function accepts. The API makes a function callable; it does not make it safe to call from an untrusted client.

That last point is the one to keep in mind when the audience for an endpoint is not your own team.

Why a R runtime behind the endpoint is the trade-off

The alternative to OpenCPU is not nothing, and the comparison is what makes the decision clear.

The obvious alternative is to rewrite the statistical routines in a language with a production-friendly runtime, or to call R through a different bridge such as a bespoke service that wraps the R process itself. The difference in approach is that OpenCPU is a system, not a bridge. It ships the R package, the server stack, the example apps, the JavaScript client and the documentation as one thing, so a team can adopt an end-to-end path rather than assembling the pieces.

The cost of that choice is the R runtime. Every OpenCPU deployment carries an R installation, an Apache2 stack and the memory behaviour of R, and the multi-user case is a stack rather than a single binary. An organisation that already standardises on R for its statistics gets a much smaller marginal cost; one that does not is taking on a runtime in order to publish functions it could publish in a lighter language.

The second alternative is doing nothing and sharing results as files. For a workflow where the analysis is run once and the output is consumed by a colleague, a script and a result file are simpler than a service. OpenCPU earns its complexity when the computation has to be re-run on demand by a running application, which is what embedded scientific computing means in this context.

The licensing wording and the reproducible research claim

The readme states that the entire system is fully open source and permissively licensed. The repository's licence field is recorded as a custom licence that GitHub cannot classify, and the pointer is the LICENSE file in the repository, so the operative text is there rather than in the readme.

That combination is common and worth a minute of reading. Permissive language in a readme is a summary; the LICENSE file is the contract, and this is a question for a lawyer rather than for this page. What can be said without interpreting terms is that the project makes no claim to a standard OSI identifier for its licence, so a tool that only accepts recognised SPDX identifiers will need a manual check.

The other theme in the readme heading is producing and reproducing results, and the arXiv paper frames the whole design around a universal interface for scientific computing through separation of concerns. The link to a server manual in PDF form alongside a hosted documentation site and a collection of example apps suggests a project that has been running long enough to have accumulated reference documentation, which is a good sign for the install path and a hint that the API conventions are stable.

The repository itself is a standard R package layout: DESCRIPTION, NAMESPACE, R/, man/, data/, inst/, examples/, a NEWS file, an Rbuildignore and a teststuff directory.

Editorial conclusion

OpenCPU fits a team that already works in R and needs to publish statistical routines to other applications, whether through a browser app, a JavaScript client or a service, and it does not fit a team that wants a language-agnostic scientific API without an R runtime behind it. Before deploying, install the cloud server on Ubuntu 22.04 or 20.04 as the documentation specifies, confirm the Apache2 stack handles the multi-user case you need, and read the LICENSE file in the repository rather than assuming the permissive wording in the readme covers every use.

Frequently asked questions

Official sources

1. Issues
2. opencpu/opencpu on GitHub
3. Project website
4. README
5. Releases