[This article was first published on data-in-flight, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)Want to share your content on R-bloggers? click here if you have a blog, or here if you don't. maestro has officially graduated to stable release with version 1.0.0 back in January 2026 and now its latest version 1.1.0. This marks a commitment to maintaining a stable API and increased reliance on using maestro in production. In our environment alone, maestro has orchestrated millions of pipeline executions over the course of a year, effectively making it the heartbeat of our entire data stack.1If you haven’t heard of maestro, it’s a pipeline orchestration package. You can learn more about it here.Get it from CRAN:install.packages("maestro")Here are some of the key new features and changes that came out of versions 1.0.0 and 1.1.0:Faster schedule build and run timesA lot of effort went into improving the performance of core functions build_schedule and run_schedule. Building is especially more efficient, at around 2x-4x quicker for projects with a decent number of pipelines. For example, our heaviest maestro project which boasts over 50 pipelines saw an average build time of 2 secs go down to 0.5 secs. This makes running maestro at tight orchestrator frequencies more feasible.Schedules are more portableOne problem with the old way maestro built schedules was that caching and reusing a schedule object (as opposed to rebuilding it every time) eventually led to schedule expiry2. As of maestro 1.1.0, schedules can safely be cached and reused avoiding the need to run build_schedule on every orchestrator run. It’s as simple as running saveRDS on a prebuilt schedule and then using readRDS to load it into the production run.Caveats when caching a scheduleIt’s important to note that caching a schedule won’t pick up changes to pipeline configuration or the addition/deletion of pipelines. Therefore, it’s recommended to rebuild and cache once on deploy, then use the prebuilt schedule on each execution. A CI/CD pattern is useful to ensure that changes to pipeline configuration trigger the rebuild of a schedule.Caching a schedule as an .rds instead of rebuilding on every run can shave off a second of runtime in production, which is significant if maestro is used on a tight cadence. For projects running on a lower frequency (e.g., 15 minutes or less often), this probably isn’t worth doing.New function get_run_sequenceIt’s often useful to know the future times your pipelines are scheduled to run. To this end, we added the get_run_sequence function which returns a data.frame of scheduled execution times. This can be helpful for planning and monitoring:#' ./pipelines#' @maestroFrequency hourlyhourly