Run RStudio IDE locally, but R session in Docker image


I know about the rocker RStudio docker containers and that I could connect to RStudio by using a browser, but I would like to have one local RStudio IDE installation but use R in a docker image instead of the local R. It just seems to be a waste of space to have RStudio installed in each docker image.

Or in other words: Can I specify the R executable to be used in RStudio?

Is this possible?



1 Like

RStudio needs the path to an R installation living on the local filesystem, so as far as I know there's no way to connect RStudio to R within a Docker image. It might be possible to accomplish this is the Docker container's filesystem could be mounted on the host's filesystem somewhere, but I'm not sure if this is possible.

1 Like

Hm. It would be a very useful feature to be able to use an R session in a docker container from RStudio.


Hi Rainer,

Any luck on this?

You might be able to use the rmote package for this! You'd start RStudio as normal with a local R installation, but then you connect to the remote (or dockerised) R instance using the package's commands. The downsides are that:

(a) Rmote sends figures and such back via a web browser; I don't think you'd get them in the RStudio plot viewer.
(b) You lose a lot of the advantages of RStudio; you might as well just run R on its own locally unless you're doing stuff like authoring Markdown in RStudio (and I don't think you could run the chunks on the remote instance automatically).

If you're using a Docker instance to run R and want interactivity, a better route might be to get a Docker container that has RStudio Server instead of running RStudio locally.


Just a thought - docker does have layer re-use to optimize storage in images, at least. In this sense, there is no real storage downside of having rstudio in your images (i.e. you are only storing it once). However, if you are using docker save (yuck!) or something like that, then you are not taking advantage of docker layers.

One big idea of docker is to have ephemeral containers and replaceable images, so that you need not worry about creating lots of images / containers / etc. If storage is your only consideration, then hopefully you should be ok. If there are other things you are concerned about, it may be worth having a wider discussion (new topic) about your general docker architecture / workflow.

1 Like