Unlike older versions of RStudio's application hosting services (such as Spark or Glimmer), shinyapps.io does not provide a development environment in the cloud. For this reason, the user has to develop their applications entirely somewhere else (either locally or on another server) and then upload the applications to their shinyapps.io account. The following shows an outline of the necessary steps to do this:
- Check whether you have the corresponding package builder in your operating system. This is basically a compiler that will be used by R in order to build the packages.
- Install
devtools. This is a package that is included in CRAN, the official R repository, to develop and distribute packages that are not available in CRAN. Among their functions, for example,install_githubcan be found, which installs a package from a GitHub repository. The installation command is the same for all the packages:install.packages("devtools") - The previous step was necessary mainly because hosting applications on shinyapps.io depends on a package that is not available in CRAN. So, after installing
devtools,install_githubhas to be used:devtools::install_github('rstudio/shinyapps') - Next, load the package.
- Go to shinyapps.io and register for an account.
- Once logged in, under the user's logo, there is a menu named Tokens. Here, you will get the token, secret key, and command to run on the machine from where you are going to deploy the applications. This is basically an OAuth method. Copy the command, paste it, and run it on your local RStudio. There is even a button to copy the command directly.
- Finally, in order to upload the directory, execute
deployApp(), which will upload the application's files to your shinyapps.io instance and if needed, will install the necessary packages in your instance.deployApp()expects a path to a directory. If nothing is passed, it takes the working directory as the default. - After the upload is complete, your application will be accessible at
https://(your user name).shinyapps.io/(application's folder name)/.Note
You can see the full documentation at http://shiny.rstudio.com/articles/shinyapps.html.
As it was previously mentioned, the Shiny applications can also be deployed on your own servers. However, there are still different versions of this; you can either use the open source version, which has certain limitations, or you can choose the paid one, which offers some extra capabilities such as user administration, password protecting, among others.
Keep in mind that the Shiny server is designed for Ubuntu, CentOS, and SUSE Linux Enterprise. Of course, the server instance where the applications will be hosted needs to have R, the RStudio server, and the Shiny package installed. It is important to keep in mind that all of these must be installed as superuser.
The R installation on a server is identical to the R installation on a local computer. The following is an example in Ubuntu:
sudo apt-get install r-base sudo apt-get install r-base-dev
For further information about these commands, see Chapter 1, Introducing R, RStudio, and Shiny.
Although the installation process is exactly the same as RStudio for local computers, the program to be downloaded is different and consequently, the link to download it is different as well. The following is an example in Ubuntu:
sudo apt-get install gdebi-core (avoid this step if you have already gdebi-core installed) wget https://download2.rstudio.org/rstudio-server-0.99.451-amd64.deb sudo gdebi rstudio-server-0.99.451-amd64.deb
It is worth pointing out that installing RStudio will not only enable application hosting on your server, but will also give the possibility that every user in that VM can work in R with RStudio directly on the server from an ordinary browser, without needing to install R nor RStudio locally. The RStudio IDE serves normally on the 8787 port, so if the RStudio server is installed, it can be accessed by entering an address such as (IP of your server): 8787
As the package will need to be accessible to every user, it will be necessary that it is installed as superuser as follows:
Initialize R as superuser directly from the console by typing the following:
sudo R
R will begin. After this, install Shiny as usual as follows:
install.packages("shiny")
In this way, Shiny will be installed through the /usr/local/lib/R/site-library path, which is accessible to every user on this server.
Regardless of whether it is a paid version or not, it is still quite simple, especially for those who have some experience with configuration in Linux environments. The following is an outline of the steps to follow.
Install the Shiny server by running the following commands:
sudo apt-get install gdebi-core wget https://download3.rstudio.org/ubuntu-12.04/x86_64/shiny-server-1.3.0.403-amd64.deb sudo gdebi shiny-server-1.3.0.403-amd64.deb
The first line could probably be avoided because gdebi-core was surely installed in the previous step.
The installation of the Shiny server will create a configuration file named shiny-server.conf under the /etc/shiny-server/ path, where the configuration options of every application hosted in that server are specified. This is how it looks like by default:
# Instruct Shiny Server to run applications as the user "shiny"
run_as shiny;
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location / {
# Host the directory of Shiny Apps stored in this directory
site_dir /srv/shiny-server;
# Log all Shiny output to files in this directory
log_dir /var/log/shiny-server;
# When a user visits the base URL rather than a particular application,
# an index of the applications available in this directory will be shown.
directory_index on;
}
}Note
The full documentation is available under the following link: http://rstudio.github.io/shiny-server/latest/.
The configuration is specified as item value, and as it can be observed, these specifications have a nested structure, which implies that every one of them is cascaded to the structures they contain, unless any of the child structures specify something different. In the following, you will find a small explanation of the most important configuration options:
run_aslistenlocationsite_dir/app_dirdirectory_index
This is the username that the application will be running as. By default, the Shiny installation creates a generic user called shiny, which is the default for this field. In more concrete words, this means that whenever the application is used, it will be under the user stated in run_as. This is important because every user has their own library paths (accessible with .libPaths()).
So, if the user specified in run_as has no access to a library that is used in the application, it will probably throw an error related to this such as There is no package called …. To prevent this, the necessary packages should be installed as superuser in the same way that was explained before as this will install the package on a path that is included by default for every user:
sudo R install.packages("package_to_install")
This specifies the port where the applications will be listening. It is highly recommendable for non-expert users to keep the default, as the port numbers are usually associated with specific protocols. Changing this may lead to the malfunction of all the applications.
location defines a name where the application will be hosted. For example, if the location is specified as /exampleApplication, then it will be accessible with the default port listening under (the IP of the server): 3838/exampleApplication.
These options are nested inside a location structure. Both specify a path where one or many applications reside. The main difference is that site_dir can contain multiple application directories while app_dir points to a specific application.
In the following, different configuration alternatives are presented for an imaginary situation where two application directories, app1 and app2, are contained in the /home/user1/applications directory:
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location /application1 {
# Host the directory of Shiny Apps stored in this directory
app_dir /home/user1/applications/app1;
}
location /application2 {
# Host the directory of Shiny Apps stored in this directory
app_dir /home/user1/applications/app2;
}
}In this case, the applications will be accessible at (IP): 3838/application1 and (IP): 3838/application2, respectively.
A single location structure with site_dir can be used too as follows:
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location /applications {
# Host the directory of Shiny Apps stored in this directory
site_dir /home/user1/applications/;
}
}The URLs here would be (IP): 3838/applications/app1 and (IP): 3838/applications/app2. Note that in this case the URL ending points to the directory name of the particular application. This is because site_dir is replaced by the location specified, but the application's directory name remains.
This specifies whether an index of applications available is shown when the user accesses the applications' base directories specified in site_dir. Looking back at the previous example, if the user accesses (IP): 3838/applications/, an index page showing the different applications will be displayed if directory_index is set to on.