Skip to content

Publishing#

Note

You must configure your RStudio Connect account before attempting to publish with the RStudio IDE. See the Connecting section for information on configuring your Connect account. If you do not have at least the Publisher role within Connect, then you can request permission to publish your own content via the link under Info on the Content page.

Link to request Publisher permissions

General Publishing Instructions#

RStudio Connect accepts publishing Shiny applications, R Markdown documents, plots, graphs, websites, TensorFlow models, Jupyter Notebooks, and APIs. The blue publishing icon in the RStudio IDE indicates built-in support for publishing this piece of content.

The RStudio publishing icon

You can find the blue publishing icon at the following locations:

  • The upper right of the file editor
  • The document viewer when viewing a document
  • The embedded viewer when running a Shiny application
  • The plots pane

Note

The functionality to publish Jupyter Notebooks to RStudio Connect is provided by a notebook extension. See the publishing Jupyter Notebooks section for details.

Click on this icon to open a publishing dialog where you can name your content and select additional files to include in the deployment. By default, RStudio will try to infer the data files and scripts are used in your content. This window lets you refine those file selections.

RStudio publishing dialog

Most of the time, RStudio is able to determine automatically which files are needed to render your document on RStudio Connect. However, there are situations in which it will miss a file (for instance, if it isn't referenced directly in your document). The Add More... button lets you add files to the bundle that will be sent to RStudio Connect so that they will be available on the server when your document is rendered. You can also use the resource_files field in your document's YAML header to add additional files.

Deployed data files must be in the same directory as your Shiny application or R Markdown document. Files stored elsewhere on your computer (C:\Users\me\mydata.csv) will not be available on the remote server.

Click Publish after verifying your settings.

Your first deployment may take a few minutes, as RStudio Connect attempts to recreate the R library you use locally -- referenced packages are downloaded and installed. These packages are cached on the server; subsequent deployments will be faster.

Not all of your IDE environment can be replicated on the server. Different operating systems or versions of R can occasionally make content behave differently. Package installation failures may require the installation of additional system libraries on RStudio Connect.

When the deployment completes, the RStudio Connect Settings page for your content is displayed. You should see your deployed content alongside its settings -- a rendered version of the document or a live instance of your Shiny application, for example.

Example of a running application

This page allows you to verify the sharing and visibility of your deployed content. See the Content Settings Panel section for additional information.

Collaboration#

Some data products will have multiple authors and collaborators who are responsible for managing the content deployed to RStudio Connect. The first step to collaboration is sharing and working together on code. We recommend using a version control tool like Git to coordinate collaboration across many users. General information about getting started with git is available elsewhere.

The second step is collaborating on the published data product. To enable multiple users to maintain and update a single piece of content on RStudio Connect, all users should be listed as collaborators on the content.

Content showing multiple
collaborators

When content is published to RStudio Connect for the first time, an rsconnect folder is created in the directory where your content was published from.

Note

This rsconnect folder should be added and committed into version control. It does not contain any private or secure information. However, it does contain the URL for the RStudio Connect server and the content URL. This information allows future publications to easily target the same endpoint.

A collaborator, then, would clone or check out the code to their development system and make whatever changes or improvements are necessary. When finished, they will click the Publish button in the RStudio IDE, which will use the rsconnect folder to determine where the content should be published. During the publishing process, RStudio Connect checks that the authenticated user has collaborator access for this piece of content.

RStudio IDE showing collaborative publishing

If the publisher wants to publish to a new location, this option is surfaced in the RStudio IDE as well. This will create a second deployment location on RStudio Connect and will leave the original content deployment unmodified. If you want to surface a single URL for your users despite publishing to a new location, keep in mind that you can assign a custom content URL to the original deployment location, then later assign it to a different piece of content on the server.

RStudio IDE option to create a new endpoint

Keep in mind that package environments may be different on each developer's computer. The original author and a collaborator may be using different computers, operating systems, or R versions with different package versions installed. RStudio Connect will attempt to reproduce the environment of whoever is publishing the content. Keeping developer environments in sync is not a problem solved by RStudio Connect. Rather, the renv package and RStudio Workbench address this problem more directly.

Info

Watch a video demonstration of basic push-button publishing with collaboration here.

Publishing Plumber APIs#

Plumber APIs have the following known restrictions:

  • Push-button publishing is available only with RStudio IDE version 1.2 and greater
  • Server-side latency is not tracked

To get started with publishing Plumber API endpoints, create a directory with a plumber.R file defining your endpoints. From the R console, execute the following, replacing <project-dir> with your project's directory:

rsconnect::deployAPI(api = '<project-dir>')

Once live, the results of your @get / endpoint are displayed. If @get / is not defined, you will see a "Swagger UI" presentation of your API. Swagger is an API documentation format; Plumber can automatically generate a swagger.json definition for your API by inspecting your endpoints. The "Swagger UI" page offers an interactive portal into your API that allows you to test your endpoints directly from the browser.

To make a call to your new API yourself, you're going to need the target URL. You can find it by looking at the bottom of the Access tab in your API's settings, or by clicking the "Open Solo" button in the upper-right of the content view. (Note: on narrow screens, the "Open Solo" button might be located in the ... menu in the upper-right of the content view.)

"Open Solo" button.

The URL opened by your browser should look like the following: https://rsc.company.com/content/42/.

All calls can be made relative to this path. For example, if you want to make a request to /volcano, the location in the above example would be https://rsc.company.com/content/42/volcano, like so:

curl -XPOST --data-binary '{ "line_plot": true }' \
    https://rsc.company.com/content/42/volcano

If your API restricts access to a particular set of users, then RStudio Connect requires that incoming requests authenticate the user making the request. The best approach for authenticating a request targeting an API is to use API Keys.

Alternatively, if your server is configured to use proxied authentication, you should ask your IT Administrator about ways to make API calls through that proxy.

If you want to perform access control in your Plumber API itself, or if you want to allow anyone to access your API, open the application settings, then the "Access" tab, and set "Sharing settings" to "Anyone".

Note

Some configurations may prohibit the "Anyone" access type.

Here is an example showing a simple way to restrict access:

#* @filter shared-secret-auth
keyAuth <- function(res, secret = NULL) {
    if(is.null(secret) || secret != 'mySecret') {
        res$status <- 401 # 401 UNAUTHORIZED
        list(error = "Authentication Failed")
    } else {
        plumber::forward()
    }
}

See the Plumber documentation for more information on @filter methods, and how they can be skipped in your route with @preempt.

Security is hard. The example above might be good enough for some purposes, but is unsuitable in cases where you need multiple keys you can invalidate arbitrarily. In those cases, API Keys would be preferable. Ask your IT Administrator for guidance if you need help choosing a suitable authentication scheme.

Publishing TensorFlow Model APIs#

Note

TensorFlow Saved Models up to TensorFlow version 1.13.1 are supported. To find out what version of TensorFlow is installed, you can run the following in the R console: tensorflow::tf_version().

If your installed TensorFlow version is greater than 1.13.1, you can install TensorFlow 1.13.1 by running the following in the R console: tensorflow::install_tensorflow(version = "1.13.1")".

TensorFlow Model APIs are easy to deploy to RStudio Connect. Export your model:

# `library(tensorflow)` version
export_savedmodel(session, "mysavedmodel")

# `library(keras)` version
export_savedmodel(model, "mysavedmodel")

Then deploy it to RStudio Connect using the rsconnect package:

rsconnect::deployTFModel("mysavedmodel", account = "myaccount", server = "myserver")

The home page on your new TensorFlow Model API will explain how it can be used. Much like Plumber, you can use RStudio Connect access controls and RStudio Connect API Keys to secure your Model API, or to allow everyone to use it.

All TensorFlow Model API requests are mostly the same. For the following examples, assume that your TensorFlow Model API is running open to the public at: https://localhost:3939/content/12. Assume also that your TensorFlow model accepts as input a 2-tensor (matrix) of floating point values with dimensions Infinity by 2.

You could call your TensorFlow Model API like so:

curl https://localhost:3939/content/12/serving_default/predict -XPOST --data-binary='\
{ \
"instances": [\
    [[5.4, 3.2]]\
]\
}'

Note that the TensorFlow Model API is strict about the number of dimensions passed in instances. The instances array does not count towards tensor dimensions:

  • "instances": [[[2.4]]] is one instance of a 2-tensor (matrix) with dimensions 1x1
  • "instances": [[[[2.3, 4.5],[5.6, 7.8]]]] is one instance of a 3-tensor with dimensions 1x2x2

Your TensorFlow Model API will return the predicted values as you configured it. For example, if your model was configured to respond with a 0-tensor (scalar) of floats, you might get the following:

{
    "predictions": [1.2]
}

The rstudio/tfdeploy repository contains some example scripts for building and exporting simple models, so you can try them before you upload some of your own. For example:

account <- "replace me with your username"
server <- "replace me with your server host"
# the `keras` package must be installed for models/keras-mnist.R
install.packages("keras")
devtools::install_github("rstudio/tfdeploy")
source(system.file("models","keras-mnist.R", package="tfdeploy"))
rsconnect::deployTFModel("keras-mnist", account = account, server = server)

Publishing with rsconnect-python#

rsconnect-python is a CLI deployment tool written in Python which can be used directly to deploy Jupyter notebooks, Python APIs (Flask, Bottle, FastAPI, etc), and interactive applications (Dash, Bokeh, and Streamlit).

Installing#

Installing the rsconnect-python command line interface is easy using pip:

pip install rsconnect-python

Once rsconnect-python is installed, the rsconnect command line utility will be available in your python binaries directory. In many cases, it will be on your PATH and accessible by executing rsconnect on the command line.

Adding a Server#

To add a server for deployment, you will need:

  1. Your server URL (--server/-s)
  2. Your API key (--api-key/-k)
  3. A nickname for the server that you provide (--name/-n)
rsconnect add --server https://my.connect.server/ --name myServer --api-key $CONNECT_API_KEY

Once the server is added, rsconnect deploy commands can reference that server by using the -n or --name flag, followed by the nickname.

Understanding entrypoints#

APIs and Dash Apps#

When deploying a FastAPI or Flask API, or a Dash app, RStudio Connect needs to locate the application object. The location of the application object is called the entrypoint and is specified in two parts, separated by a colon: the module name and the object name (optional). For example, app:app if both are specified; or simply app if only the module name is specified.

The module name is the name of a Python module that contains the application. For example, if your application code is in a file named example.py in the application directory, then the module name would be example.

The object name is the name of the application object in your Python code. In a Flask API, for example, the application is typically created by a line of code that looks like:

# example.py
# ...
app = Flask(__name__)

In this case, the application object is named app, and the entrypoint would be example:app.

If the object_name is omitted, Connect will attempt to find a default application in the following order:

  • app
  • application
  • create_app
  • make_app

    create_app and make_app are expected to be factory functions, which should take no arguments and should return a valid application object.

If you are using rsconnect-python, the default entrypoint is app. If you put your code in app.py and your application object is one of the defaults listed above, the default entrypoint will work.

Otherwise, specify the entrypoint on the command line using the --entrypoint option. For example, if your code is in the file example.py and your application object is named myapp, use:

For Flask:

rsconnect deploy api -n <saved server name> --entrypoint example:myapp ...

For FastAPI:

rsconnect deploy fastapi -n <saved server name> --entrypoint example:myapp ...

If you are creating a manifest.json file for later deployment, you can use:

rsconnect write-manifest api --entrypoint example:myapp ...

or

rsconnect write-manifest fastapi --entrypoint example:myapp ...

Streamlit and Bokeh Apps#

For Streamlit and Bokeh apps, the entrypoint is the name of the Python file containing your app. For example, if your streamlit app's source file is named main.py, use:

rsconnect deploy streamlit -n <saved server name> --entrypoint main.py ...

Python APIs#

  • If you have not already, install rsconnect-python using the instructions here.

  • Verify that you have activated the virtualenv environment that you wish to reproduce on the RStudio Connect server. rsconnect-python will freeze your current python environment unless it finds a requirements.txt file in the same directory.

  • Ensure that you have added the target server to the rsconnect-python command line interface. Your target server should be in the list when you execute:

    rsconnect list
    
  • Once your server is added, you can deploy your Flask API using the following command:

    rsconnect deploy api -n myServer MyApiPath/
    

    or deploy a FastAPI-based API with:

    rsconnect deploy fastapi -n myServer MyApiPath/
    

    The command line interface will attempt to infer your entry point, but if you would like to specify one, use the --entrypoint command line flag. Learn more about Python APIs and entrypoints here.

  • Once complete, the command line interface will return a link to your content.

Dash#

  • If you have not already, install rsconnect-python using the instructions here.

  • Verify that you have activated the virtualenv or conda environment that you wish to reproduce on the RStudio Connect server. rsconnect-python will freeze your current python environment unless it finds a requirements.txt or environment.yml file in the project directory.

  • Ensure that you have added the target server to the rsconnect-python command line interface. Your target server should be in the list when you execute:

    rsconnect list
    
  • Once your server is added, you can deploy your app using the following command:

    rsconnect deploy dash -n myServer MyApiPath/
    
  • Once complete, the command line interface will return a link to your deployed app.

Publishing Documents#

When publishing documents to RStudio Connect, you may encounter other deployment options depending on your content. These options are discussed below.

Publishing Destination#

Publish to RPubs or
Connect

RPubs is a service for easily sharing R Markdown documents. RPubs is not related to RStudio Connect, and you should always choose "RStudio Connect" if you wish to publish your content to RStudio Connect.

RPubs documents are (1) always public, (2) always self-contained, and (3) and cannot contain any Shiny content. You will see the choice to publish to RPubs if your document is self-contained and does not require Shiny. Some organizations want to prohibit publishing to RPubs to reduce the chance that sensitive data will be accidentally made public; publishing to RPubs (and shinyapps.io) can be disabled if desired using an RStudio Server or RStudio Workbench option.

Publish Source Code#

Dialog to publish source code

These options display when publishing from the document viewer.

Publishing the document with source code means that your R Markdown file (.Rmd) will be deployed to RStudio Connect. This file is rendered (usually to HTML) on the server.

Publishing only the finished document means that the HTML file you rendered locally is deployed to RStudio Connect.

We recommend publishing your documents with source code, as it allows you to re-render the document with RStudio Connect (on a weekly schedule, for example). If the document cannot be rendered by RStudio Connect because of files or data sources that are unavailable on the server, choose "Publish finished document only" so others can view your work.

Document Selection#

Dialog to publish one or all documents

When publishing an R Markdown document from a directory that contains more than one R Markdown document, these options display. It is possible to link together multiple R Markdown documents to make a multi-page document, so this is your chance to indicate that you've done this, and to publish all the documents at once. In most cases however you'll want to publish just the current document.

Publishing Jupyter Notebooks#

Publishing from the rsconnect-jupyter Notebook Extension#

The functionality to publish Jupyter Notebooks to RStudio Connect is provided by a notebook extension.

Follow the steps in the rsconnect-jupyter User Guide to install and configure Jupyter Notebook with the ability to publish to RStudio Connect:

  • Install the rsconnect-jupyter package
  • Enable the rsconnect-jupyter notebook extension
  • Generate an RStudio Connect API Key (instructions in the API Keys section)
  • Use push-button publishing to publish your Jupyter Notebooks to RStudio Connect

Publishing from the rsconnect-python Command Line Interface#

Installing the rsconnect-python command line interface is easy using pip:

pip install rsconnect-python

Once rsconnect-python is installed, the rsconnect command line utility will be available in your python binaries directory. In many cases, it will be on your PATH and accessible by executing rsconnect on the command line.

To publish a notebook using the command line interface:

  • Verify that you have activated the virtualenv or conda environment that you wish to reproduce on the RStudio Connect server. rsconnect-python will freeze your current python environment unless it finds a requirements.txt or environment.yml file in the same directory.

  • Ensure that you have added the target server to the rsconnect-python command line interface. Your target server should be in the list when you execute:

rsconnect list
  • If you have not set up the target server, you can create an entry using the following command:
rsconnect add --server https://my.connect.server/ --name myServer --api-key $RSTUDIO_CONNECT_API_KEY
  • When the server is added, you are ready to deploy your notebook:
rsconnect deploy notebook -n MyServer MyNotebook.ipynb
  • Once complete, the command line interface will return a link to your content.

Publishing Pins#

The pins R package can be used to share data resources on RStudio Connect. Use the board_register_rsconnect function to identify your RStudio Connect server and the pin function to publish resources:

board_register_rsconnect(server = "https://connect.example.com")
iris %>%
  filter(Species == "Setosa") %>%
  pin("s_iris", board = "rsconnect")

The pins package documentation has additional details about publishing and consuming pinned resources hosted by RStudio Connect.

Publishing Content that uses Python and R#

The reticulate package allows users to create projects that contain R and Python code. Reticulate can be used across content types including Shiny applications, R Markdown documents, and plumber APIs.

RStudio Connect can deploy and host this content, and will automatically restore both the R and Python environments. To deploy:

  1. Ensure your server administrator has enabled Python in the RStudio Connect configuration, and double check that your project uses a version of Python available on RStudio Connect.

  2. Projects deployed to RStudio Connect should use the RETICULATE_PYTHON environment variable and should not include any references to reticulate::use_python, reticulate::use_virtualenv, or reticulate::use_conda. See an example of switching to RETICULATE_PYTHON.

  3. Check to be sure you are using rsconnect version 0.8.13 or above: packageVersion('rsconnect')

  4. Follow the publishing instructions that are specific to the type of content you are deploying. During deployment, the list of necessary Python packages are sent to Connect. Connect installs these packages into an isolated virtual environment, similar to the approach used for R packages.

Deployment Logs for Content with R and Python Dependencies#

When you deploy this type of content, you will see additional logs in both the RStudio Deploy pane and the RStudio Connect logs pane.

In RStudio, you will see something like the following in the Deploy pane, typically after a series of log lines detailing the R environment restore:

Completed packrat build against R version: '3.4.4' Bundle requested Python
version 3.6.7; using /opt/Python/3.6.7/bin/python3.6 which has version 3.6.7
2019/03/05 22:31:15.585067606 Running with python "3.6.7 (default, Dec 11 2018,
22:03:50)  [GCC 4.8.4]" at /opt/Python/3.6.7/bin/python3.6

The first line signals that RStudio Connect has completed restoring the R environment. The second line indicates the version of Python discovered in RStudio as well as the matched version available on RStudio Connect. These lines will be followed by logging that indicates RStudio Connect's progress in re-creating the Python environment. In some cases, these environments may be cached. For example:

2019/03/05 22:31:15.586051939 Using cached environment: eTZbLgG9EAv8_Nfcrq7LYw
2019/03/05 22:31:16.025098703 Packages in the environment: numpy==1.16.2,
pandas==0.24.1, python-dateutil==2.8.0, pytz==2018.9, six==1.12.0, Completed
python build against Python version: '3.6.7'

In RStudio Connect, you will see two log entries each with a unique Job ID, one entry will be titled "R snapshot restore" and the second will be titled "Python environment restore".

Switching to RETICULATE_PYTHON#

If your reticulate code currently uses use_conda, use_virtualenv, or use_python, you'll need to switch to using the RETICULATE_PYTHON environment variable in order for push-button publishing to work. Any of the reticulate::use functions can be replaced using the environment variable. For example, if you are using a virtual environment located in the project subfolder ./env:

  1. Remove the code reticulate::use_virtualenv("./env")
  2. Create a .Renviron file in your project containing the line: RETICULATE_PYTHON=./env/bin/python
  3. Restart your R session
  4. You can use reticulate::py_config() to confirm the correct environment is in use

After following these steps you will be able to push-button publish the content to RStudio Connect. You can continue project development using the environment variable, you do not need to undo the change to continue working on your code.

During push-button publishing, do NOT include the .Renviron file.

Publishing from Git#

Any of the content types that are described above may be deployed directly from a Git repository. See the Git-Backed Publishing section for details.

Troubleshooting Publishing Issues#

RStudio Connect includes extra information in the packrat restore, content build, and content execution logs that may help diagnose common problems with publishing content. For example:

  • RStudio Connect will log the distribution of Linux used by the server. If there are issues related to shared object files used by R, this may help to diagnose them.

  • RStudio Connect will log any overrides to the repos option set by your server administrator. This may occur when your organization has a security policy that permits you to use a particular public repository on your workstation but requires a secure private repository on the RStudio Connect server. If there are issues related to packages not being present in repositories, this may help to diagnose them.

  • RStudio Connect will log the URL of all requests made to fetch packages. If you have multiple repos set in options(repos), Packrat's behavior on restore may be difficult to visualize. If there are issues related to this behavior, this information may help diagnose them.

  • If no version of R on the RStudio Connect server matches the version of R that you used to deploy your content, RStudio Connect will find the closest available R version and log that you requested a specific R version but that it is using some other specific R version because the requested one is not available.

  • RStudio Connect will scan your logs for common errors and suggest troubleshooting steps if an error is found. If you have encountered an error that RStudio Connect is not detecting or for which RStudio Connect is not providing adequate troubleshooting steps, you may wish to contact your administrator or your RStudio Support representative.

Error Codes#

RStudio Connect analyzes the log output and recognizes a set of common errors. These are assigned error codes, which are listed below along with possible causes and solutions.

r-cannot-access-repo#

RStudio Connect cannot download a package because the R package repository (for example, CRAN or RStudio Package Manager) cannot be accessed.

Possible causes

  • There is a network problem preventing the Connect server from connecting to the package repository.
  • The package repository may be down.
  • The package repository must be accessed through a proxy server, but no proxy server is configured in the Connect configuration file.
  • The client computer that published the content is using a different package repository from the Connect server, and that package repository is not accessible from the Connect server.
  • The package repository has moved to a different URL since the content was published.

Possible solutions

  • Verify that the package repository is reachable from the RStudio Connect server.
  • If necessary, change the Packages.HTTPProxy and Packages.HTTPSProxy configuration settings to point to your outbound proxy server.
  • Configure the client with a package repository that is accessible via http(s) from the Connect server, such as CRAN or RStudio Package Manager. Reinstall the affected packages from the new repository and publish the content again.

References

r-proxy-unreachable#

The proxy server specified in Packages.HTTPProxy or Packages.HTTPSProxy could not be reached.

Possible causes

  • The proxy server configuration in Connect is incorrect.
  • The proxy server is not working or cannot be reached on the network.

Possible solutions

  • Verify that the proxy server is working and is reachable from the RStudio Connect server.
  • If necessary, change the Packages.HTTPProxy and Packages.HTTPSProxy configuration settings to point to the correct proxy server.

References

r-package-not-available#

An R package required by the content cannot be found in the package repository.

Possible causes

  • The R package being installed is not available for the version of R configured at Connect.
  • The R package being installed is not available for linux.
  • The client computer that published the content is using a different package repository from the Connect server, and the R package being installed is not available in the repository configured at the Connect server.
  • The package repository moved to a new URL after the content was published, and Connect is now attempting to rebuild the environment using the old package repository URL.

Possible solutions

  • Install a version of R on the Connect server that matches the one being used by the client computer. You can identify the required R version from the deployment logs, which will contain an entry similar to this:

    Bundle requested R version 3.5.0; using /usr/lib/R/bin/R which has version 3.4.4

    In this example, the client computer has R 3.5.0 and the Connect server has R version 3.4.4. The recommended solution would be to install R version 3.5.0 on the Connect server alongside the existing 3.4.4 installation.

  • Replace usage of Windows-specific R packages with ones available for linux.

  • Configure the client with a package repository that is accessible via http(s) from the Connect server, such as CRAN or RStudio Package Manager. Reinstall the affected packages from the new repository and publish the content again.

References

r-package-installed-directly#

A package was installed improperly on the client computer.

Possible causes

  • On the client computer publishing the content, the R package was installed directly from a download URL. For example, using install.packages("https://.../packagename.tar.gz").

Possible solutions

  • Reinstall the affected package on the client computer from a configured repository such as CRAN or an instance of RStudio Package Manager. For example, install.packages("packagename"). Then publish the content again.

References

r-gcc-too-old#

An R package must be compiled using a newer version of GCC.

Possible causes

  • The R package being installed is a compiled C++ package which requires support for a specific language standard such as C++14, and the installed version of gcc does not support that language standard.

Possible solutions

References

r-build-need-cxx-defined#

The R package being installed is a compiled C++ package which requires support for a specific language standard such as C++14, and that support is not properly configured in the toolchain.

Possible causes

  • A previous update to your R installation did not update the Makeconf file. This can happen if the file has been modified and you updated R using a package manager such as yum.

Possible solutions

  • Install R from precompiled binaries as recommended in the RStudio Connect Admin Guide. Installing from these binaries allows you to easily make multiple versions of R available as your users upgrade or install R on their computers.
  • Install a version of GCC which supports the required language features, as described at https://gcc.gnu.org/projects/cxx-status.html.
  • The CXX11 or CXX14-related variables must be defined in the Makeconf file located at $(R RHOME)/etc/Makeconf for all installed versions of R. If a Makeconf.rpmnew file exists in this location, copy the values from there to Makeconf. Otherwise, edit the file to ensure that the required variables are defined.

References

r-cannot-access-local-repo#

A local package repository could not be accessed.

Possible causes

  • A local package repository was in use on the client which published the content, and the path to that package repository is not valid on the server.

Possible solutions

  • Configure the client with a package repository that is accessible via http(s) from the Connect server, such as CRAN or RStudio Package Manager. Reinstall the affected packages from the new repository and publish the content again.

References

r-invalid-package-repository-certificate#

There is a problem with the TLS certificate for the package repository (e.g. CRAN or RStudio Package Manager) or outbound proxy server.

Possible causes

  • The server uses a self-signed certificate, and your RStudio Connect server is not configured to trust the certificate.
  • The server certificate is signed by a private certificate authority (CA), and your RStudio Connect server is not configured to trust the CA certificate.
  • The server certificate is expired.

Possible solutions

  • For self-signed or private-CA certificates, install a trusted certificate into the system trust store.

References

r-package-version-not-available#

A required R package was found in the package repository, but the specified version is not available.

Possible causes

  • The client computer that published the content is using a different package repository from the Connect server, and the package repository that Connect is using does not have the requested version of the package.
  • The Connect server is using a CRAN mirror that is out of date.
  • The package repository moved to a new URL after the content was published, and Connect is now attempting to rebuild the environment using the old package repository URL.

Possible solutions

  • Configure the client with a package repository that is accessible via http(s) from the Connect server, such as CRAN or RStudio Package Manager. Reinstall the affected packages from the new repository and publish the content again.

  • Update the packages on the CRAN mirror.

    • If this is a local instance of RStudio Package Manager, see the Package Manager documentation for instructions on how to update the mirrored packages.
    • If this is a public CRAN mirror, it may be experiencing technical problems. Choose a different CRAN mirror.

References

r-missing-system-library#

An R package cannot be installed because a required system-level dependency is missing.

Possible causes

  • An R package requires a system-level dependency, such as a library or executable, which is not installed on the Connect server.

Possible solutions

  • Install the required package using your system package manager (such as apt or yum).
  • Use your on-premise instance of RStudio Package Manager or the publicly provided instance and open the information page for the affected R package. Installation instructions for the package's system-level dependencies are included under the Install System Prerequisites heading.
  • Use the messages in the deployment log to identify which system package you need to install.

References

render-missing-r-package#

A package is missing from the R environment.

Possible causes

  • The package is referenced indirectly in the R code, without an explicit library() or require() call.

Possible solutions

  • Import required libraries directly. For example, using "library(tidyverse)".

References

render-r-code-error#

An error occurred while running R code.

Possible causes

  • There is a bug in the R code being deployed.
  • The R code depends on conditions that are not present in Connect.
  • The R code depends on a version of R that is not configured in Connect.

Possible solutions

  • Correct bugs in the R code, then deploy the corrected content.

    • The document rendering log in Connect contains details of the error.
    • Knitting the document in the RStudio IDE may also be helpful for debugging.
  • Install a version of R on the Connect server that matches the one being used by the client computer, then redeploy the content. You can identify the required R version from the log messages above, which will contain an entry similar to this:

    Note

    Bundle requested R version 3.5.0; using /usr/lib/R/bin/R which has version 3.4.4

    In this example, the client computer has R 3.5.0 and the Connect server has R version 3.4.4. The recommended solution would be to install R version 3.5.0 on the Connect server alongside the existing 3.4.4 installation.

  • If you have previously published this content, viewers will continue to see the last successful output until the error is resolved by republishing.

References

python-cannot-access-repo#

RStudio Connect cannot download a package because the Python package repository (for example, PyPI) cannot be accessed.

Possible causes

  • There is a network problem preventing the Connect server from connecting to the package repository.
  • The package repository may be down.
  • The package repository must be accessed through a proxy server, but no proxy server is configured in the Connect configuration file.
  • You have a private package repository or PyPI mirror, but RStudio Connect is not configured to use it.

Possible solutions

  • Verify that the package repository is reachable from the Connect server.
  • If necessary, change the Packages.HTTPProxy and Packages.HTTPSProxy configuration settings to point to your outbound proxy server.
  • If necessary, configure /etc/pip.conf on the Connect server to provide access to your package repository.

References

python-proxy-unreachable#

The proxy server specified in Packages.HTTPProxy or Packages.HTTPSProxy could not be reached.

Possible causes

  • The proxy server configuration in Connect is incorrect.
  • The proxy server is not working or cannot be reached on the network.

Possible solutions

  • Verify that the proxy server is working and is reachable from the RStudio Connect server.
  • If necessary, change the Packages.HTTPProxy and Packages.HTTPSProxy configuration settings to point to the correct proxy server.

References

python-invalid-package-repository-certificate#

There is a problem with the TLS certificate for the Python package repository (e.g. PyPI) or outbound proxy server.

Possible causes

  • The server uses a self-signed certificate, and your RStudio Connect server is not configured to trust the certificate.
  • The server certificate is signed by a private certificate authority (CA), and your RStudio Connect server is not configured to trust the CA certificate.
  • The server certificate is expired.

Possible solutions

  • For self-signed or private-CA certificates, install a trusted certificate into the system trust store.

References

python-package-not-available#

A Python package required by the content cannot be found in the package repository.

Possible causes

  • The Python package being installed is not available for the version of Python configured at Connect.
  • The Python package being installed is not available for linux.
  • The client computer that published the content is using a different package repository from the Connect server, and the Python package being installed is not available in the repository configured at the Connect server.
  • The package repository moved to a new URL after the content was published, and Connect is now attempting to rebuild the environment using the old package repository URL.

Possible solutions

  • Install a version of Python on the Connect server that matches the one being used by the client computer. You can identify the required Python version from the deployment logs, which will contain an entry similar to this:

    Bundle requested Python version 3.7.0; using /opt/python/3.5.7/bin/python which has version 3.5.7

    In this example, the client computer has Python 3.7.0 and the Connect server has Python version 3.5.7. The recommended solution would be to install Python version 3.7.0 on the Connect server alongside the existing 3.5.7 installation.

  • Replace usage of Windows-specific Python packages with ones available for linux.

  • Configure the client with a package repository that is also configured at the Connect server, such as PyPI. Reinstall the affected packages from the new repository and publish the content again.
  • Configure the RStudio Connect server's /etc/pip.conf to use a package repository that is accessible via http(s) from the Connect server, such as PyPI. Reinstall the affected packages from the new repository and publish the content again.

References

python-package-version-not-available#

A required Python package was found in the package repository, but the specified version is not available.

Possible causes

  • The client computer that published the content is using a different package repository from the Connect server, and the package repository that Connect is using does not have the requested version of the package.
  • The Connect server is using a PyPI mirror that is out of date.
  • The package repository moved to a new URL after the content was published, and Connect is now attempting to rebuild the environment using the old package repository URL.

Possible solutions

  • Configure the client with a package repository that is also configured at the Connect server, such as PyPI. Reinstall the affected packages from the new repository and publish the content again.
  • Configure the RStudio Connect server's /etc/pip.conf to use a package repository that is accessible via http(s) from the Connect server, such as PyPI. Reinstall the affected packages from the new repository and publish the content again.
  • Update the packages on the PyPI mirror.

    • If this is a local package repository, see its documentation for instructions on how to update the mirrored packages.
    • If this is a public PyPI mirror, it may be experiencing technical problems. Choose a different PyPI mirror.

References

python-missing-system-library#

A Python package cannot be installed because a required system-level dependency is missing.

Possible causes

  • A Python package requires a system-level dependency, such as a library or executable, which is not installed on the Connect server.

Possible solutions

  • Install the required package using your system package manager (such as apt or yum).
  • Use the messages in the deployment log to identify which system package you need to install.

render-python-code-error#

An error occurred while running Python code.

Possible causes

  • There is a bug in the Python code being deployed.
  • The Python code depends on conditions that are not present in Connect.
  • The Python code depends on a version of Python that is not configured in Connect.

Possible solutions

  • Correct bugs in the Python code, then deploy the corrected content.

    • The document rendering log in Connect contains details of the error.
    • For content published from the RStudio IDE, knitting the document in the IDE may also be helpful for debugging.
    • For content published from Jupyter, running the notebook locally may help to isolate the problem.
  • Install a version of Python on the Connect server that matches the one being used by the client computer, then redeploy the content. You can identify the required Python version from the log messages above, which will contain an entry similar to this:

    Bundle requested Python version 3.7.0; using /opt/python/3.5.7/bin/python which has version 3.5.7

    In this example, the client computer has Python 3.7.0 and the Connect server has Python version 3.5.7. The recommended solution would be to install Python version 3.7.0 on the Connect server alongside the existing 3.5.7 installation.

  • If you have previously published this content, viewers will continue to see the last successful output until the error is resolved by republishing.

References