Documentación
Updating
How TDE updates itself and how to pin a version.
En esta página
Overview
TDE has two updaters, and it helps to keep them apart:
- The system updater keeps the
tdebinary 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:
- 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.gzon Linux,dmgon macOS. - Compare. Semver comparison against the running version, tolerant of a
leading
v. - Download and verify. Fetch the artifact and check its SHA-256. A
mismatch aborts with "refusing to install (possible tampering)". On Linux
the
tdebinary is extracted from the tarball root. - Stage. Write it to
~/.tde/updates/and recordpending.json. The running process keeps its current version. - 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
| Situation | Next check |
|---|---|
| Last check succeeded | 24 hours |
| Last check failed | 15 minutes |
| No check recorded yet | immediately |
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_UPDATEisoff,0orfalse.- The build is a debug build.
- The executable lives under a cargo
target/debugortarget/releasedirectory — development builds never auto-update. - The install directory is not writable and is not a managed versioned install.
TDE_MACHINE_NAMEis 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
| Variable | Effect |
|---|---|
TDE_AUTO_UPDATE=off | Disable 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/repo | Fall back to that repository's GitHub Releases when the feed is unavailable. |
TDE_GITHUB_TOKEN / GITHUB_TOKEN | Bearer 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:
curl -fsSL https://tde.sh/install | shTDE_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.
# 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 betaThe 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-runningeget. - 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
| Path | Contents |
|---|---|
~/.tde/updates.json | The last update report: timestamp, badge count, per-app rows. |
~/.tde/updates/pending.json | The staged update: version, digest, staged path. |
~/.tde/updates/tde.pending | The verified Linux binary waiting to activate. |
~/.tde/updates/TDE.pending.dmg | The verified macOS DMG waiting to activate. |
~/.local/share/tde/install.json | The install receipt, including the feed URL. |
Next
- Installation — install paths, channels and mirrors.
- Store — where the tracked apps come from.
- Troubleshooting — when an update will not apply.