Shiny Server Configuration Reference

Version {{version}}

Overview

By default, Shiny Server will look for a config file at /etc/shiny-server/shiny-server.conf; if no file is found, a default configuration will be used.

You can tell Shiny Server to use a different config file instead, by passing the config file path as an argument to shiny-server.

Shiny Server offers three distinct methods of application deployment:

1. Site directory [site_dir]

   Serve up a directory which can contain a combination of static assets (HTML files, images, PDFs, etc.), Shiny applications, and subdirectories.

   Any subdirectory that contains a shiny.R file is assumed to be a Shiny application directory. For example, if /var/shiny-server/www is your root dir and /var/shiny-server/www/sales/historical/server.R exists, then the URL for that application would be http://hostname:port/sales/historical/.

2. Autouser [user_apps]

   Any user with a home directory on the system can deploy applications simply by creating a ~/ShinyApps directory and placing their Shiny applications in direct subdirectories.

   For example, if /users is configured to be an autouser path, and the user jeffreyhorner creates a folder ~/ShinyApps/testapp that contains a server.R and a ui.R file, then browsing to http://hostname/users/jeffreyhorner/testapp/ would automatically load that application.

3. Direct mapping [app_dir]

   Explicitly declare one or more applications in the configuration file.

   For each individual application you can specify the URL, application directory path, log directory, and which user to run the application as.

(A single Shiny Server instance can host all three of the above types of URL paths at the same time; you don't have to restrict yourself to just one. See the fourth example below.)

Examples

Here is a minimal configuration file for a server that only does autouser hosting:

server {
  # The TCP/IP port to listen on
  listen 80;

  # Configure the root URL to be autouser
  location / {
    user_apps on;
  }
}

Here is a minimal configuration file for a server that is backed by a directory that contains a combination of static assets and Shiny applications:

# By default, use the 'shiny' user to run the applications; this
# user should have the minimum amount of privileges necessary to
# successfully run the applications (i.e. read-only access to the
# site dir).
run_as shiny;

# The directory where application log files should be written to.
# This directory must exist--it will NOT be automatically created.
log_dir /var/log/shiny-server/apps/;

server {
  listen 80;

  location / {
    site_dir /var/shiny-www;
  }
}

Here is a simple configuration file for a server that hosts two apps:

# By default, use the 'shiny' user to run the applications; this
# user should have the minimum amount of privileges necessary to
# successfully run the applications (i.e. read-only access to the
# Shiny app dirs).
run_as shiny;

# The directory where application log files should be written to.
# This directory must exist--it will NOT be automatically created.
log_dir /var/log/shiny-server/apps/;

server {
  listen 80;

  location /app1 {
    app_dir /var/shiny-apps/app1;
  }

  location /app2 {
    app_dir /var/shiny-apps/app2;
  }
}

You can have multiple location directives per server block, and they don't need to all be of the same kind; you can easily incorporate all three hosting models in the same server instance.

run_as shiny;
log_dir /var/log/shiny-server/log/;

server {
  listen 80;

  location /users {
    user_apps on;
  }

  location /dashboard {
    app_dir /var/dashboard/shinyapp;
  }

  location / {
    site_dir /var/shiny-server/www;
  }
}

Directive Reference

Listed below are all the directives that are supported in Shiny Server config files.

Applies to indicates the kind of parent scope that this directive normally appears inside.

Inheritable means that you can put this directive at a higher level in the hierarchy and it will be inherited by any children to which it might apply. Inherited directives can be overridden by using the directive again in a child scope.

{{#each directives}}

• {{name}}

  {{{desc}}}

  {{#if params}} {{#each params}} {{/each}}

  Parameter	Data type	Type	Description	Default
  {{name}}	{{type}}	{{#if optional}}optional{{else}}{{#if vararg}}multiple{{else}}required{{/if}}{{/if}}	{{{desc}}}	{{defaultValue}}

  {{else}}

  This directive has no parameters.

  {{/if}}

  Applies to: {{{scopelist primaryLoc}}}
  Inheritable: {{YesNo otherLocs}}
  {{#if children}} Child directives: {{{scopelist children}}}
  {{/if}}

{{/each}}