Skip to content
You're reading the docs for DRE 0.4 (v0.4.4). This page for 0.5 · New in 0.5

Install

macOS and Linux (x86_64 and ARM):

Terminal window
curl -fsSL https://getdre.com/install.sh | sh

This puts dre in ~/.local/bin, after checking the download against the release’s SHA256SUMS. DRE_INSTALL_DIR picks another folder and DRE_VERSION a release (default: the newest, pre-releases included):

Terminal window
curl -fsSL https://getdre.com/install.sh | DRE_VERSION=v0.3.2 DRE_INSTALL_DIR=/usr/local/bin sh

The same line works in a Databricks job (a cluster init script or a %sh cell), a CI runner or a container build. On Windows, download dre-<version>-windows-x86_64.zip (or -aarch64.zip) from Releases and put dre.exe on your PATH.

From 0.1.0 on:

Terminal window
brew install get-dre/tap/dre # macOS and Linux
Terminal window
scoop bucket add get-dre https://github.com/get-dre/scoop-bucket # Windows
scoop install get-dre/dre

The dre-cli package holds dre (Linux x86_64 and aarch64, macOS, Windows; Python 3.8+):

Terminal window
pip install dre-cli # or: uv tool install dre-cli
dre --version

Each release attaches the wheels (dre_cli-*.whl), which install the same way with pip install <wheel URL> before the version reaches PyPI. From Python, dre_cli.run(["run", "-s", "daily"]) runs dre and returns the finished process. In a Databricks job (serverless included), add dre-cli to the job’s environment dependencies and run dre from a script or notebook.

Terminal window
cargo install dre-cli --locked # builds `dre` from crates.io

A pre-release installs only when named: cargo install dre-cli --locked --version 0.2.0-rc.1.

Every DRE and plugin release, from 0.4.0, publishes three things next to each archive and wheel:

  • SHA256SUMS: checksums. They catch a corrupted download, and dre.lock pins plugins by them. They don’t prove where a file came from: whoever could change a release could change the checksums too.

  • Signed build provenance, a GitHub artifact attestation signed through Sigstore. It ties the file’s digest to the repository, the tag, the commit and the workflow that built it. Check it with the GitHub CLI:

    Terminal window
    gh attestation verify dre-0.4.1-linux-x86_64.tar.gz \
    --repo get-dre/dre \
    --signer-workflow get-dre/dre/.github/workflows/release.yml

    This requires signed provenance from the official repository’s release workflow and a matching file digest. It fails if the file was changed, or its attestation comes from a different repository or workflow. It establishes origin, not that the code is free of bugs or that the trusted release workflow could never be compromised. Wheels on PyPI also carry PyPI’s own attestations.

  • An SBOM (<archive>.cdx.json, CycloneDX): every component in the file, Rust crates and Go modules included, for your vulnerability scanner. The SBOMs are attested too.

install.sh, dre system update and plugin installs check the checksums; they don’t check attestations yet.

These checks identify official releases; they impose no restriction on building or running modified DRE. A fork that publishes its own attestations can use its own repository and release workflow in the command above. Local builds do not need an attestation, and the license is unchanged.

Terminal window
dre --version
dre --help
dre new my_reports --profile warehouse --type duckdb

--profile chooses the starter project’s default connection name; --type declares its source plugin. dre new does not create credentials: run dre init to configure a connection first, or use the complete tutorial example with its local profile. --source remains an older alias for --type; prefer the current spelling. --help prints available commands; dre <command> --help prints that command’s flags and defaults.

If the shell says command not found: dre, put the install directory on PATH and open a new shell. After a pip install, check the command using the same Python environment in which the package was installed. project-file-missing means installation worked but the command ran outside a project; cd to its root or pass --project-dir. See CLI reference, getting started, plugin packages and profiles.