figshare might be an option. You may need to split the data into chunks and provide a download script, as in this example (6GB of compressed data split into chunks), though their individual accession size limits may have increased since then.

I get the point of using a Docker image is for reproducibility, but the key selling point of Docker is it's modularity! It seems slightly blasphemous to put everything onto a Docker image. Why not just a VM image if you're going to make an offline reproducibility archive of multi-gigabytes?

Instead I would give some serious thought to what genomax said, which is to have a Docker image which automates the process of downloading, decompressing, etc, all the raw public data and turning that into the final result instead. This way, your Docker image would be tiny, you don't have issues with the Docker data and the public data falling out-of-sync if there are ever corrections needed (as a general rule of thumb, there should only be 1 place to download the data from). And of course, you can update your Docker image of 100Mb much easier than updating your Docker image of 100Gb to fix a typo in a script.

As an aside, it seems to be a very popular these days when met with the question of "how can I reproduce this in 10 years time?" people think of the future as being some cataclysmic hellscape where nothing works anymore. Some poor future Bioinformatician slumped over a green and black cathode-ray monitor mumbling about "the wisdom of the ancients" while his buddies peddle bicycles to generate power. All to reproduce the RNA-Seq findings for some 10-year-old study.

As someone typing this while playing Pokemon Red via Gameboy emulator on his phone, i'd say the chances of bad code still working in 10 years from now is fairly high, so long as the code was fairly popular at the time :)

Storage of very large Docker images is potentially a bit of an issue. As Devon suggested you can check into Quay.io, but I don't know if they have any file size restrictions. In practice downloading a large single file can be a bit of a problem. You might consider separating the data storage from the docker image itself that replicates the code aspects and software. Then you could put the Docker image anywhere Quay.io or just Docker Hub) and store all of the data in a public Amazon S3 bucket (or another cloud storage system with a nice API). The Docker Image could have code for pulling the data from AWS

Here are a few options that come to my mind:

• Host the data on a public repository, for example synapse, which has been created for this exact purpose. You can keep the data private during the publication, and then release it afterwards. Hosting is free of charge.

• As previously noted, the docker image should be small. In the docker image, download the data from synapse or wherever you host the data, and pull the code from github or bitbucket

• if you really need to host large datasets, bitbucket has no space limits (although large repositories may incur into limits)

• I remember some bioinformatics-related journals advertising that they didn't have limits for the size of supplementary materials posted. This is to encourage people to upload all the relevant data and facilitate reproducibility. However right now I don't remember the name of the journals using this policy. Sorry :-)