Chapter 3 Applications hosts each app on its own virtualized server, called an instance. Each instance runs an identical copy of the code, packages, and data that you deployed; collectively, this is called an image. The bundle size that can be uploaded is limited to 1 GB for the Free and Starter plans, and up to 5 GB for the Basic, Standard and Professional plans. For the latter plans, note that the rsconnect package has a default bundle size limit of 1 GB, independent of your plan limit. If you plan to deploy application bundles larger than 1 GB in size, you can override the rsconnect default by setting this option first: options(rsconnect.max.bundle.size=...) where the value is in bytes. Do not set the maximum size larger than the limit for your plan, or application deployments will fail.

When you deploy an app, creates a new image with the updated code and packages, and starts one or more instances with the new image. If the app was previously deployed, shuts down and destroys the old instances. This design comes with some important considerations:

  1. Data written by an application to the local filesystem of an instance will be lost when you re-deploy the application. Additionally, the distributed nature of the platform means that instances may be shut down and re-created at any time for maintenance, or to recover from server failures.

  2. It is possible to have more than one instance of an application. This means that multiple instances of an application do not share a local filesystem. A file written to one instance will not be available to any other instance. limits the availability of system resources that an instance can consume by its type. The table below outlines the various instance types and how much memory is allowed for each. By default, deploys all applications on ‘medium’ instances, which are allowed to use 512 MB of memory.

Instance Memory
small 256 MB
medium (default) 512 MB
large 1024 MB
xlarge 2048 MB
xxlarge 4096 MB
xxxlarge 8192 MB

Note: Instance types and limits may change in the future. does not make any guarantees regarding the number of CPU cores, or the speed of the CPUs that are allocated to the deployed applications. If your applications are particularly computationally intensive, please contact us at to determine whether Shiny Server or Shiny Server Pro installed on your own infrastructure would better suit your needs.

3.1 Configuring your application

There are two ways that you can configure your application settings. The easiest and most comprehensive is to log into the dashboard and select the application you wish to configure in the Application View. From there, click the Settings menu bar choice to access the various options for application configuration.

The second method uses the rsconnect::configureApp() call to modify a subset of settings. For example, this is how you can change the instance size used by an application:

rsconnect::configureApp("APPNAME", size="small")

3.1.1 Custom Domains

Applications deployed on are accessible by loading a URL of the form: https://<account-name><application-name>/. Organizations that would like to have greater control over the URLs that their applications are served on can subscribe to the Professional plan and host the application on domains that belong to them.

To enable this feature, which is only available with the Professional plan, you will need to follow these steps:

  • Decide on domain(s) or subdomain(s) that you would want to host your applications on. (Example: or
  • Ask your IT administrator to setup a CNAME from that domain/subdomain to your account domain. For example, if your account name is acme and your domain you would like to setup is, then you must create a CNAME from to Steps to accomplish this can vary depending on domain registrar or DNS provider, so we recommend that you consult your provider’s documentation for exact instructions on completing this step.
  • Once the domain record has been created, log into the dashboard and navigate to Account -> Domains. From here, you can add the domain or subdomain from above and then click Add Domain.
  • Now you are ready to add custom URLs to any of your existing applications. Within the dashboard, find your application in the Applications tab and click on the URLs menu bar choice. You will notice that there is already a single URL, which is the one that is created by default, and cannot be removed.
  • Click on Add URL. You can now select from the list of domains you have entered, and specify the path to the application. The URL field below will show you what the final URL would look like.

Note that a single application can be hosted on multiple domains and using different paths; all paths are case-sensitive. does not currently support secure URLs for custom domains. The URLs you define in the application settings are accessible only via the http protocol, not the https protocol.

3.1.2 Embedding applications

Every application you deploy will have a unique URL, served over a secure socket (SSL) connection and accessible from a web browser in the format:


You can embed your application within other pages by using an iframe. Here is an example of an iframe for a fictitious application. Note that you may want to size the frame differently based on your application’s display requirements.

<iframe id="example1" src="https://<accountname><applicationame>"
style="border: non; width: 100%; height: 500px"

Be aware that since a shiny application is always served over SSL, your application cannot load HTML UI elements that are served over plain http; this is a security feature of all browsers.

3.1.3 Application Instances

An application instance is a virtualized server that serves an application. To serve your application, will start at least one application instance. You can start or stop your instance by visiting the Application page within the dashboard.

With the Basic plan and above, you can tune your application to use multiple application instances, and control when additional instances are added to meet your performance requirements. We describe how to tune your application in the Application Performance Tuning section below.

The maximum number of instances you can add is governed by your subscription plan:

Plan Instances
Free 1
Starter 1
Basic 3
Standard 5
Professional 10

3.1.4 Workers

A worker is a special type of R process that an Application Instance runs to service requests to an application. Each Application Instance can run multiple workers, and each worker process is capable of servicing multiple end users, depending on the configuration and performance requirements of the application. If there are no processes available to handle a new request, the Application Instance will start a new worker process. With the Basic plan and above, you can configure how many workers you would like to use and when they should be added.

3.2 Application performance tuning

With the Basic plan and above, you can configure your application to fine-tune its performance. You can tune the number of workers that run in each Application Instance, the number of Application Instances that you wish to run, how many Instances should start by default, how long to wait before your applications are considered idle and can be shut down, and many other parameters.

To learn more about instances, workers, and other details of the architecture, please read Scaling and Performance Tuning.

3.3 Application life cycle

Applications start out in a running state when they are first deployed. An application will remain in that state as long as it is handling requests from end users. Once all end user sessions disconnect (or the connections time out), an application will be put to sleep. A sleeping application will return to a running state when it is requested again.

State Description
Sleeping Currently not receiving any traffic, but can be brought online to service new requests
Running Currently running with at least one instance
Archived Cannot run unless it is unarchived

3.3.1 Application restarts

You can force a restart of your application by clicking on the Restart button in the Application view. Restarting an application in this manner tells to force a redeployment of the application that was last uploaded to the service. This can be helpful in circumstances where you want to force a rebuild of the packages again.

Alternately, you can force this restart programmatically by making the following call:

rsconnect::deployApp(upload = FALSE)

3.3.2 Active hours

Active hours are defined as the number of hours that any Application Instance was up and able to serve your application. Application Instances will be put into a sleep state when they have been idle for the Instance Idle Timeout value (default is 15 minutes). Idle time counts toward your account’s active hours, but sleep time does not.

For example, an application that is accessed for 15 minutes by a single user, will use 30 minutes or 1/2 an active hour.

15 minutes of usage + 15 minutes for the idle timeout = 30 minutes

If the application was configured to use two application instances and is used by multiple users for the same 15 minutes, the active hours will be 60 minutes, or 1 active hour:

(15 minutes of usage x 2 Application instances) + (15 minute idle timeout x 2 Application Instances) = 30 + 30 = 60 minutes

3.4 Archiving your application

You can remove an app on from the web with the terminateApp() command. To use it, run:


Alternately, you can click on the Archive button in the Application view.

Archived applications will not be served on the web. If you restart the application, or redeploy it, it will be moved out of the Archived state and will be available. Note that if you are subscribed to the Free plan, you have a limit to the number of applications that can be active at once. Archiving unused applications will allow you to deploy new applications.

3.5 Downloading your application

Users typically save and back up their applications locally, often with a source control management system like GitHub.

Should you need a copy of the data or R code that was last deployed, you can download a zip file that contains the full bundle by clicking on the Download button next to the Bundle label on the Application View page in the dashboard.

3.6 Deleting your application

If you no longer want to have your application and data on, you can delete your application by clicking on the Delete button within the Application View. Please note that applications must be archived before they can be deleted.

Use this feature carefully, deletes are permanent and the files cannot be recovered.

3.7 Advanced Settings

If you are on the Basic plan or above, you have access to advanced settings that provide you with the tools to tune the performance of your applications. Please read the section on Application Performance Tuning before making changes to the default settings.

3.7.1 Worker Settings

Workers are R processes that are started with your application code loaded. Since R is single-threaded, you may want to control how many users can connect to a single R process, and when new Workers should be added and removed. Below is a list of the various settings available for more fine-grained control. All of these settings are available within the dashboard under your application’s Settings -> Advanced tab. Max Worker Processes

This setting controls the maximum number of Workers that can be started within each Application Instance. Additional Workers are added to an instance, up to this maximum, when the Worker Load Factor threshold is reached. For Free and Starter plans, the default and maximum number of worker processes are 1. For the other plans the default is 3 with a maximum of 10. Worker Load Factor

This setting is the threshold percentage after which a new connection will trigger the addition of a new Worker, until the Max Worker Processes limit is reached. Max Connections

This setting controls the maximum number of concurrent connections that can access a given Worker. If your application has long-running operations that could block other users, you may consider lowering this number to ensure that the performance of the application is reasonable for all users.

Note that once a Worker’s connection limit is reached, no additional connections can be added to that Worker until some of the other connections are closed. If you configure your Application Instance to have a single Worker, you would only be able to serve Max Connections worth of connections simultaneously. Connection Timeout

The Connection Timeout is the seconds of inactivity before a browser connection to a Worker process is considered to be idle, and is closed. The higher the timeout, the longer that an inactive connection from your end user’s browser will continue to be considered active. Read Timeout

The Read Timeout is the seconds of browser-to-Worker inactivity after which the connection is considered to be idle and is closed. Set this value to 0 for non-interactive applications, e.g. a dashboard. The difference between this setting and the Connection Timeout setting is that the Read Timeout setting allows you to extend the time before a connection is considered idle if the end user is not interacting with the application, but the server is sending data down to the client. One example of such an application is a dashboard that refreshes itself on a regular basis with little to no interaction from the end user. Startup Timeout

This setting is the number of seconds that an instance will wait for a Worker to start. Increase this number if you load a lot of data or have a longer application startup time. The maximum is 300 seconds. Idle Timeout

This setting is the number of seconds before an idle worker process with no connections is shut down. The value must be between 5 and 60 seconds.

3.7.2 Instance Settings Instance Load Factor

This setting is the threshold percentage after which a new connection will trigger the addition of an Application Instance, up to the Maximum Instance Limit. Accounts on the Free plan get only 1 Application Instance. Start Count

The Start Count is the number of instances to bring up when an application starts. Pick a higher number if you know that your application receives flash traffic.

3.7.3 Build Settings

All shiny applications use one or more R packages to get their work done. When an application is uploaded to, the service will compile and install the various packages that are needed. In order to improve the deploy-time performance, will keep a copy (cache) of the compiled packages so it can load them quickly if it has seen the combination of R package, R version, and other dependent packages before. Package Cache

The Package Cache setting allows you to enable/disable the use of package caching when your application is built. Caching allows for faster deploy times; disable this only if you suspect that the build is failing due to caching.

3.8 Debugging your application

Sometimes your applications do not run the way you expect them to on If your application works perfectly on your local machine but fails on, you can use the following techniques to understand and correct the issues you see.

3.8.1 Logging

The best tool at your disposal is the application log, which includes the messages that are logged when the shiny application is brought online. This log is comparable to the log created when you run the shiny application locally in your own R process.

You can see your logs in the dashboard under the Logs tab in the Application view. Alternatively, you can use the rsconnect::showLogs() function to show the log messages of a deployed application. This log will include both stdout (log lines producted via print or cat) and stderr (log lines produced by message, warning, or stop). You can even use the streaming=TRUE option to specify that you want to continuously monitor the file for changes; this will listen for log messages until you interrupt R (typically by pressing Escape). If you deployed your application using an older version of the rsconnect package, you will need to redeploy it (deployApp(upload=FALSE)) before you can use logging.

Typically, most errors end up falling into one of the following categories:

  • Using absolute file paths instead of relative paths. For example, the following two examples will fail:
    • Windows: read.csv("C:\myapplication\data\myfile.csv")
    • Linux or Mac: read.csv("~/myapplication/data/myfile.csv") Instead, your application should reference the data file by a path relative to the application, e.g., read.csv("data/myfile.csv"). See the section on Storage for more information.
  • Attempting to change the working directory. This is a corollary to the previous item. The working directory is the directory where your ui.R and server.R files reside. If you need to reach files in a subdirectory, you should use relative paths rather than changing the working directory. For example, the following two examples will fail:
    • Windows: setwd("C:\myapplication\data")
    • Linux or Mac: setwd("~/myapplication/data")
  • Attempting to access resources that are not reachable from (for example, a database behind your organization’s firewall)
  • Use of packages that require Windows ( runs on Linux)
  • Use of packages that require access to the display (e.g., packages that require Tcl/Tk)

Please read the Troubleshooting section for more information.

3.8.2 JavaScript console

Sometimes the logs do not show any errors when your application is misbehaving. All modern browsers have a mechanism to provide you with visibility into the Javascript console, where you can view JavaScript errors or responses from The contents of this console may help you investigate the problem with your application.

Different browsers have different tools that can help you see the network traffic between the browser client and the servers. This article describes how to open the JavaScript console on some of the most widely used browsers.

3.8.3 Accessing your local databases from

If your shiny application needs to access a database that you have running behind your organization’s firewall, your IT department will need to know which servers will be connecting through the firewall. Below are the IP addresses you must whitelist:


If your database is on Amazon servers, you will need to whitelist the IP addresses. To do that:

  • Log into your Amazon AWS console
  • If your database is in EC2-VPC, click on the VPC Dashboard under the Database section. If your database is in EC2-Classic, click the EC2 Dashboard under the Compute section.
  • Navigate to the Security Groups tab
  • Select the security group you want to allow access to
  • At the bottom, choose Inbound Rules and click Edit
  • Click Add another rule
  • Choose the type of connection you want to allow, the port range, and enter the IP addresses above. Note that you will have to add them as CIDR blocks - for instance -
  • Note that you will have to add a rule for each IP address, so follow steps 6-7 for each IP address given above.
  • Once you’ve finished adding each IP address, click Save.

3.8.4 Memory

If you see no errors in your logs or in the JavaScript console, your application may be using more memory than the instance is configured to allow. Unfortunately, doesn’t have a means of capturing that information and presenting it to you at this time. Try increasing the instance size and running your application again.