15 Content Management

RStudio Connect provides flexibility over how uploaded content is configured and shared.

15.1 Sharing Settings

Each deployment in RStudio Connect can have specific access controls which specify which users are allowed to view and/or edit that content.

15.1.1 Collaborators

The list of collaborators enumerates the users allowed to edit and help manage the settings for a given deployment. The content owner is always included as a collaborator. Collaborators must be either “publisher” or “administrator” accounts.

15.1.2 Viewers

A viewer is able to view content. Any type of account can be made a viewer for a given piece of content. Choose from the following options.

Anyone - no login required

Any visitor to RStudio Connect will be able to view this content. This includes anonymous users who are not authenticated with the system.

All users - login required

All RStudio Connect accounts are permitted to view this content.

Specific users or groups

Specific users (or groups of users) are allowed to view this content. Other users will not have access.


Only the owner of this content is able to view this content. Limiting allowed viewership

Some organizations want to restrict the types of access that publishers and administrators can assign to content.

The settings Applications.MostPermissiveAccessType and Applications.AdminMostPermissiveAccessType limit the viewership options allowed to publishers and administrators, respectively.

These settings take the following values:


The most permissive access type. Allows all viewership permissions.


Permits only logged-in viewership options. This includes allowing the content owner and specific users and groups.


Content must explicitly enumerate specific users and groups.

There is not an access type that only allows the owner to view the content. Owner-only access is implemented as an empty access control list (ACL).

The following example requires publishers to constrain viewership by enumerating specific users and groups in access control lists. Publishers cannot grant access to all logged-in users or to anonymous, unauthenticated users. Administrators are allowed to configure any access type.

These values can be helpful to avoid accidentally exposing content too widely, while still allowing select individuals to publicize approved content.

; /etc/rstudio-connect/rstudio-connect.gcfg
MostPermissiveAccessType = acl
AdminMostPermissiveAccessType = all

This next example prohibits content from being given unconstrained viewership. Content cannot be configured to allow anonymous, unauthenticated access. The restriction applies to both publishers and administrators.

Use this configuration when you want to require user login before accessing any content on RStudio Connect.

; /etc/rstudio-connect/rstudio-connect.gcfg
MostPermissiveAccessType = logged_in

The access type of existing content is not automatically altered. The two access type settings limit which permissions may be given to content. This restriction is only enforced when content is created or modified.

15.2 Vanity Paths

All content receives a URL that includes its numerical ID at at the time of deployment – something like https://rsc.company.org/connect/#/apps/982. Connect administrative users can create “vanity paths” for content which make the content available at an additional, customized URL.

This setting can be found at the bottom of the “Access” tab when editing a piece of content. There you can enter the path at which you want this content to be available and preview the complete URL. Once you “Save” your content, you’ll be able to access your content at the new vanity URL.

Vanity URLs can not be nested inside of one another. So if a vanity URL /finance/ already exists, you would not be able to create a new vanity URL at /finance/budget/. You may create sibling paths: /finance/budget/ and /finance/quarterly/ may both exist concurrently.

15.3 Tags

You can use tags to organize content and make it easy for users to find content that they’re interested in. To begin, create a tag schema in the “Tags” section of the Connect dashboard by creating one or more tag categories. Define some tags, which can be nested any number of levels deep.

For example, if your data scientists are creating reports covering different geographical areas, you could create a category called “Geographical Area”. Then, you could create tags such as “Americas” or “Asia” and nest the tags “North America” and “South America” under “Americas”.

Only administrators can create and edit the tag schema. Categories and tags can be added, deleted, and renamed. Once a tag or category is deleted, all tags nested under it are also deleted.

Collaborators can associate content with one or more tags in the “Tags” tab of the content settings sidebar. Users can filter by tags to discover content, as long as they have permission to view that content.

For example, if multiple reports analyze the same set of data, those reports could be tagged with some identifier, such as “FY2016 Q3” for the third quarter of the 2016 fiscal year. A report that analyzes the third and fourth quarter could be tagged with “FY2016 Q3” and “FY2016 Q4”, and would appear when a user filters for either “FY2016 Q3” or “FY2016 Q4”.

15.4 Bundle Management

Content published to RStudio Connect is encapsulated in a “bundle” that contains the source code and data necessary to execute the content. An application or report is updated by uploading a new bundle. Old bundles are retained on disk until you reach the limit imposed by Applications.BundleRetentionLimit at which point older bundles will be deleted.

Users can manage their own bundles in the Connect dashboard by clicking the “Source Versions” button. Collaborators can delete, download, activate, and view activation logs for their applications’ bundles. Activating a different bundle is a way of “rolling back” or “rolling forward” to an older or newer version of your application, respectively.

Activating an alternative bundle for a Shiny application will cause new incoming users to be directed to the new version of the application but will not interrupt existing users of the application who are viewing the previously activated bundle. For reports, activating an alternate bundle will immediately render the newly activated bundle and promote it to be the authoritative version of that document. For parameterized reports, only the default variant will be rerendered; other instances of the report will not automatically be regenerated, but the next manual or scheduled update will be performed on the newly selected bundle.

When Activating an alternative bundle for a Plumber API, existing requests will be serviced by processes already launched running the old code. New requests will be serviced by new processes running the new code.

15.5 Content Images

Once content has been published to RStudio Connect, the publisher may enter the “info” tab in the application settings pane and upload an image to be associated with the content.

  • Application images are stored in the server’s data directory.
  • Application images can be viewed by anyone with permission to view the associated content.
  • Administrators cannot view images associated with content that they do not have access to. However, all administrators may change the visibility mode, or add themselves to the viewer list, for any piece of content. This ensures that the Administrator’s act of giving themselves viewer privileges can be tracked in the server’s audit logs.
  • RStudio Connect will reject uploads of images larger than the Applications.MaxAppImageSize configuration setting value. By default, the server will tolerate images up to 10MB in size.
  • RStudio Connect does no post-processing; images will be sent back to the user exactly as they were uploaded, and the RStudio Connect dashboard will make its best effort to display them in a consistent manner.
  • The RStudio Connect dashboard will attempt to cache images in an efficient and consistent manner. Every time the image is displayed, the dashboard will check the server for a newer version of the image, and accept its cached version if a newer image does not exist.

15.6 Git Backed Content

RStudio Connect publishers can deploy content to Connect in a variety of ways. One mechanism is to create content on Connect directly from a Git repository. The user guide contains instructions on the steps taken by publishers.

Content deployed from a Git repository will be indicated both in the content listing with the text “from Git” and in the content’s Settings -> Info with a Git-specific section containing metadata about the source repository.

NOTE: A given source repository may be associated with any number of applications.

15.6.1 Requirements

NOTE: Git >=1.7.12 is required for Git backed content.

The version of Git installed in the same environment as RStudio Connect is detected at process startup time, and is subject to the PATH set in the process environment. Alternatively, the path to the git executable may be set directly via Git.Executable.

If the version of Git cannot be detected, or if the version is lower than the minimum required of 1.7.12, an error will be logged and startup will be aborted. See 15.6.4 for how to disable Git backed content support.

15.6.2 Publishing

Git backed content may be associated with either public or private Git repositories, and may use https:// (recommended) or http:// remotes.

The Applications.RunAs user will run all git commands necessary for retrieving repository data. Public repositories

Publicly-accessible source repositories may be configured by any user with a “publisher” role. Private repositories

Private source repositories may be accessed by setting GitCredential.Host, GitCredential.Username, and GitCredential.Password, which will work with any authentication based on HTTP basic auth, such as with GitHub personal access tokens.

; /etc/rstudio-connect/rstudio-connect.gcfg
Host = github.com
Username = accountName
Password = <encrypted-string>
Protocol = https

NOTE: The encrypted string value of GitCredential.Password should be generated via rscadmin. Automatic fetch & deploy

Git backed content differs from content that is directly published to RStudio Connect, as indirect user actions such as pushing a Git commit to the associated repository may result in a new deployment. The decision to trigger a new deployment is made after a periodic fetch of the source repository, and will only occur if the specified branch and path prefix have changed since the last fetched commit.

NOTE: Periodic Git fetches are automatically performed at ~15 minute intervals for each Git backed application. This interval duration may be modified via the Git.PollingFrequency setting.

NOTE: The same polling frequency interval and re-deployment logic are used for public and private repositories.

15.6.3 Operational considerations

Throughout the lifetime of managing Git backed content, various background processes may be spawned, and data written to file storage. As a result, the number and type of processes running on the system may vary independent of users interacting with RStudio Connect. The size and composition of file based storage may likewise independently change over time. Repository data

All Git repository clones and cached metadata will be stored relative to the Server.DataDir at {Server.DataDir}/git. Automatic cleanup

An automatic cleanup is triggered at startup time and periodically during runtime which is responsible for removing any Git repository data which is no longer in use. Such data includes Git repository clones which are not associated with content and temporary clones fetched prior to first deploy. Concurrency limits

The Git.Concurrency setting limits the number of concurrent parent processes which may be spawned for Git operations. The limit is imposed at the individual Connect process level, meaning that a clustered deployment will have a total concurrency that is a multiple of the cluster members.

15.6.4 Disabling

In the case that Git backed content is not desired, such as when the Git version requirement cannot be met, it may be disabled by setting Git.Enabled to false.

15.7 API Keys

RStudio Connect allows users to access hosted content outside the web browser by utilizing API Keys - e.g. via shell scripts. API Keys are enabled by default. To change this behavior please see Section 15.7.2.

15.7.1 How this Works

API Keys are associated with user accounts. They provide roughly the same level of access to RStudio Connect as a user logged in via the browser would have.

If a user has a compromised API Key, the Key should be deleted as soon as possible. The administrator may wish to lock the account if the user is having difficulty deleting the API Key.

To retrieve static content or to invoke Plumber endpoints via API Keys an HTTP request must be made to the target URL of the published content. The request must contain an HTTP header whose key is Authorization and value is set to Key API_KEY.

Authorization: Key ABCDEFGHIJKLMNO

Note: Use the information above to allow API Keys to pass through a Proxy.

API Keys have the same authorization access levels as the user that owns them. Someone who uses an API Key will be able to view all content that the owner of the API Key has access to. API Keys are shared secrets and as such they should be stored securely and only be given to trusted applications. It is advisable that content requests be made securely over HTTPS. If a user believes that an API Key has been compromised, they can revoke just that key by deleting it.

The API Keys chapter of the RStudio Connect User Guide explains how to create and use API Keys.

To learn how to configure RStudio Connect to listen for HTTPS requests please see Section A.6.

15.7.2 Configuring API Keys

To disallow API Keys, set Authentication.APIKeyAuth to false.

; /etc/rstudio-connect/rstudio-connect.gcfg
APIKeyAuth = false