3  Deployment and IT Hurdles

Learning Objectives

Understand how to share a Shiny application and the tradeoffs of the different approaches. Learn to navigate common IT hurdles for developing and deploying Shiny applications.

3.1 Sharing your Shiny application

Now that you know the basics of creating a Shiny application, the next step is to learn how to share it with others or yourself at different locations. There are several ways this can be done and each comes with tradeoffs in the level of control and ease of setup. We’ll present a few options and you can decide which is preferred for your needs.

3.1.1 Sharing the script

Because a Shiny app is simply an R script or two (i.e., app.R or server.R and ui.R), they can be shared directly with others for use on their own machines. The advantage of this approach is that file sizes are small and easily shareable, although there are several disadvantages. First, any data that an app requires must also be shared. This can be simple if the data are small, but can quickly become tedious if multiple files are required or the data are larger than a few megabytes. The second and more important disadvantage is that your intended user must know how to use R and has the required dependencies (packages) installed on their machine. For these reasons, this mode of sharing is not a recommended approach for most applications.

3.1.2 Sharing on GitHub

Code for an app can also be shared on GitHub as a repository, similar to how it would be structured on your own machine.

shiny::runGitHub('tbep-tech/nwqmc-shiny', subdir = 'app-wq')

The disadvantages of this approach are similar to the previous example. A user must already know how to use R and the required packages must already be installed. The app is also not actually hosted on GitHub - only the code is made accessible. Further, this approach assumes you have a working knowledge of Git/GitHub and version control. There are some helpful resources in our Useful Links page for those interested in learning more.

3.1.3 ShinyApps.io

The easiest and most portable approach to hosting an app is using ShinyApps.io. Hosting on this service makes a publicly accessible web page for your app and allows you to host up to five apps for free. The free version is suitable for personal use and sharing with a handful of others, but it will quickly run out of the allowed hours if your app has more than a few users. Additional pricing options are available, although they may be prohibitive for individuals at the higher tiers. Visit Shiny - Getting started with shinyapps.io to run through the following sequence:

  1. Install the rsconnect R package.
  2. Create an account at ShinyApps.io.
  3. Configure rsconnect with a token in RStudio.
  4. Publish the app from RStudio using deployApp().

The disadvantage of this approach is that your app is hosted on a third-party server with limited ability to fine tune or customize the setup. This limitation is likely not a huge concern for most users. Those wanting more freedom and ownership of the hosting service should use the final option below.

3.1.4 NALMS server

The North American Lake Management Society (NALMS) hosts a shiny server on nalms.shinyapps.io as a free paid service for water resources apps. The service is paid for by NALMS and has all of the advantages of ShinyApps.io, without the need for an individual user to pay for a higher-tier subscription service. Simply use the contact information on the main page to request hosting for your app. The advantage of this approach is that the service is free and is hosted at the higher end of the pricing plan with plenty of computational resources to accommodate multiple apps. The disadvantages are similar to the previous example.

3.1.5 Shiny Server or Docker

Posit provides an open source version of Shiny Server that allows you to host apps on an internal or personal server. This may be desired if you want full control over the server and customization of the settings. Apps can also be hosted behind a firewall for an added level of security. However, this requires some knowledge of server settings and use of a Linux operating system that is common on remote servers. A dedicated server space is also needed, which usually requires a paid service, such as through Google or Amazon hosting. Apps can also be hosted with Shiny Server using Docker that “containerizes” an easily portable bundle of your app. Machines or servers only need to have Docker installed to run an app. Assuming you have comfort with server management, this is the best option for full control of hosting, although it comes with overhead of requiring server space and full management of app dependencies.

3.2 IT hurdles

One of the biggest challenges developing and deploying Shiny applications is having support from your institution’s IT or administrative staff. Nearly all of these deployment options are not viable if you do not have administrative privileges on your computer nor the ability to host and expose internal applications outside of your institution. So, the challenge becomes acceptance of the new approach rather than the technical logistics of hosting. There is no simple solution to this issue, but we offer some suggestions as you begin or continue your journey developing robust applications.

  1. Demonstrate the value of the tool: IT or administrative staff may be more willing to accept these new approaches if they can see the value it has for the organization. Presenting a functional, useful, and well designed application can go a long way in changing opinions on whether adopting the new technology is worthwhile and acceptable.

  2. Transparency in process: Clearly explaining the logistics of creating an application and the deployment requirements may be necessary to address concerns that IT staff may have about exposing content to external users. Having them understand IT requirements will also ensure that any deployment system that is setup will meet the needs for your application. This may require explaining which packages are required and what computational resources are needed. Specific versions for R packages, R itself, and Shiny Server (if used) should also be discussed.

  3. Data: Having a discussion about how data will be used by the application may also be needed. This discussion could serve two purposes. First, IT staff may have concerns about data ownership or if the application will share any sensitive information. Hosting the application on a third-party server may mean that the data are now external to your organization if included as files within the application. This may not be a huge concern if the data are not sensitive, but this potential issue should be stated upfront if a solution is needed. Any application that uses sensitive information (e.g., personal data) should also anonymize or otherwise not present this information directly. The second purpose of this discussion may be more technical if hosting the data with an application is prohibitive given the size. Shiny applications can use external databases as a data source and you may need to discuss with IT staff how this is accomplished. Using an external database may also greatly improve app performance.

  4. Licensing: The open source community has a well-established practice of licensing that defines how others may or may not use software or data. The license does not directly control how others could use your app, but it does establish a legal framework for use should it be needed with bad actors. Explaining the purpose and value of licensing to IT staff could address any legal concerns about sharing software and data publicly. Guidance on choosing an appropriate license can be found at https://choosealicense.com/.

  5. Internal applications: Controlling access to an application may be all that is needed to convince IT or administrative staff that hosting is okay. Many of the hosting services described above can be configured with credential authentication that requires a login for access. Additional services provided by Posit (e.g., Posit Connect) can also be used to setup an internal server accessible only within the organization. Posit has recognized the value of enterprising their services (at a cost) and has developed hosting products to serve these needs.

3.3 Next Steps

Now that our brief workshop is complete, we hope that you continue your journey learning to develop actionable dashboards with Shiny. Please continue to use this website as a resource for continued learning and feel free to connect with the instructors for additional advice or guidance. The Resources page also includes many useful links for additional learning and applications that can be used as templates for building your own dashboards.