Installing packages

Published

September 30, 2026

Since 2026-09-28, bioconductor.org is served by the new stack: a Cloudflare Worker in front of a copy of the full repository in R2 (see the overview for the design). There is nothing to change on your side. BiocManager::install() reads the same URLs it always has, and gets the same packages, tarballs and checksums, because the new stack still copies the legacy build output from master.bioconductor.org hourly, and a weekly job checksums R2 against that local copy.

BiocManager::install("GEOquery")

Checked on the day of the switch: BiocManager::install() against bioconductor.org passes for release (3.23) and devel (3.24), from reading config.yaml through PACKAGES to installing and loading a package.

Is my install coming from the new stack?

Any response from bioconductor.org now carries server: cloudflare and no via: … cloudfront header:

curl -sI https://bioconductor.org/packages/release/bioc/src/contrib/PACKAGES | grep -i -e '^server' -e '^via'

What to expect

  • Same URLs, same content. Landing pages, vignettes, archives and old releases all live at the addresses they always had. Two exceptions: /talks/ pages return 404 (ADR 0013), and site search (/solr) is not served.
  • Smaller downloads. Everything is compressed, including the repository indexes R reads on every install: PACKAGES goes over the wire at about a quarter of its size.
  • Package updates appear within about an hour of being published, as before. “Published” means built by the Bioconductor Build System (BBS) and propagated to master.bioconductor.org, not pushed to git.bioconductor.org. A URL requested just before a file appears can 404 for up to ten minutes more (see edge cache).

Reporting problems

An install that fails, a checksum mismatch, a slow or missing file, a page that renders wrong: all worth reporting, however small. Use one of the bioc-infrastructure issue forms, package install problem or something’s broken on bioconductor.org, with the R output and, if possible, the failing URL. Reports are triaged by hand and moved to the repo that owns the problem (how reporting works). You can also email Sean Davis (seandavi@gmail.com).