I'm afraid I do not. But I do know that this would mean 20-30 R sessions. So you could fire up 20-30 R session in terminal windows and see if it burns into a heap 
Hey @mara, sorry to summons you from your genie bottle, but do you know who at your shop could give some sense of minimum hardware for 20 connection on RStudio Server?
@mara not so much when we are talking about specs for a laptop, as opposed to running in the cloud. But without approximately 1GB per session, compiling packages may not go too well. I'd probably buy an Intel Skull Canyon NUC, max it out with 32 GB of RAM, then run RStudio Server on it with perhaps a full sync of CRAN.
But for an "official" recommendation of "minimum hardware", I would check with the IDE team.
@benmarwick has some very relevant experience on teaching R in very challenging environments:
http://blog.revolutionanalytics.com/2015/04/r-in-myanmar.html
https://software-carpentry.org/blog/2015/03/teaching-in-yangon.html
If you put RStudio Server on a laptop or box and have people connect to it via a router, the good news is that you can compile and install packages like tidyverse to a common library ahead of the workshop, and then users would just need to load them on the day.
That might not be ideal if you want to actually show people how to use install.packages, but I think it's fair to say that compiling and installing tidyverse is probably going to be biggest RAM/CPU bottleneck for 30 simultaneous users, especially since it'll be the first thing they need to do. This way you get to skip that pain.
I think the best solution is to have bootable ubuntu usb sticks with docker images of R and tidyverse. I'd try to make everything as plug 'n' play as possible, so the focus is on R and TidyVerse 
As Jenny noted, I've run several Carpentry-style R workshops for complete novices in low-bandwidth throughout in Southeast Asia (including the one in Yangon I wrote about). I have a few opinions about working with complete novices in offline conditions based on these experiences.
I've found the quickest and easiest way to get people doing things in RStudio is to pass around a dozen USB sticks with full R & RStudio installers and a folder of R package binaries (Win and OSX). The learners copy the whole USB folder to their desktop. We install R and RStudio first. Then we open the previously-prepared RStudio project file among the files from the USB, double-click on that to start RStudio, and then don't have to worry about paths when we run the code to install pkgs.
Prior to the workshop, I prepare the R package binaries using miniCRAN, which ensures that we get all the dependent packages also, which is fantastic. It works pretty good during the workshops, but is not 100% perfect, and for the odd cases where the miniCRAN install of packages didn't get them all, I can usually take library folders from my computer (grabbing them from the location indicated by .libPaths()) and copy-pasted them onto the learner's computer.
This general approach has proven pretty robust to a wide range of old, slow hardware, and learners who rarely use computers, as well as being quick to prepare and implement (so we have more time to learn R), and very cheap. I've often thought about the router/server method suggested by @rensa, but I don't use that much myself and I'd worry that the time I'd spend preparing, setting up, giving instructions and troubleshooting would be another potential distraction from getting learners using R. But I'd love to read someone else's success story teaching R offline with a local server 
I guess that we share the general goal when working with complete novices of getting people started using R such that they can continue using and learning by themselves in the future. To be effective at this we need to place R and RStudio as close as possible to the novice's familiar contexts. My opinion is that the quicker and easier we can make it for the learner to go from turning on their computer to doing things in RStudio (i.e. a desktop shortcut to a local install), the higher our chances of cultivating a productive, long-term R-user. So that's what motivates my approach.
If this is truly a workshop for complete novices, as you say, then my opinion is that including Ubuntu and Docker in the solution to the no-internet problem is not ideal. I can imagine it could cause confusion, wasted time, and distraction from the main goal of getting people started with using R & RStudio. From the point of view of a complete novice, Docker is a bunch of unfamiliar concepts and magical command line interactions, and Ubuntu is a strange new desktop environment that will slow people down as they try to navigate around it. The learners will ask questions about these things, and you can't just waive them off and say 'don't worry these things aren't important' because you'll lose their trust and attention ("why is he getting us to do things that aren't important?"). That adds up to a lot of time explaining things that are not R, and that, in my opinion, most complete novice R users will probably do better without. So I'd avoid those if time is limited.
Anyway, good luck, and please do report back on what worked for you! My experiences may not generalize very well, and I'd love to know of other solutions to this problem.
@benmarwick, thanks for sharing your experience in SE Asia. I can definitely see the value in sharing install files via USB, and your tip to open from a prepared RStudio project file will save a lot of pain, I think.
I tried creating a bootable USB with Ubuntu, but I had mixed success. I'm exploring the RStudio laptop server + router as an alternative. @rensa, it makes sense to install packages we'll use in a common library. Thanks. @josh, thanks for the hardware suggestion. If we don't need everyone to be compiling packages, do you think something more modest would get us through? We'll only ask folks to load a few packages (from a common library) + a small dataset (1000x50ish), tidy the data, make a few plots and tables, and run few regressions.
If you are not compiling packages, you likely would be able to budget less memory per session.
But even if you said 512 MB per session, 30 sessions means 16 GB of RAM (leaving a little bit for the OS, so it would be tight).
also potentially (for Windows):
# Before workshop
.libPaths("C:/Users/Documents/toDelete") # Point to an empty directory where you will install packages to (these can be deleted later, this ensures package dependencies are installed even if you have them in your usual library)
binariesLocation <- "E:/binaries" # Point to another empty directory
packagesWanted <- c("docker", "purrr") # Vector of packages desired
install.packages(packagesWanted, destdir = binariesLocation , type="binary") # Install packages and depencies, downloaded packages and dependencies will go to the directory you assigned to "binariesLocation"
# Be sure to reset your R session to reset your .libPaths before continuing on any more work
# At Workshop
usbLocation <- 'E:/binaries' # set to binaries folder on usb
packagesToInstall <- list.files(usbLocation, full.names = TRUE)
install.packages(packagesToInstall, repos = NULL, type = "binary")