pantheon-local/tools

Pantheon work, locally. Without the glue scripts.

A small CLI for the Pantheon jobs that otherwise turn into shell history: first-run diagnostics, canonical Dev checkout and sync, estate drift inspection, Multidev workflows, local data pulls, Drupal setup, and structured status. It works with DDEV or Lando without taking over either one.

Install Read the docs

DDEV + Lando · macOS + Linux + WSL/WSL2 · MIT licensed

$ pantheon-local multidev example-site.feature1 --dry-run
Pantheon multidev dry-run
Pantheon:    example-site.feature1
Provider:    lando
Git branch:  feature1
$ pantheon-local multidev example-site.feature1 --provider lando
Cloning into 'example-site-feature1'...
Created Pantheon multidev checkout
$ _
Why

Keep the workflow. Lose the machine-specific magic.

Pantheon projects tend to accumulate shell aliases, copy-pasted commands, one-off checkout directories, and local-provider assumptions. Pantheon Local Tools puts the repeatable parts behind one CLI while leaving Pantheon, Terminus, DDEV, Lando, Git, and your project configuration in charge of the things they already own.

Provider-neutralUse DDEV or Lando without rewriting the project around the tool.
Configuration-drivenChoose your root, provider, and optional Pantheon Tag routing instead of editing the script.
Fail closedAmbiguous providers, unsafe overrides, and occupied destinations stop instead of guessing.
Who it's for

For developers already doing Pantheon work.

If your day involves Terminus, Git, DDEV or Lando, and more shell history than you'd like, that's the use case. PLT gives the repeatable parts a stable command without hiding or replacing the tools underneath.

If you manage one site and already have a local workflow you like, you may not need it.

Workflow

Built around the Pantheon work you actually repeat.

Each command stays narrow: resolve the intent, protect the checkout, delegate to the right upstream tool, and leave useful local state behind.

01 / DOCTOR

Find the setup problem before a mutating workflow finds it for you.

Check Git, the checkout root, provider prerequisites, Terminus authentication, Pantheon Tag routing, canonical Dev access, and existing checkout metadata without repairing or starting anything. PASS, INFO, WARN, and FAIL results include the smallest safe next action when PLT can determine one.

Doctor diagnostics → 
$ pantheon-local doctor
$ pantheon-local doctor --format json
PASS  terminus-auth     Terminus authentication is valid

02 / CHECKOUT

Populate canonical Dev checkouts — then sync only when you ask.

Use Terminus-backed site, Tag, environment, and Git discovery to build a deterministic canonical Dev estate. Normal checkout creates only missing destinations; checkout sync is the explicit fast-forward-only update path and refuses dirty, ahead, diverged, or ambiguous local state.

Checkout and sync contract → 
$ pantheon-local checkout example-site.dev --dry-run
$ pantheon-local checkout dev --tag 'Example Group'
$ pantheon-local checkout sync example-site.dev

03 / ESTATE

See local drift beside Dev, Test, and Live code identity.

Inspect one site, all accessible sites, or configured Tag-selected subsets without changing anything. PLT joins Terminus-backed environment code identity with canonical local Git and provider state so missing, behind, ahead, diverged, dirty, or unavailable state stays explicit.

Estate status contract → 
$ pantheon-local estate status --all
$ pantheon-local estate status --tag 'Example Group'
$ pantheon-local estate status example-site --format json

04 / MULTIDEV

Clone an existing Multidev into an isolated local checkout.

Resolve the authoritative Git URL through Terminus, route the checkout through your configured root or Pantheon Tag mapping, configure DDEV or Lando locally, and refuse to overwrite an existing destination. The command never creates or deletes the remote Multidev.

Multidev behavior → 
$ pantheon-local multidev SITE.ENV --dry-run
$ pantheon-local multidev SITE.ENV --provider lando --group migration
$ pantheon-local multidev SITE.ENV --provider ddev --start

05 / PULL

Refresh the database, files, or both — without pulling code.

Use the provider already associated with the checkout and request only the data you need. Pantheon Local Tools verifies Git HEAD and tracked content before and after the provider pull, then records database and file provenance only after success.

Pull safety contract → 
$ pantheon-local pull live
$ pantheon-local pull test --database-only
$ pantheon-local pull live --files-only

06 / STATUS

Know what this checkout is before you touch it.

Run a local, read-only inspection from the checkout root or any subdirectory. See Pantheon metadata when it is recorded, the detected local provider, Git state, runtime URL when safely available, and independent database/files provenance — without contacting Pantheon or starting the provider.

Status contract → 
$ pantheon-local status
$ pantheon-local status --format json
$ pantheon-local --version
Providers

DDEV or Lando. Same intent.

The shared Pantheon and Terminus core stays provider-neutral. Provider-specific adapters handle the runtime details while preserving the project's existing .ddev/config.yaml, .lando.yml, services, add-ons, and custom tooling.

DDEVpantheon-local config set provider ddev
Landopantheon-local config set provider lando
Autopantheon-local config unset provider
Provider architecture →
Install

Free to use. Pick the install path that fits your host.

The current stable release is available through Homebrew, a signed Debian/APT repository, downloadable release artifacts, or the portable clone installer.

HomebrewmacOS
brew install zevarix/tap/pantheon-local-tools Tap →
APTDebian · Ubuntu · WSL
curl -fsSL https://raw.githubusercontent.com/zevarix/pantheon-local-tools/main/install-apt.sh | bash Manual setup →

APT stays fingerprint-verified. The bootstrap verifies the canonical public archive fingerprint before installing the dedicated Signed-By keyring/source, then runs normal APT installation. The full manual procedure remains available for users who want to inspect every trust step.

Safety

Useful automation without pretending the local machine is disposable.

The tool is intentionally conservative around code, credentials, provider configuration, and filesystem boundaries.

  • Dry-run before clone.Resolve Pantheon and local routing without creating directories or starting a provider.
  • Git code stays code.Data pulls verify HEAD and tracked content remain unchanged before recording success.
  • No token vault.Terminus and the local providers keep ownership of their supported Pantheon authentication flows.
  • No provider takeover.Local overrides are additive; unsafe changes fail instead of clobbering project configuration.
  • No guessing on ambiguity.Provider selection, checkout paths, and existing destinations must resolve safely or the command stops.
FAQ

A few things to know before you install it.

Does PLT replace Terminus, DDEV, or Lando?

No. Pantheon and Terminus remain authoritative for Pantheon operations, and DDEV or Lando still owns the local runtime. PLT coordinates their supported interfaces and adds safety checks around the workflow.

Can it create a Pantheon Multidev?

Yes, but only through the explicit pantheon-local multidev create command. The normal pantheon-local multidev SITE.ENV command remains clone-only and will not create a missing environment.

Where does it keep Pantheon credentials?

It doesn't collect or persist Pantheon machine tokens. Authentication stays with Terminus and the supported provider flows.

Will it rewrite my DDEV or Lando project configuration?

No. Project-owned provider configuration stays authoritative. PLT uses additive local overrides where it can do so safely and stops when it cannot.

Does it run on Windows?

Through WSL or WSL2 using Linux paths. Native PowerShell and Command Prompt are not part of the current supported host contract.

Repository trust

The website and signed APT repository share this endpoint.

This landing page is static. APT reads the signed metadata below directly from GitHub Pages; there is no application server or hidden package backend between the client and the published repository files.

  • InReleaseClear-signed stable repository metadata consumed by APT.
  • Archive keyringPublic OpenPGP keyring. Verify its fingerprint before trusting it.
  • PackagesPackage index for architecture-independent Debian artifacts.