Launcher Configuration
By default, a fresh installation of Posit Workbench comes with the Job Launcher and the Local Plugin enabled. No additional configuration is necessary to enable the use of Launcher Sessions or Workbench Jobs with the Local Plugin. If you wish to enable another Launcher Plugin to integrate with a container orchestration system (e.g., Kubernetes) or a batch processing system (e.g., Slurm), configuration changes will be necessary. Additionally, if you wish to enable load balancing for your Posit Workbench installation there will be some extra configuration considerations. See the Launcher Considerations section of the Load Balancing chapter for more information.
The Launcher configuration parameter admin-group will by default be configured to use the group value of the Posit Workbench server user, specified in the server-user configuration parameter in rserver.conf (which defaults to rstudio-server). This makes the server user a Job Launcher admin, which is necessary to properly launch sessions on behalf of other users.
Server configuration
The Posit Workbench process rserver must be configured to communicate with the Job Launcher in order to enable session launching. The following table lists the various configuration options that are available to be specified in the rserver.conf configuration file:
Server options
/etc/rstudio/rserver.conf
| Config Option | Description | Required (Y/N) | Default Value |
|---|---|---|---|
| launcher-sessions-enabled | Enables launching of rsession processes via the Job Launcher. This must be enabled to use the Job Launcher. | N | 0 |
| launcher-address | TCP host/IP of the launcher host, or unix domain socket path (must match /etc/rstudio/launcher.conf configuration value). If using the default launcher configuration that ships with Workbench, this should be localhost (assuming you run the launcher side-by-side with Posit Workbench). |
Y | |
| launcher-port | Port that the launcher is listening on. Only required if not using unix domain sockets. If using the default launcher configuration that ships with Workbench, this should be 5559. |
Y | |
| launcher-default-cluster | Name of the cluster to use when launching sessions. Can be overridden by the launching user. | N | |
| launcher-sessions-callback-address | Address (HTTP or HTTPS) of Posit Workbench that will be used by launcher sessions to communicate back for project sharing and launcher features. The address must be the reachable address of the rserver process from the host that will be running rsession, which in the case of launcher sessions can be on a different network segment entirely. If Workbench is configured to use SSL, you must also ensure that the callback address hostname matches the FQDN of the Common Name or one of the Subject Alternate Names on the HTTPS certificate. See the example configuration below for more details. |
Y | |
| launcher-sessions-callback-verify-ssl-certs | Whether or not to verify SSL certificates when Launcher sessions are connecting to Workbench. Only applicable if connecting over HTTPS. For production use, you should always leave the default or have this set to true, but it can be disabled for testing purposes. | N | 1 |
| launcher-use-ssl | Whether or not to connect to the launcher over HTTPS. Only supported for connections that do not use unix domain sockets. | N | 0 |
| launcher-verify-ssl-certs | Whether or not to verify SSL certificates when connecting to the launcher. Only applicable if connecting over HTTPS. For production use, you should always leave the default or have this set to true, but it can be disabled for testing purposes. | N | 1 |
| launcher-sessions-clusters | List of clusters to allow for submitting interactive session jobs to. The default allows all job launcher clusters to run interactive sessions. | N | |
| launcher-adhoc-clusters | List of clusters to allow for submitting ad hoc jobs from the Launcher pane. The default allows all job launcher clusters to run ad hoc jobs. | N | |
| launcher-sessions-container-image | The default container image to use when creating sessions. Only required if using a plugin that requires containerization. If none is specified, the Job launcher-specified default will be used, if the plugin supports it. | N | |
| launcher-sessions-auto-update | Indicates whether or not to automatically update session components on non-Local clusters. Only supported on Kubenernetes. | N | 0 |
| launcher-sessions-container-images | Comma-separated list of images which may be used for launching sessions. Used to filter out incompatible entries from the UI when a user is selecting an image to use for running the session. Leave blank to allow all images to be used. | N | |
| launcher-adhoc-container-images | Comma-separated list of images which may be used for launching ad hoc jobs. Used to filter out incompatible entries from the UI when a user is selecting an image to use for running an ad hoc job. Leave blank to allow all images to be used. | N | |
| launcher-sessions-container-run-as-root | Whether or not to run as root within the session container. We recommend you do not use this in most cases. | N | 0 |
| launcher-sessions-create-container-user | Whether or not to create the session user within the container. Only applicable if using container sessions and not running containers as root. The created user will have the same UID, GID, home directory, and login shell as the user that launched the session. It is recommended that this option be used, unless your containers connect to an LDAP service to manage users and groups. The container starts as root so it can create the correct user and group ids, then drops privilege to use the created user account. If it cannot drop privilege the container will fail to start. | N | 1 |
| launcher-sessions-forward-container-environment | Whether or not to forward any container environment variables to the session. This is useful for example, propagating Kubernetes secrets to the session. However, the variables USER, HOME, and LOGNAME are not forwarded, and are loaded from the user’s passwd entry. |
N | 1 |
| launcher-sessions-connection-timeout-seconds | Number of seconds to allow for making the initial connection to a launcher session. Connection failures are retried automatically - this is simply to prevent unreachable hosts from hanging the retry process as the default connection timeout on most systems is very high. Only change this if you are having trouble connecting to sessions. A value of 0 indicates that there should be no timeout (system default). | N | 3 |
| launcher-sessions-container-forward-groups | Whether or not to forward the user’s supplemental groups to the created containers. This will only be done when not creating the container user, and when running the container as a non-root user, such as if integrating with LDAP. This is enabled by default, but if group lookups are very expensive in your environment and supplemental groups are not necessary, this can be disabled. | N | 1 |
Sample Server Configuration
For example, your rserver.conf file might look like the following:
/etc/rstudio/rserver.conf
launcher-address=localhost
launcher-port=5559
launcher-sessions-enabled=1
launcher-default-cluster=Kubernetes
# the callback address that launcher sessions will reconnect to rserver on
# since our Kubernetes jobs run on a different network segment, this needs
# to be the routable IP address of the web server servicing RStudio traffic
# (routable from the point of view of any Kubernetes nodes)
launcher-sessions-callback-address=http://10.15.44.30:8787
launcher-use-ssl=1
launcher-sessions-container-image=rstudio:R-4.2
launcher-sessions-container-run-as-root=0
launcher-sessions-create-container-user=1Launcher configuration
To configure the Job Launcher, create and modify the /etc/rstudio/launcher.conf file. Configuration options are listed below.
Launcher options
/etc/rstudio/launcher.conf
| Config Option | Description | Required (Y/N) | Default Value |
|---|---|---|---|
| address | IPv4 or IPv6 address, or path to Unix domain socket | Y | |
| port | Port number (0-65535) | Y (when using IP Address) | |
| enable-ssl | Toggle usage of SSL encryption for connections | N | 0 |
| certificate-file | Certificate chain file of public certificates to present to incoming connections. Must be readable by the server-user user. |
Y | (Only required when SSL is enabled) |
| certificate-key-file | Certificate private key file used for encryption. Must be readable by the server-user user. |
Y | (Only required when SSL is enabled) |
| server-user | Service user. The Launcher should be started as root, and will lower its privilege to this user for normal execution. | N | rstudio-server |
| authorization-enabled | Enables/disables authorization - this is required for all but test systems. Can be 1 (enabled) or 0 (disabled) | N | 1 |
| admin-group | Group name of users that are able to see/control all jobs in the system, including jobs belonging to other users. If using with Posit Workbench, this must match the rserver.conf’s server-user’s group value. |
N | Empty |
| thread-pool-size | Size of the thread pools used by the launcher | N | Number of CPUs * 2 |
| request-timeout-seconds | Number of seconds a plugin has to process a request before it is considered timed out | N | 120 |
| bootstrap-timeout-seconds | Number of seconds a plugin has to bootstrap before it is considered a failure | N | 120 |
| max-message-size | Maximum allowed message size (in bytes) of messages sent by plugins. It is strongly recommended you do not change this, but it may be increased if you exceed the limit. | N | 5242880 |
| enable-debug-logging | Enables/disables verbose debug logging. Can be 1 (enabled) or 0 (disabled) | N | 0 |
| scratch-path | Scratch directory where the launcher and its plugins write temporary state | N | /var/lib/rstudio-launcher |
| logging-dir | Specifies the path where debug logs should be written. | N | /var/log/rstudio/launcher |
| secure-cookie-key-file | Location of the secure cookie key, which is used to perform authorization/authentication. It is strongly recommended you do not change this. | N | /etc/rstudio/secure-cookie-key |
| enable-cgroups | Enables/disables cgroups for local launcher resource limits. Can be 1 (enabled) or 0 (disabled) | N | 0 |
Cluster options
/etc/rstudio/launcher.conf
| Config Option | Description | Required (Y/N) | Default Value |
|---|---|---|---|
| name | Friendly name of the cluster | Y | |
| type | Type of the cluster (for human consumption, display purposes) | Y | The plugin type. Can be one of Local, Kubernetes, or Slurm |
| exe | Path to the plugin executable for this cluster | N | If using a plugin provided by Posit like Local, Kubernetes, or Slurm, this will be inferred from the value of type. If using a custom plugin, you must provide the executable path by configuring this option. |
| config-file | Path to the configuration file for the plugin | N | Each plugin will have its own default config location |
| allowed-groups | Comma-separated list of user groups that may access this cluster | N | Empty (all groups may access) |
Sample Launcher configuration
There should be one [server] section in the configuration file. There should also be one [cluster] section in the configuration file per cluster to connect to / plugin to load.
/etc/rstudio/launcher.conf
[server]
address=127.0.0.1
port=5559
server-user=rstudio-server
admin-group=rstudio-server
authorization-enabled=1
thread-pool-size=4
enable-debug-logging=1
[cluster]
name=Local
type=Local
exe=/usr/lib/rstudio-server/bin/rstudio-local-launcher
allowed-groups=devs,adminsSSL considerations
The Job Launcher can be configured to use SSL via the use of the certificate-file and certificate-key-file options above. When the Launcher is configured to use SSL, any node(s) connecting to the Launcher must ensure that the hostname configured in their address field matches the FQDN of the Common Name or Subject Alternate Name of the certificate that is presented by the Launcher. If the hostnames do not match exactly, SSL verification will fail, preventing connections to the Job Launcher.
Similarly, if Posit Workbench is configured to use SSL, the hostname configured in the launcher-sessions-callback-address field must match the FQDN of the Common Name or Subject Alternate Name of the certificate that is presented by Workbench. Failure to do so will cause certificate verification to fail when sessions attempt to connect to Workbench, preventing you from using Job Launcher functionality such as starting Launcher jobs.
The certificate files must be readable by the server-user user account, and it is recommended that the permissions be very restrictive to prevent leaking of the private key. This can be accomplished by setting the permissions to 600 and changing the owner to the server-user account. For example, if the server-user is set to the default rstudio-server account:
/etc/rstudio/launcher.conf
certificate-file=/etc/rstudio/launcher.crt
certificate-key-file=/etc/rstudio/launcher.keysudo chmod 0600 /etc/rstudio/launcher.crt
sudo chmod 0600 /etc/rstudio/launcher.key
sudo chown rstudio-server /etc/rstudio/launcher.crt
sudo chown rstudio-server /etc/rstudio/launcher.keyAdditionally, both the Posit Workbench and Job Launcher root certificates need to be imported into the trusted root certificate store on the systems that are accessing those addresses. For example, the Workbench server nodes need to have the Job Launcher root certificate installed in their trusted certificate store to ensure that certificate verification works correctly. The exact steps for importing a certificate into the trusted root store are operating system specific and outside of the scope of this document.
Authentication
Posit Workbench authenticates with the Job Launcher via the secure-cookie-key file, a secret key that is read on startup of both the launcher and Workbench which is only readable by the root account. The file is present at /etc/rstudio/secure-cookie-key. If the Job Launcher is running on a different machine than Posit Workbench, you will need to make sure that the exact same secure-cookie-key file is present on both machines.
To do this, create a secure cookie key file on one of the nodes like so:
# generate secure-cookie-key as a simple UUID
sudo sh -c "echo `uuidgen` > /etc/rstudio/secure-cookie-key"
# ensure that the cookie is only readable by root
sudo chmod 0600 /etc/rstudio/secure-cookie-keyOnce this file has been created, copy it to the other node to the same location so that both services use the same key. Alternatively, you could accomplish this via a symlink to a location on a file share.
The path to the secure-cookie-key file can be changed, but it is not recommended in most cases. If you need to change it, it can be done by adding the following line to the /etc/rstudio/rserver.conf and /etc/rstudio/launcher.conf configuration files:
/etc/rstudio/rserver.conf
secure-cookie-key-file=/path/to/secure-cookie-keyand:
/etc/rstudio/launcher.conf
secure-cookie-key-file=/path/to/secure-cookie-keyWhen running Launcher sessions in a load balanced Workbench deployment, sessions do additional authorization verification to ensure that they are only used by the user that created them. This is accomplished by an RSA key pair, located at /etc/rstudio/launcher.pem and /etc/rstudio/launcher.pub. These files must be the same on every Workbench node, or users will be unable to use their sessions on multiple nodes.
In order to create the RSA files, run the following commands:
sudo openssl genpkey -algorithm RSA -out /etc/rstudio/launcher.pem -pkeyopt rsa_keygen_bits:2048
sudo openssl rsa -in /etc/rstudio/launcher.pem -pubout > /etc/rstudio/launcher.pub
sudo chmod 0600 /etc/rstudio/launcher.pem"You must ensure that the above private key (.pem) file is owned by root and has 600 permissions, as it must remain secret to your users.
Once the files are created, simply copy them to each Workbench node in your cluster.
Launcher sessions
It is recommended that you configure the Shared Storage path (see Shared storage for configuration) in a location that will be reachable both by the Posit Workbench instance and each Launcher Session in order to support various Workbench features. Failure to do so could cause subtle, unintended issues.
See the Launcher mounts section for more details about how to configure this correctly with Containerized sessions.
Containerized sessions
In order to run your Workbench Sessions in containers, you will need a Docker image that contains the necessary system dependencies, R versions, R packages, Python, and any other desired components. Posit provides an official base image for this purpose, rstudio/workbench-session, which you can get from Docker Hub.
At runtime, the session container also requires the presence of Workbench session components, such as the rsession binary. On Kubernetes, this is accomplished by using an init container to copy these components to the session container at runtime. See the Session init container section for more details.
For container-based job systems that are not Kubernetes, such as Singularity and Apptainer, the rstudio/r-session-complete image is recommended. rstudio/r-session-complete contains the necessary session components such as the rsession binary that are copied by the init container in Kubernetes. See Docker Hub for more information on the rstudio/r-session-complete image. When using the rstudio/r-session-complete image, it is not necessary to set the launcher-sessions-auto-update option in the rserver.conf file.
Customizing the base image
The rstudio/workbench-session image is tagged with the Ubuntu version that it is based on, as well as the versions of R and Python that come pre-installed. These images can be used as a base image to create your own custom image that includes additional R versions, R packages, system dependencies, Python versions, or other components that your users require. To get the base image, pull one of the provided images from Docker Hub.
docker pull rstudio/workbench-session:ubuntu2204-r4.4.1_4.3.3-py3.12.6_3.11.10After pulling the base image, create your own Dockerfile that extends from the workbench-session image and customize it by adding any additional R versions, R packages, system dependencies, Python versions, or other components that your users require. We recommend that you follow our approved procedures for Installing R. For example, your Dockerfile could look similar to the following:
FROM rstudio/workbench-session:ubuntu2204-r4.4.1_4.3.3-py3.12.6_3.11.10
ARG R_VERSION
# install system dependencies
RUN apt-get update
&& apt-get install -y gdebi-core
# install desired version of R
RUN curl -O https://cdn.rstudio.com/r/ubuntu-2204/pkgs/r-${R_VERSION}_1_amd64.deb \
&& gdebi r-${R_VERSION}_1_amd64.deb
# install R packages
...For more information on using custom docker images for Posit Workbench sessions, see the Using Docker Images section of this guide.
Session init container
To make the maintenance of session images as seamless as possible, Posit Workbench utilizes an init container when deploying sessions to Kubernetes clusters.
The session init container is not enabled by default, but is the recommended configuration for Kubernetes clusters. To use this feature, enable it in /etc/rstudio/rserver.conf:
/etc/rstudio/rserver.conf
launcher-sessions-auto-update=1Posit maintains an official init container image which is 1:1 with the Workbench version. When a session Pod is created in Kubernetes, Workbench also creates an EmptyDir volume. This empty directory is used as a staging area for the Workbench session components. The init container is then responsible for copying the session components to the staging area so that they are available to the session container.
Launcher mounts
When creating containerized sessions via the Job Launcher, you will need to specify mount points as appropriate to mount the users’ home drives and any other desired paths. In order for sessions to run properly within containers, it is required to mount the home directories into the containers, as well as any directories containing per-user state (e.g., a customized XDG_DATA_HOME). The home mount path within the container must be the same as the user’s home path as seen by the Posit Workbench instance itself (generally, /home/{USER}).
When using project sharing, all user home directories must be mounted in each cluster, so the {USER} tag should not be included in the mount, or a dedicated project shared directory must be configured and mounted. See Shared projects root directory for more information.
To specify mount points, modify the /etc/rstudio/launcher-mounts file to consist of multiple mount entries separated by a blank line. The following table lists the fields that are available for each mount entry in the file.
| Field | Description | Required (Y/N) | Default Value |
|---|---|---|---|
| MountType | The type of mount. Can be Host, NFS, CephFs, GlusterFs, AzureFile, KubernetesPersistentVolumeClaim, or Passthrough |
Y | |
| MountPath | The path within the container that the directory will be mounted to. | Y | |
| ReadOnly | Whether or not the mount is read only. Can be true or false. | N | false |
| JobType | What type of jobs the mount is applied to. Can be session, adhoc, or any. |
N | any |
| Workbench | What type of workbench the mount is applied to. Can be rstudio, jupyterlab, jupyter notebook, vs code, positron, or any. |
N | any |
| Cluster | The specific cluster that this mount applies to. Applies to all clusters if not specified. | N | |
| Groups | Comma-separated list of group names whose users will have this mount configured. | N |
Depending on the MountType specified above, different settings may be used to control the mount.
MountType: Host
| Field | Description | Required (Y/N) |
|---|---|---|
| Path | The source directory of the mount, i.e. where the mount data comes from. | Y |
MountType: NFS
| Field | Description | Required (Y/N) |
|---|---|---|
| Path | The source directory of the mount, i.e. where the mount data comes from. | Y |
| Host | The NFS host name for the NFS mount. | N |
MountType: CephFs
| Field | Description | Required (Y/N) |
|---|---|---|
| Monitors | A comma-separated list of Ceph monitor addresses. For example: 192.168.1.200:8765,192.168.1.200:8766 |
Y |
| Path | The path within the Ceph filesystem to mount | N |
| User | The Ceph username to use | N |
| SecretFile | The file which contains the Ceph keyring for authentication | N |
| SecretRef | Reference to Ceph authentication secrets, which overrides SecretFile if specified |
N |
MountType: GlusterFs
| Field | Description | Required (Y/N) |
|---|---|---|
| Endpoints | The name of the endpoints object that represents a Gluster cluster configuration | Y |
| Path | The name of the GlusterFs volume | Y |
MountType: AzureFile
| Field | Description | Required (Y/N) |
|---|---|---|
| SecretName | The name of the secret that contains both the Azure storage account name and the key | Y |
| ShareName | The share name to be used |
MountType: KubernetesPersistentVolumeClaim
| Field | Description | Required (Y/N) |
|---|---|---|
| ClaimName | The name of the Kubernetes Persistent Volume Claim to use | Y |
| SubPath | The subPath to use within the path exposed by the PVC. See here |
N |
MountType: Passthrough
| Field | Description | Required (Y/N) |
|---|---|---|
| FilePath | Path to a file that contains the raw JSON object representing the mount, which is sent directly to the back-end without transformation | Y |
Note that for many mount types, paths may contain the special variable
{USER}to indicate that the user’s name be substituted, enabling you to mount user-specific paths.
An example /etc/rstudio/launcher-mounts file is shown below.
/etc/rstudio/launcher-mounts
# User home mount - This is REQUIRED for the session to run
MountType: NFS
Host: nfs01
Path: /home/{USER}
MountPath: /home/{USER}
ReadOnly: false
# Shared code mount
Cluster: Kubernetes
MountType: NFS
Host: nfs01
Path: /dev64
MountPath: /code
ReadOnly: false
# Only mount the following directory when the user is launching a JupyterLab session
Cluster: Kubernetes
Workbench: JupyterLab
MountType: CephFs
Monitors: 127.0.0.1:8080,127.0.0.1:8081
SecretFile: /etc/secrets/ceph
ReadOnly: trueIt is important that each entry consists of the fields as specified above. Each field must go on its own line. There should be no empty lines between field definitions. Each entry must be separated by one full blank line (two new-line \n characters).
If you choose to run your containers as root, the user home drive must be mapped to /root. For example:
/etc/rstudio/launcher-mounts
MountType: NFS
Host: nfs01
Path: /home/{USER}
MountPath: /root
ReadOnly: falseAs noted in the Launcher sessions section, it is recommended that you also mount the Shared Storage path (see Shared storage for configuration) into the session container to support various RStudio features. When mounting the shared storage path, ensure that the folder is mounted to the same path within the container to ensure that the rsession executable will correctly find it. For example:
/etc/rstudio/launcher-mounts
MountType: NFS
Host: nfs01
Path: /rstudio/shared-storage
MountPath: /rstudio/shared-storage
ReadOnly: falseSingularity
If using Singularity, MountType: Host is the only compatible MountType. For example, for Singularity your launcher-mounts might look like this:
/etc/rstudio/launcher-mounts
MountType: Host
Groups: pwrusers
MountPath: /mnt/power-users
Path: /data/power-usersLauncher environment
You may optionally specify environment variables to set when creating launcher sessions.
To specify environment overrides, modify the /etc/rstudio/launcher-env file to consist of multiple environment entries separated by a blank line. The following table lists the fields that are available for each environment entry in the file.
| Field | Description | Required (Y/N) | Default Value |
|---|---|---|---|
| JobType | What type of jobs the environment value(s) is applied to. Can be session, adhoc, or any. |
N | any |
| Workbench | What type of workbench the mount is applied to. Can be rstudio, jupyterlab, jupyter notebook, vs code, or any. |
N | any |
| Cluster | The specific cluster that the environment applies to. Applies to all clusters if not specified. | N | |
| Environment | The environment variables to set, one per line (each subsequent line must be indented with an arbitrary amount of spaces or tabs), in the form of KEY=VALUE pairs. |
N |
Additionally, you can use the special {USER} variable to specify the value of the launching user’s username, similar to the mounts file above.
An example /etc/rstudio/launcher-env file is shown below.
/etc/rstudio/launcher-env
JobType: session
Environment: IS_LAUNCHER_SESSION=1
IS_ADHOC_JOB=0
USER_HOME=/home/{USER}
JobType: adhoc
Environment: IS_LAUNCHER_SESSION=0
IS_ADHOC_JOB=1
USER_HOME=/home/{USER}
JobType: any
Cluster: Kubernetes
ENVIRONMENT: IS_KUBERNETES=1If you do not need to set different environment variables for different job types or different clusters, you may simply specify KEY=VALUE pairs, one per line, which will be applied to all launcher ad hoc jobs and sessions. For example:
IS_LAUNCHER_JOB=1
USER_HOME=/home/{USER}Launcher ports
You may optionally specify ports that should be exposed when creating containerized jobs. This will allow the ports to be exposed within the host running the container, allowing the ports to be reachable from external services. For example, for Shiny applications to be usable, you must expose the desired Shiny port, otherwise the browser window will not be able to connect to the Shiny application running within the container.
To specify exposed ports, modify the /etc/rstudio/launcher-ports file to consist of multiple port entries separated by a blank line. The following table lists the fields that are available for each port entry in the file.
| Field | Description | Required (Y/N) | Default Value |
|---|---|---|---|
| JobType | What type of jobs the port(s) is applied to. Can be session, adhoc, or any. |
N | any |
| Workbench | What type of workbench the mount is applied to. Can be rstudio, jupyterlab, jupyter notebook, vs code, or any. |
N | any |
| Cluster | The specific cluster that this set of ports applies to. Applies to all clusters if not specified. | N | |
| Ports | The ports to expose, one per line (each subsequent line must be indented with an arbitrary amount of spaces or tabs). | N |
An example /etc/rstudio/launcher-ports file is shown below.
/etc/rstudio/launcher-ports
JobType: adhoc
Ports: 6210
6143
6244
6676
# additional Kubernetes ports to expose
JobType: adhoc
Cluster: Kubernetes
Ports: 4434If you do not need to set different exposed ports for different job types or different clusters, you may simply specify port values, one per line, which will be applied to all launcher ad hoc jobs and sessions. For example:
/etc/rstudio/launcher-ports
5873
5874
64234
64235Containerized ad hoc jobs
To run ad hoc jobs in containers from the Launcher pane, you need a Docker image containing the bash shell and the desired version of R on the path.
The ad hoc job container will run using the same userId and groupId value as the Workbench user. In order for scripts under the home directory to be found in the container, the home directory must be mounted with the same absolute path inside the container.
Jobs started from the RStudio Pro R console via rstudioapi::launcherSubmitJob() have no specific container requirements.
Job Launcher plugin configuration
Each specific cluster plugin can be additionally configured via its own configuration file, and some plugins (such as the Kubernetes plugin) require additional configuration. Documentation for all plugins created by Posit can be found in the following sections: Local Plugin, Kubernetes Plugin, Slurm Plugin.