Requirements

The following page lists detailed information on the supported server and browser platforms, recommended minimal CPU, RAM, and disk storage. It lists requirements for all deployments and for your specific deployment type.

Requirements for all deployments

System and platform requirements

Posit Workbench runs on most modern Linux distributions and can be accessed in most modern browsers.

Workbench requires its own server, separate from Posit Connect and Posit Package Manager. The server can be physical, virtual, or a container. It does not need to be bare-metal hardware, only one that is not shared with those products. Co-locating these products causes them to compete for CPU, RAM, and disk, which can lead to instability and degraded performance.

NotePlatform Support

We recommend viewing our Platform Support page, which offers an in-depth overview of Posit’s Platform Support strategy and lists our supported operating systems and browsers.

Supported x86-64 Linux distributions

  • RHEL 8, 9, and 10
  • Ubuntu Linux 22, 24, and 26
  • Debian Linux 13
  • SUSE Linux 15 SP7 / openSUSE 15.6

Supported ARM (aarch64) Linux distributions

  • RHEL 10
  • Ubuntu Linux 24 and 26

Linux and privilege requirements

ImportantSELinux requirements

If you need to use Workbench with SELinux in enforcing mode, you must install the SELinux policy module before installing Workbench. For steps and details, see the SELinux Configuration section.

Knowledge of how to safely administer a Linux system with root privileges is required.

Posit professional products are designed to run code safely. The products take advantage of sandboxing and user impersonation. To seamlessly ensure safe execution for many uses, the products themselves have certain privilege requirements.

When run on server, Posit professional products typically install and run as root. When used in containers, some Posit professional products require container privileges. The table below summarizes permission requirements for Workbench.

Location Permission requirements
Server Installation requires root, Workbench runs as root. Kubernetes Launcher must meet requirements as described in the per-deployment requirements section (off-host execution).
Docker Requires root in the container. The Local Launcher can run in unprivileged mode. Session containers (i.e., Pods) run with Kubernetes Launcher do not require running in privileged mode.

Runtime support

Note

RStudio Pro, VS Code, and Positron Pro do not require Python. However, we recommend installing Python to provide users with the most choice.

R

  • Workbench requires R version 3.6.0 or higher.
  • We recommend installing multiple versions of R. See Installing R for details.

Python

  • Python is required to run JupyterLab or Jupyter Notebook sessions, or to run Python code in any IDE.
  • We recommend installing multiple versions of Python. See Installing Python for details.
  • This version of Workbench includes Positron version 2026.04.1-10, which supports Python versions 3.9 through 3.13. See Positron prerequisites for the full list of supported Python and R versions.

Browser support

  • Microsoft Edge
  • Chrome
  • Safari
  • Firefox (version 126.0 or higher recommended1)

Network

By default, Posit Workbench accepts connections on port 8787 for HTTP and 443 for HTTPS.

For additional information, such as configuring a custom port, see the Network Port and Address section.

Internet access requirements

If you are using VS Code, extensions cannot be installed without outbound access to:

  • https://open-vsx.org

Requirements for your deployment type

Select your deployment type to see the extra requirements for it. The requirements for all deployments also apply.

  • A Workbench license
  • A Workbench license that permits multiple servers (Enhanced or Advanced tier)
  • The same version of Workbench on each node
  • A shared PostgreSQL database that all nodes use to store Workbench metadata
  • Shared storage for Workbench session data and user home directories, on POSIX-compliant storage such as Network File System (NFS) or Elastic File System (EFS) (see Shared storage for user home directories)
  • (Optional) An external load balancer to provide a consistent entry point and cluster resilience
  • A Workbench license that permits off-host execution (Advanced tier)
  • Working knowledge of Kubernetes and Helm
  • A running Kubernetes cluster and API access to it
  • kubectl, the Kubernetes command-line tool
  • Helm v3, the Kubernetes package manager
  • A PostgreSQL database
  • A StorageClass backed by POSIX-compliant PersistentVolume storage that supports symlinks and ReadWriteMany access. PersistentVolume storage backed by AWS EFS must be statically provisioned
  • At least 100 GB of shared storage (see Shared storage for user home directories)

The Kubernetes cluster must provide these requirements:

  • A Kubernetes API that is enabled and reachable from the machine that runs the Job Launcher
  • A namespace for Workbench jobs, selected with the kubernetes-namespace setting (default rstudio)
  • A service account with full API access to all endpoints and API groups in the namespace, with its token supplied to the plugin through the auth-token setting
  • (Optional) A service account that can read the node list through the API, which lets Workbench return the external IP address for a job rather than only the internal one
  • The metrics-server add-on, used by Workbench to stream job resource metrics
Note

To create the namespace and service account, see the sample script in the Kubernetes Launcher section of this guide.

User home directories

Workbench frequently interacts with user home directories. If you mount home directories with NFS, we recommend using the async mount option and a modern, high-throughput network connection that can support many simultaneous clients. In most configurations, no_root_squash is also required to be set on the system providing this NFS share. If you would like your users to be able to share their projects, see the section on Project Sharing for additional NFS requirements.

If you mount home directories with EFS, we recommend the following settings for the best performance:

  • Use the general purpose performance mode rather than Max I/O mode.
  • In most cases, you should use bursting behavior rather than provisioned throughput.
  • Mount the file system using the Amazon package efs-utils.
  • We recommend provisioning EC2 instances that are memory or compute-optimized (do not choose general purpose instances), and choose the network enhanced options, e.g., r5n.2xlarge.
  • Use CloudWatch to monitor usage and identify system performance bottlenecks.
  • Project Sharing must be disabled. For more information, see Project Sharing.
  • File locking must use the advisory type. For more information, see File locking.
Note

You might experience slower performance in certain areas as EFS is not performant when reading and writing thousands of small files. For example, installing certain R packages with a lot of C++ header files, or working with projects that require reading a large number of files.

See Recommended EFS configuration settings for more details.

Back to top

Footnotes

  1. Workbench 2024.08 includes a bugfix (vscode-server#17 in the 2024.08 release notes) for potential data leakage between users in the same browser session. The fix uses browser functionality that, until version 126.0, was not implemented in Firefox.

    VS Code sessions will otherwise function in older versions of Firefox, which is why >= 126.0 is recommended, but not required. The caveat is that older Firefox versions may generate several harmless error logs in the browser console as Workbench attempts to use the unimplemented functionality: Error accessing Indexed DB: TypeError: indexedDB.database is not a function.↩︎