# Install | DRE

> Install DRE with the install script, Homebrew, Scoop, pip or cargo.

You're reading the docs for DRE 0.4 (v0.4.4). [This page for 0.5](https://getdre.com/docs/install/) · [New in 0.5](https://getdre.com/docs/new-in-0.5/)

# Install

macOS and Linux (x86\_64 and ARM):

```bash
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):

```bash
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](https://github.com/get-dre/dre/releases) and put `dre.exe` on your `PATH`.

## With Homebrew or Scoop

From 0.1.0 on:

```bash
brew install get-dre/tap/dre                                   # macOS and Linux
```

```powershell
scoop bucket add get-dre https://github.com/get-dre/scoop-bucket   # Windows
scoop install get-dre/dre
```

## With pip

The `dre-cli` package holds `dre` (Linux x86\_64 and aarch64, macOS, Windows; Python 3.8+):

```bash
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.

## With cargo

```bash
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`.

## Verifying a download

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](https://cli.github.com):
    
    ```bash
    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.

## Check the installed command

```bash
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](https://github.com/get-dre/dre/blob/v0.4.4/examples/tutorial/) 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](https://getdre.com/docs/v0.4/cli-reference/), [getting started](https://getdre.com/docs/v0.4/getting-started/), [plugin packages](https://getdre.com/docs/v0.4/glossary/#plugin-package) and [profiles](https://getdre.com/docs/v0.4/glossary/#profile).

[Previous  
Glossary](https://getdre.com/docs/v0.4/glossary/)[Next  
Lookups](https://getdre.com/docs/v0.4/lookups/)