dd_pantheon: Terminus Cockpit

By Jared Lyvers, ldnddev — September 2, 2026

Why Terminus still lives in a sticky note

Agency work on Pantheon is a handful of CLIs you already trust: Terminus for the platform, Lando for the local stack, git for the push. The dashboard is fine for a screenshot. The real day is a sequence of commands you have run a hundred times and still have to get right on live. Which env? Did we backup first? Is this git-mode or env:deploy? Did someone type --yes because the last prompt was annoying?

That is how live gets wiped at 4:40 p.m. Not because the team is careless. Because the command is in your head, the site name is in a Slack thread, and the confirm is a single letter. Terminus can do everything the dashboard can do. That is the point, and the risk. Lando’s Pantheon recipe is the same story locally: pull overwrites the database, push can send a dump the other way, and the recipe exists because Pantheon is not “just Docker.”

dd_pantheon is a terminal cockpit for those sites. It never calls the Pantheon HTTP API. Every action is a terminus, lando, or git command you can read in preview before anything is spawned. Safety badges tell you whether it is read-only, mutating, destructive, or LiveGate. Live deploy asks you to type live. A Lando database push asks you to type database. y is a character, not a confirm.

If you deploy Drupal and WordPress on Pantheon for a living, this is the daily loop — and a way to learn Terminus because the argv is always on screen. Clone it, run --demo first, then log in and keep watching the preview.

What dd_pantheon actually is

It is a Ratatui TUI. One binary. No server, no Pantheon SDK in the hot path. The product is the plan: a redacted shell line, a cwd, a why, and a badge. Inventory can auto-run so the tree fills. Mutating work waits for Enter in preview. Destructive work adds a confirm that repeats argv, target, and why. LiveGate is a typed word. The runner injects --yes only after that TUI confirm. There is no silent yes.

The chrome is the same family as our other tools: three-line header, one-line footer that always starts with F1 Help, quit is Ctrl+Q only. Bare q does not quit. F2 is theme. F3 is doctor — tool paths, versions, whoami, catalog count. F4 cycles layouts (classic stack, three-column, tabbed inspector) and saves the choice. Tab moves tree → inspector → preview → log.

Start in demo. dd_pantheon --demo loads three dummy sites, fake metrics, and a staged backup plan. It never spawns your user plans. Enter toasts demo: no spawn. The DEMO badge is the warning color on purpose. That is the layout lab. When you drop --demo, you are on real Terminus. Missing Terminus is not fatal: the app still starts, the tree is empty, login is disabled, F4 still works. Same idea if Lando or git is missing — those workflows hide.

This is the same “stay in the shell, see the work” instinct we wrote about in building better workflows. Terminus is already the CLI. dd_pantheon is the cockpit around it so the next person on the account can see what you were about to run.

Preview first: the command is the product

The daily loop is short on purpose. Select a site, expand it, pick an environment. Read the preview. Press Enter in preview to run. That is it. Read-only inventory (site list, env list, tags, metrics) auto-runs with a short debounce so the cockpit is usable. The preview still shows those argv while they fire. Palette ReadOnly still waits for Enter. One mutating job per slot — a site.env, a local path, or global — so you cannot stack two deploys into the same env because you were impatient.

Login is Ctrl+L. Paste a Pantheon machine token. Terminus 4.3.2 has no first-class env for that token, so spawn is terminus auth:login --machine-token=… in argv. Preview and the job log redact it. Config, theme, and sites.toml never store it. If TERMINUS_MACHINE_TOKEN is already in your shell, the modal can use it — that is a TUI convenience, not a Terminus feature. Logged-out whoami is a normal launch state. After login, inventory fills. Logout is mutating and replaces the Login action while you are signed in.

The command palette is colon or Ctrl+K. It searches the discovered Terminus catalog and Lando tasks. Known dangerous names route into the same plan constructors as the first-class keys. The palette stages only. You still press Enter in preview. Wipe has no W key. Use the palette or the Actions row. Both call backup-first plan_wipe. Unrouted names warn raw palette — no backup-first / diffstat. The palette is not a safety bypass.

Safety that matches live risk

Pantheon deploys are not one command. On dev and multidev, e is git-mode: a dirty env:diffstat blocks connection:set git, then git push and workflow:wait. On test and live, e opens a note form. Test can --sync-content and prefixes a backup when that box is checked. Live never syncs content. Drupal gets --updatedb. LiveGate on live deploy is the word live. That is slower than y. That is the point.

Hard rules the TUI will not let you skip:

• No silent --yes. The runner injects it only after a TUI confirm.
• One mutating job per slot.
• Backup before clone-content, restore, wipe, and test --sync-content.
• Dirty diffstat blocks git-mode connection set.
• Palette is not a bypass.

Lando is in the same model. Bind a project with --root (needs a .lando.yml, or it still binds the path). Start and stop are first-class. Rebuild and destroy are destructive. Pull is destructive because it overwrites the local database — that matches how Lando’s Pantheon recipe actually works. Code-only push is mutating. Database push is LiveGate: type database, even if the dest is live. One word, not two. If the recipe is not pantheon, pull and push hide; global Lando still works.

We already treat Pantheon as the right home for Drupal and WordPress in our hosting notes. dd_pantheon is how we operate those sites without pretending the dashboard is the source of truth. The dashboard is still there for billing and users. The deploy is a command you can read.

The daily loop: CMS, Lando, and the tree

m is always the CMS form, never “month.” Metrics month is Shift+M. One form: remote (Terminus) or local (Lando), wp or drush, then the command after --. History lives in config (last 50). Wipe-class CMS — sql-drop, site-install — is destructive. The form never auto-inserts -y into the CMS argv. You type it if you mean it. That is how juniors learn that wp db query and drush sql-drop are not the same kind of Enter.

Sites overlay is optional sites.toml: cms, whether multidev is allowed, git branch, local path. Config holds layout, last site and env, org ids, history, locals. No secrets. Theme is the shared ldnddev YAML, version: 1, looked up next to the other TUI themes — not nested in the app config dir. Uninstall removes the binary and default theme. It does not delete your layout and history. That is correct. The cockpit should not eat your last site on uninstall.

Creating a site with “bind local” runs site:create then local:clone --site_dir=…. That is the onboarding path we want for a new client sandbox: one cockpit, not a wiki of five CLIs in the wrong order. Resolution for the local path is sites.toml first, then config [locals], then --root.

Ctrl+C cancels the running job’s process group. Doctor tells you whether Terminus is even on PATH before you file a ticket that the tree is empty. If you already keep git work in parallel — worktrees are how we avoid context-switching the repo — dd_pantheon is the ops surface for the env those worktrees deploy to.

Learn Terminus by watching it run

The CTA is not “never learn Terminus.” It is the opposite. Agency onboarding still fails when the only teacher is a wiki of copy-pasted argv that drifted from Terminus 3. Preview is the lesson. You see backup:create before wipe. You see env:deploy with --cc and the note. You see why git-mode stopped: dirty diffstat. You copy the redacted line into Slack when you ask for a second pair of eyes on live. A new hire can sit in --demo for an hour and learn the badges before they ever hold a machine token.

That also cuts the “what did we run on live?” thread. The job log is in the cockpit. The plan is in preview. You are not reconstructing a deploy from muscle memory and a half-scrolled terminal history. When something fails, doctor and the log are the first two places to look — not the Pantheon dashboard two environments over.

That is how we want people to learn the platform we ship on. Dashboard clicks do not transfer. A TUI that hides the command does not transfer either. dd_pantheon is guided operations that still leave you fluent when the TUI is closed. Run demo for the layouts. Run live for the muscle memory. Keep F1 open the first week. Then stop opening it.

If your team already lives in TUIs for contrast and email HTML — dd_emailforge and dd_wcag are the siblings — this is the one that sits on the Pantheon account all day.

Get it from GitHub and try --demo

The project is MIT licensed: github.com/ldnddev/dd_pantheon. Linux is the v1 target. You need Terminus 4.3.2 or compatible on PATH, Lando if you work locally, git for git-mode deploys. The illustrated tutorial in the repo is the same walkthrough we used here, with screenshots recaptured from the live demo widgets.

From a checkout:

./install.sh
dd_pantheon --demo
dd_pantheon
dd_pantheon --root /path/to/site

The installer puts a release binary in ~/.local/bin and writes a default theme only if one is missing. Uninstall is ./install.sh uninstall. From a clone without installing: cargo run -- --demo.

Give it the demo first. Cycle F4. Open LiveGate and type the word. Open the CMS form. Filter the palette to wipe and read the backup-first plan. Then drop demo, log in with a machine token, and run the same loop on a real dev env. Watch the preview. If doctor is red, fix PATH before you blame the tree.

We built dd_pantheon because Pantheon ops should be a visible command, not a remembered one. Daily Terminus work gets a cockpit. Learning gets the argv. Live still requires you to type live. Pull it, try --demo, and tell us which plan is still missing from your week.

Until next time, Jared Lyvers