Documentation menu

Documentation

Updating

How TDE updates itself and how to pin a version.

On this page

Overview

TDE has two updaters, and it helps to keep them apart:

  • The system updater keeps the tde binary itself current.
  • The app updater watches the CLIs and TUIs installed through TDE and raises a badge when they have newer releases.

Both run on the same daily cadence and both surface in the same window, but they update different things.

The system updater

How it works

A release build checks the stable feed in the background. Nothing interrupts the running session:

  1. Probe. Fetch the release manifest (default https://tde.sh/releases/stable.json), validate its schema, and select the artifact matching this OS, architecture and format — tar.gz on Linux, dmg on macOS.
  2. Compare. Semver comparison against the running version, tolerant of a leading v.
  3. Download and verify. Fetch the artifact and check its SHA-256. A mismatch aborts with "refusing to install (possible tampering)". On Linux the tde binary is extracted from the tarball root.
  4. Stage. Write it to ~/.tde/updates/ and record pending.json. The running process keeps its current version.
  5. Activate. On the next start, before any terminal or state setup, TDE re-verifies the staged bytes, swaps them in atomically, and re-execs itself so you land in the new version on that very launch.

You are offered a shortcut in between: once an update is staged, a modal asks "TDE <version> is installed and will activate on restart. Restart now?" Choosing Restart now does the same clean process re-exec, not a reboot.

Cadence

SituationNext check
Last check succeeded24 hours
Last check failed15 minutes
No check recorded yetimmediately

The report is persisted to ~/.tde/updates.json, so the cadence and the badge survive restarts. The system probe deliberately runs before the per-app probes, so a slow app pass can never keep the feed check on the 15-minute retry treadmill.

Activation targets

On a managed Linux install, activation writes the new binary into <root>/versions/<tag>/tde and swaps the current symlink — the same layout the installer uses, so ~/.local/bin/tde keeps pointing at the right place.

Otherwise it replaces the executable next to itself, keeping the old one as a dotfile backup and restoring it if the rename fails.

When automatic updates are off

Automatic downloads are disabled when any of these is true:

  • TDE_AUTO_UPDATE is off, 0 or false.
  • The build is a debug build.
  • The executable lives under a cargo target/debug or target/release directory — development builds never auto-update.
  • The install directory is not writable and is not a managed versioned install.
  • TDE_MACHINE_NAME is set. TDE Machines bake the binary into the VM image and update by whole-image rollout, never by self-update.

Probing still happens, so the badge still tells you an update exists — you just apply it yourself.

Environment overrides

VariableEffect
TDE_AUTO_UPDATE=offDisable automatic downloads (0 and false also work).
TDE_UPDATE_MANIFEST=<https url>Release feed for the in-app updater. Must be https://; anything else is ignored.
TDE_REPO=owner/repoFall back to that repository's GitHub Releases when the feed is unavailable.
TDE_GITHUB_TOKEN / GITHUB_TOKENBearer token for private or self-hosted GitHub releases.

The feed URL is resolved in order: TDE_UPDATE_MANIFEST, then the manifest field of the install receipt (~/.local/share/tde/install.json, then /opt/tde/install.json), then https://tde.sh/releases/stable.json.

Updating manually

Re-running the installer is a full, verified update — it is the same download, checksum and atomic swap:

bash
curl -fsSL https://tde.sh/install | sh

TDE_VERSION, TDE_URL, TDE_RELEASE_BASE, TDE_CHANNEL and --channel are installer-side and let you pin a tag, point at an internal artifact host or follow a non-stable channel. They are documented in full on Installation.

bash
# Pin an exact release
TDE_VERSION=v0.3.30 curl -fsSL https://tde.sh/install | sh

# Follow a different channel
curl -fsSL https://tde.sh/install | sh -s -- --channel beta

The app updater

Separately from the binary, TDE tracks what it installed for you. The same daily probe compares each installed app's version against its upstream release and reports the ones that moved.

Three sources feed one report:

  • Catalog apps with a GitHub release (install.github = "owner/repo"), checked against the GitHub Releases API and updated by re-running eget.
  • Agent runtimes on npm or PyPI, reusing the desktop's runtime probe.
  • The TDE binary itself, which appears as the system row in the same list.

A ⬆ N badge appears on the status bar when the count is non-zero — the count includes the system update. Clicking it opens the updater window: one row per app with its installed and latest versions, a per-app Update button, Update all, and Refresh to force a probe now.

Version probes are paced and have a hard one-second deadline, because some programs ignore --version and start their whole TUI instead.

Files involved

PathContents
~/.tde/updates.jsonThe last update report: timestamp, badge count, per-app rows.
~/.tde/updates/pending.jsonThe staged update: version, digest, staged path.
~/.tde/updates/tde.pendingThe verified Linux binary waiting to activate.
~/.tde/updates/TDE.pending.dmgThe verified macOS DMG waiting to activate.
~/.local/share/tde/install.jsonThe install receipt, including the feed URL.

Next