15 Package Management

15.1 Package Installation

RStudio Connect installs the R package dependencies of Shiny applications, Plumber APIs, and R Markdown documents when that content is deployed. The RStudio IDE uses the rsconnect and packrat packages to bundle the relevant source code and document its dependencies. RStudio Connect then uses packrat to duplicate those package dependencies on the server.

Packrat attempts to re-use R packages whenever possible. The shiny package, for example, should be installed only when the first Shiny application is deployed. This installation of shiny is placed into the packrat package cache as well as associated with that Shiny application deployment. Subsequent Shiny applications can use that cached package installation and see faster deployments as a result. Packrat also allows multiple versions of a package to exist on a system. Two Shiny applications referencing different versions of shiny will reference the correct Shiny installation and these two packages will not conflict with each other.

Resolving which packages need installing and which are already available all happens when you deploy content to RStudio Connect.

15.1.1 Package compilation

Some packages contain C and C++ code components. That code needs to be compiled during package installation. The Server.CompilationConcurrency setting controls the number of concurrent compilation processes used by package installation.

The default value for the Server.CompilationConcurrency setting is derived from the number of available CPUs with the formula max(1, min(8, (cpus-1)/2)). This property controls the number of concurrent C/C++ compilations during R package installation. This value makes it less likely for package installs to encounter memory capacity issues on lightweight hosts while allowing more concurrency on high-capacity servers.

CPUs 1 2 4 6 8 16 24 32
CompilationConcurrency 1 1 1 2 3 7 8 8

You can customize Server.CompilationConcurrency to force a specific level of concurrency.

CompilationConcurrency = 1

15.1.2 External Package Installation

Warning: Adding external packages decreases the reproducibility and isolation of content on RStudio Connect, and should only be done as a last resort.

You can indicate that a system-wide installation of a package should be used instead of one fetched by packrat. To do this, set each system package name to the External option under the Packages heading.

For example, RJava or ROracle are large installations, potentially with odd dependencies, such as your choice of JDK and/or Oracle InstantClient. First, you would install these packages in every R installation that RStudio Connect will be using. Then, you would configure RStudio Connect with the following parameters:

External = ROracle
External = RJava

This is the same as settings the packrat option external.packages to c("ROracle", "RJava") using packrat::set_opts. The external.packages option instructs packrat::restore to load certain packages from the user library. See the packrat documentation for more information.

15.1.3 Proxy Configuration

If the http_proxy and/or https_proxy environment variables are provided to RStudio Connect when the server starts, those variables will be passed to all R processes run by RStudio Connect, including the package installation process.

Setting the Packages.HTTPProxy and Packages.HTTPSProxy configuration options under the Packages heading will provide their values as http_proxy and https_proxy only when packages are installed during deployment. This could be useful if you have a special proxy just for downloading package dependencies. You could regulate access to unapproved packages in non-CRAN repositories by rejecting certain URL patterns.

15.2 Private Repositories

Packrat records details about how a package was obtained in addition to information about its dependencies. Most public packages will come from a public CRAN mirror. Packrat lets RStudio Connect support alternate repositories in addition to CRAN.

Learn how to create your own custom repository; this directory can then be shared over HTTP or through a shared filesystem.

Here are some reasons why your organization might use an alternate/private repository.

  1. Internally developed packages are made available through a corporate repository. This is used in combination with a public CRAN mirror.

  2. All packages (private and public) are approved before use and must be obtained through the corporate repository. Public CRAN mirrors are not used.

  3. Direct access to a public CRAN mirror is not permitted. A corporate repository is used as a proxy and caches public packages to avoid external network access.

RStudio Connect supports private repositories in these situations given that the deploying instance of R is correctly configured. No adjustment to the RStudio Connect server is needed.

Repository information is configured using the repos R option. Your users will need to make sure their desktop R is configured to use your corporate repository.

RStudio IDE version 0.99.1285 or greater is needed when using repositories other than the public CRAN mirrors.

We recommend using an .Rprofile file to configure multiple repositories or non-public repositories.

The .Rprofile file should be created in a user’s home directory.

# A sample .Rprofile file with two different package repositories.
  r <- getOption("repos")
  r["CRAN"] <- "https://cran.rstudio.com/"
  r["mycompany"] <- "http://rpackages.mycompany.com/"
  options(repos = r)

This .Rprofile creates a custom repos option. It instructs R to attempt package installation first from "CRAN" and then from the "mycompany" repository. R installs a package from the first repository in "repos" containing that package.

With this custom repos option, you will be able to install packages from the mycompany repository. RStudio Connect will be able to install these packages as code is deployed.

For more information about the .Rprofile file, see help(Startup) in R. For details about package installation, see help(install.packages) and help(available.packages).

15.3 Private Packages

Packages available on CRAN, a private package repository, or a public GitHub repository are automatically downloaded and built when an application is deployed. RStudio Connect cannot automatically obtain packages from private GitHub repositories, but a workaround is available.

We recommend using a private repository to host internal packages when possible. See Section 15.2 for details.

The configuration option Server.SourcePackageDir can reference a directory containing additional packages that Connect would not otherwise be able to retrieve. This directory and its contents must be readable by the Applications.RunAs user. Connect will look in this directory for packages before attempting to obtain them from a remote location.

This feature has some limitations.

  • The package must be tracked in a git repository so that each distinct version has a unique commit hash associated with it.
  • The package must have been installed from the git repository using the devtools package so that the hash is contained in the DESCRIPTION file on the client machine.

If these conditions are met, you may place .tar.gz source packages into per-package subdirectories of SourcePackageDir. The proper layout of these files is <package-name>/<full-git-hash>.tar.gz.

For example, if Server.SourcePackageDir is defined as /opt/R-packages, source bundles for the MyPrivatePkg package are located at /opt/R-packages/MyPrivatePkg. A commit hash of 28547e90d17f44f3a2b0274a2aa1ca820fd35b80 needs its source bundle stored at the following path:


When private package source is arranged in this manner, users of RStudio Connect will be able to use those package versions in their deployed content.

Be aware that this mechanism is specific to the commit hash, so you will either need to make many git revisions of your package available in the SourcePackageDir directory hierarchy or standardize to a particular git commit of the package.