When you say packrat bundle, I will presume you are talking about the result of packrat::bundle().
The important thing to note about this function is that it has a lot of arguments. As a result, what your bundle will look like will depend on your selection of arguments.
To answer your bigger question, though, packrat is definitely a great solution for portability and reproducibility of projects across different operating systems. I have experience using packrat to reproduce the same project on Windows and on Linux.
An important caveat to be aware of, though, packrat manages several different things. It will be profitable to have a good understanding of what these are so that you can understand what is happening.
- the version of packages you have in your project. This is incredibly necessary and is stored in the
packrat/packrat.lock file
- the options you have selected for packrat's behavior. This is stored in the
packrat/packrat.opts file
- an "auto-executable" in your project. Typically stored in
.Rprofile. This automatically initializes packrat when the project is opened
- the package sources. These are stored on CRAN as well, so no worries if you lose this part of the repository. Typically stored at
packrat/src. This is the operating-system agnostic source code for packages.
- package binaries. These are compiled for each operating system and are stored in sub-directories like
packrat/lib.
All you really need to make your project reproducible on another operating system is packrat.lock. If you have this file, a student can run packrat::restore() to download package source files from CRAN and then build the packages on her own computer.
However, packrat.opts can be useful, and packrat::bundle() has options for including the other items. Including the sources in your bundle (the default) will save students the time of downloading source files from CRAN when loading up the project. Up until this point, though, all of the options I have mentioned require the student being able to build packages from source. This requires things like a C++ compiler, but I think RStudio includes most of these tools in modern versions.
To avoid building packages from source, the only option you really have in packrat world is packrat::bundle(include.lib=TRUE). To avoid building packages from source, the important caveat here will be that you and the students all have the same operating system. You will build binaries before bundling, and then include the binaries in the bundle. If the student has the same type of operating system, they should be able to open the bundle and use the binaries.
Hopefully that is a helpful overview 
I generally prefer to track packrat.lock and packrat.opts in version control (git) and exclude all of the other folders (lib, src, etc.) from version control. That typically gives me what I need to reproduce the project on another computer (even w/ another OS) using packrat::restore(). However, packrat::bundle() is certainly a valid approach! I would recommend testing with a clean computer analogous to a student's (maybe a new AWS VM... it starts w/ a free tier to save $$) so you can get a sense for which workflow is best.
I am curious to hear how it goes, though!
Helpful if you ever want to rebuild your image with some semblance of similarity. I have to admit that I'm unfamiliar with the R wrapper around docker, though.