infographic Usage Release Development Licence CRAN Travis minimal R version cran-checks AppVeyor rOpenSci Codecov downloads JOSS SayThanks Zenodo Project Status: Active – The project has reached a stable, usable state and is being actively developed.

The drake R package logo

Data analysis can be slow. A round of scientific computation can take several minutes, hours, or even days to complete. After it finishes, if you update your code or data, your hard-earned results may no longer be valid. How much of that valuable output can you keep, and how much do you need to update? How much runtime must you endure all over again?

For projects in R, the drake package can help. It analyzes your workflow, skips steps with up-to-date results, and orchestrates the rest with optional distributed computing. At the end, drake provides evidence that your results match the underlying code and data, which increases your ability to trust your research.

6-minute video

Visit the first page of the manual to watch a short introduction.


What gets done stays done.

Too many data science projects follow a Sisyphean loop:

  1. Launch the code.
  2. Wait while it runs.
  3. Discover an issue.
  4. Rerun from scratch.

Ordinarily, it is hard to avoid rerunning the code from scratch.


But with drake, you can automatically

  1. Launch the parts that changed since last time.
  2. Skip the rest.

How it works

To set up a project, load your packages,


load your custom functions,

create_plot <- function(data) {
  ggplot(data, aes(x = Petal.Width, fill = Species)) +

check any supporting files (optional),

# Get the files with drake_example("main").
#> [1] TRUE
#> [1] TRUE

and plan what you are going to do.

plan <- drake_plan(
  raw_data = readxl::read_excel(file_in("raw_data.xlsx")),
  data = raw_data %>%
    mutate(Species = forcats::fct_inorder(Species)),
  hist = create_plot(data),
  fit = lm(Sepal.Width ~ Petal.Width + Species, data),
  report = rmarkdown::render(
    output_file = file_out("report.html"),
    quiet = TRUE
#> # A tibble: 5 x 2
#>   target   command                                                         
#>   <chr>    <expr>                                                          
#> 1 raw_data readxl::read_excel(file_in("raw_data.xlsx"))                   …
#> 2 data     raw_data %>% mutate(Species = forcats::fct_inorder(Species))   …
#> 3 hist     create_plot(data)                                              …
#> 4 fit      lm(Sepal.Width ~ Petal.Width + Species, data)                  …
#> 5 report   rmarkdown::render(knitr_in("report.Rmd"), output_file = file_ou…

So far, we have just been setting the stage. Use make() to do the real work. Targets are built in the correct order regardless of the row order of plan.

#> target raw_data
#> target data
#> target fit
#> target hist
#> target report

Except for files like report.html, your output is stored in a hidden .drake/ folder. Reading it back is easy.

readd(data) # See also loadd().
#> # A tibble: 150 x 5
#>    Sepal.Length Sepal.Width Petal.Length Petal.Width Species
#>           <dbl>       <dbl>        <dbl>       <dbl> <fct>  
#>  1          5.1         3.5          1.4         0.2 setosa 
#>  2          4.9         3            1.4         0.2 setosa 
#>  3          4.7         3.2          1.3         0.2 setosa 
#>  4          4.6         3.1          1.5         0.2 setosa 
#>  5          5           3.6          1.4         0.2 setosa 
#>  6          5.4         3.9          1.7         0.4 setosa 
#>  7          4.6         3.4          1.4         0.3 setosa 
#>  8          5           3.4          1.5         0.2 setosa 
#>  9          4.4         2.9          1.4         0.2 setosa 
#> 10          4.9         3.1          1.5         0.1 setosa 
#> # … with 140 more rows

You may look back on your work and see room for improvement, but it’s all good! The whole point of drake is to help you go back and change things quickly and painlessly. For example, we forgot to give our histogram a bin width.

#> `stat_bin()` using `bins = 30`. Pick better value with `binwidth`.

So let’s fix the plotting function.

create_plot <- function(data) {
  ggplot(data, aes(x = Petal.Width, fill = Species)) +
    geom_histogram(binwidth = 0.25) +

drake knows which results are affected.

config <- drake_config(plan)
vis_drake_graph(config) # Interactive graph: zoom, drag, etc.


The next make() just builds hist and report.html. No point in wasting time on the data or model.

#> target hist
#> target report

Reproducibility with confidence

The R community emphasizes reproducibility. Traditional themes include scientific replicability, literate programming with knitr, and version control with git. But internal consistency is important too. Reproducibility carries the promise that your output matches the code and data you say you used. With the exception of non-default triggers and hasty mode, drake strives to keep this promise.


Suppose you are reviewing someone else’s data analysis project for reproducibility. You scrutinize it carefully, checking that the datasets are available and the documentation is thorough. But could you re-create the results without the help of the original author? With drake, it is quick and easy to find out.

#> Unloading targets from environment:
#>   hist
#> All targets are already up to date.

config <- drake_config(plan)
#> character(0)

With everything already up to date, you have tangible evidence of reproducibility. Even though you did not re-create the results, you know the results are re-creatable. They faithfully show what the code is producing. Given the right package environment and system configuration, you have everything you need to reproduce all the output by yourself.


When it comes time to actually rerun the entire project, you have much more confidence. Starting over from scratch is trivially easy.

clean()    # Remove the original author's results.
make(plan) # Independently re-create the results from the code and input data.
#> target raw_data
#> target data
#> target fit
#> target hist
#> target report

Big data efficiency

Select specialized data formats to increase speed and reduce memory consumption. In version and above, the available formats are "fst" for data frames (example below) and "keras" for Keras models (example here).

```{r, eval = FALSE} library(drake) n <- 1e8 # Each target is 1.6 GB in memory. plan <- drake_plan( data_fst = target( data.frame(x = runif(n), y = runif(n)), format = "fst" ), data_old = data.frame(x = runif(n), y = runif(n)) ) make(plan)

> target data_fst

> target data_old

build_times(type = "build")

> # A tibble: 2 x 4

> target elapsed user system


> 1 data_fst 13.93s 37.562s 7.954s

> 2 data_old 184s (~3.07 minutes) 177s (~2.95 minutes) 4.157s

## History and provenance

As of version 7.5.2, `drake` tracks the history and provenance of your
targets: what you built, when you built it, how you built it, the
arguments you used in your function calls, and how to get the data back.
(Disable with `make(history = FALSE)`)

``` r
history <- drake_history(analyze = TRUE)
#> # A tibble: 12 x 10
#>    target current built exists hash  command   seed  runtime quiet
#>    <chr>  <lgl>   <chr> <lgl>  <chr> <chr>    <int>    <dbl> <lgl>
#>  1 data   TRUE    2019… TRUE   e580… raw_da… 1.29e9 0.002    NA   
#>  2 data   TRUE    2019… TRUE   e580… raw_da… 1.29e9 0.001    NA   
#>  3 fit    TRUE    2019… TRUE   62a1… lm(Sep… 1.11e9 0.003    NA   
#>  4 fit    TRUE    2019… TRUE   62a1… lm(Sep… 1.11e9 0.001000 NA   
#>  5 hist   FALSE   2019… TRUE   10bc… create… 2.10e8 0.006    NA   
#>  6 hist   TRUE    2019… TRUE   00fa… create… 2.10e8 0.004    NA   
#>  7 hist   TRUE    2019… TRUE   00fa… create… 2.10e8 0.00600  NA   
#>  8 raw_d… TRUE    2019… TRUE   6317… "readx… 1.20e9 0.01     NA   
#>  9 raw_d… TRUE    2019… TRUE   6317… "readx… 1.20e9 0.00500  NA   
#> 10 report TRUE    2019… TRUE   1f41… "rmark… 1.30e9 0.484    TRUE 
#> 11 report TRUE    2019… TRUE   1f41… "rmark… 1.30e9 0.39     TRUE 
#> 12 report TRUE    2019… TRUE   1f41… "rmark… 1.30e9 0.357    TRUE 
#> # … with 1 more variable: output_file <chr>


Let’s use the history to recover the oldest histogram.

hash <- history %>%
  filter(target == "hist") %>%
  pull(hash) %>%
  head(n = 1)
cache <- drake_cache()
#> `stat_bin()` using `bins = 30`. Pick better value with `binwidth`.

Reproducible data recovery and renaming

Remember how we made that change to our histogram? What if we want to change it back? If we revert create_plot(), make(plan, recover = TRUE) restores the original plot.

create_plot <- function(data) {
  ggplot(data, aes(x = Petal.Width, fill = Species)) +

# The report still needs to run in order to restore report.html.
make(plan, recover = TRUE)
#> recover hist
#> target report

readd(hist) # old histogram
#> `stat_bin()` using `bins = 30`. Pick better value with `binwidth`.

drake’s data recovery feature is another way to avoid rerunning commands. It is useful if:

In version 7.5.2 and above, make(recover = TRUE) can salvage the values of old targets. Before building a target, drake checks if you have ever built something else with the same command, dependencies, seed, etc. that you have right now. If appropriate, drake assigns the old value to the new target instead of rerunning the command.


  1. This feature is still experimental.
  2. Recovery may not be a good idea if your external dependencies have changed a lot over time (R version, package environment, etc.).

Undoing clean()

# Is the data really gone?

# Nope! You need clean(garbage_collection = TRUE) to delete stuff.
make(plan, recover = TRUE)
#> recover raw_data
#> recover data
#> recover fit
#> recover hist
#> recover report

# When was the raw data *really* first built?
#> [1] "2019-07-24 20:58:22.465591 -0400 GMT"


You can use recovery to rename a target. The trick is to supply the random number generator seed that drake used with the old target name. Also, renaming a target unavoidably invalidates downstream targets.

# Get the old seed.
old_seed <- diagnose(data)$seed

# Now rename the data and supply the old seed.
plan <- drake_plan(
  raw_data = readxl::read_excel(file_in("raw_data.xlsx")),

  # Previously just named "data".
  iris_data = target(
    raw_data %>%
      mutate(Species = forcats::fct_inorder(Species)),
    seed = !!old_seed

  # `iris_data` will be recovered from `data`,
  # but `hist` and `fit` have changed commands,
  # so they will build from scratch.
  hist = create_plot(iris_data),
  fit = lm(Sepal.Width ~ Petal.Width + Species, iris_data),
  report = rmarkdown::render(
    output_file = file_out("report.html"),
    quiet = TRUE

make(plan, recover = TRUE)
#> recover iris_data
#> target fit
#> target hist
#> target report

Independent replication

With even more evidence and confidence, you can invest the time to independently replicate the original code base if necessary. Up until this point, you relied on basic drake functions such as make(), so you may not have needed to peek at any substantive author-defined code in advance. In that case, you can stay usefully ignorant as you reimplement the original author’s methodology. In other words, drake could potentially improve the integrity of independent replication.

Readability and transparency

Ideally, independent observers should be able to read your code and understand it. drake helps in several ways.

Scale up and out.

Not every project can complete in a single R session on your laptop. Some projects need more speed or computing power. Some require a few local processor cores, and some need large high-performance computing systems. But parallel computing is hard. Your tables and figures depend on your analysis results, and your analyses depend on your datasets, so some tasks must finish before others even begin. drake knows what to do. Parallelism is implicit and automatic. See the high-performance computing guide for all the details.

# Use the spare cores on your local machine.
make(plan, jobs = 4)

# Or scale up to a supercomputer.
drake_hpc_template_file("slurm_clustermq.tmpl") #
  clustermq.scheduler = "clustermq",
  clustermq.template = "slurm_clustermq.tmpl"
make(plan, parallelism = "clustermq", jobs = 4)


You can choose among different versions of drake. The CRAN release often lags behind the online manual but may have fewer bugs.

# Install the latest stable release from CRAN.

# Alternatively, install the development version from GitHub.

Function reference

The reference section lists all the available functions. Here are the most important ones.


Use cases

The official rOpenSci use cases and associated discussion threads describe applications of drake in action. Here are some more applications of drake in real-world projects.

Help and troubleshooting

The following resources document many known issues and challenges.

If you are still having trouble, please submit a new issue with a bug report or feature request, along with a minimal reproducible example where appropriate.

The GitHub issue tracker is mainly intended for bug reports and feature requests. While questions about usage etc. are also highly encouraged, you may alternatively wish to post to Stack Overflow and use the drake-r-package tag.


Development is a community effort, and we encourage participation. Please read for details.

Similar work

drake enhances reproducibility and high-performance computing, but not in all respects. Literate programming, local library managers, containerization, and strict session managers offer more robust solutions in their respective domains. And for the problems drake does solve, it stands on the shoulders of the giants that came before.

Pipeline tools

GNU Make

The original idea of a time-saving reproducible build system extends back at least as far as GNU Make, which still aids the work of data scientists as well as the original user base of complied language programmers. In fact, the name “drake” stands for “Data Frames in R for Make”. Make is used widely in reproducible research. Below are some examples from Karl Broman’s website.

Whereas GNU Make is language-agnostic, drake is fundamentally designed for R.


remake itself is no longer maintained, but its founding design goals and principles live on through drake. In fact, drake is a direct reimagining of remake with enhanced scalability, reproducibility, high-performance computing, visualization, and documentation.

Factual’s Drake

Factual’s Drake is similar in concept, but the development effort is completely unrelated to the drake R package.

Other pipeline tools

There are countless other successful pipeline toolkits. The drake package distinguishes itself with its R-focused approach, Tidyverse-friendly interface, and a thorough selection of parallel computing technologies and scheduling algorithms.


Memoization is the strategic caching of the return values of functions. It is a lightweight approach to the core problem that drake and other pipeline tools are trying to solve. Every time a memoized function is called with a new set of arguments, the return value is saved for future use. Later, whenever the same function is called with the same arguments, the previous return value is salvaged, and the function call is skipped to save time. The memoise package is the primary implementation of memoization in R.

Memoization saves time for small projects, but it arguably does not go far enough for large reproducible pipelines. In reality, the return value of a function depends not only on the function body and the arguments, but also on any nested functions and global variables, the dependencies of those dependencies, and so on upstream. drake tracks this deeper context, while memoise does not.

Literate programming

Literate programming is the practice of narrating code in plain vernacular. The goal is to communicate the research process clearly, transparently, and reproducibly. Whereas commented code is still mostly code, literate knitr / R Markdown reports can become websites, presentation slides, lecture notes, serious scientific manuscripts, and even books.

knitr and R Markdown

drake and knitr are symbiotic. drake’s job is to manage large computation and orchestrate the demanding tasks of a complex data analysis pipeline. knitr’s job is to communicate those expensive results after drake computes them. knitr / R Markdown reports are small pieces of an overarching drake pipeline. They should focus on communication, and they should do as little computation as possible.

To insert a knitr report in a drake pipeline, use the knitr_in() function inside your drake plan, and use loadd() and readd() to refer to targets in the report itself. See an example here.

Version control

drake is not a version control tool. However, it is fully compatible with git, svn, and similar software. In fact, it is good practice to use git alongside drake for reproducible workflows.

However, data poses a challenge. The datasets created by make() can get large and numerous, and it is not recommended to put the .drake/ cache or the .drake_history/ logs under version control. Instead, it is recommended to use a data storage solution such as DropBox or OSF.

Containerization and R package environments

drake does not track R packages or system dependencies for changes. Instead, it defers to tools like Docker, Singularity, renv, and packrat, which create self-contained portable environments to reproducibly isolate and ship data analysis projects. drake is fully compatible with these tools.


The workflowr package is a project manager that focuses on literate programming, sharing over the web, file organization, and version control. Its brand of reproducibility is all about transparency, communication, and discoverability. For an example of workflowr and drake working together, see this machine learning project by Patrick Schratz.


Special thanks to Jarad Niemi, my advisor from graduate school, for first introducing me to the idea of Makefiles for research. He originally set me down the path that led to drake.

Many thanks to Julia Lowndes, Ben Marwick, and Peter Slaughter for reviewing drake for rOpenSci, and to Maëlle Salmon for such active involvement as the editor. Thanks also to the following people for contributing early in development.

Credit for images is attributed here.


wlandau-lilly/drake documentation built on Aug. 23, 2019, 1:29 p.m.