Machines

A TDE that is already running

A TDE Machine is a managed cloud box that boots straight into TDE. There is no install step, no terminal emulator to configure and nothing to keep awake on your laptop: the desktop is running, Web Share is bound, and you open it in a browser tab or reach it over SSH.

Machines are managed from your account on tde.sh, not from the tde CLI — there is no tde machines command. For the commercial pitch see /products/machines; for cost see /pricing.

Sizes and regions

Three sizes, each with a persistent volume that survives restarts, resizes and image rollouts.

Every size is available in every region: São Paulo (gru), Ashburn (iad), Frankfurt (fra), Singapore (sin), Tokyo (nrt) and Sydney (syd). The create dialog pre-selects the region closest to you and marks it "Recommended".

Provisioning

The first machine on a new subscription is created as soon as checkout completes. Machines you add later are scheduled: the create dialog says so explicitly, and the machine is provisioned at your next renewal date rather than immediately. The same is true of resizes and removals — they take effect at the period boundary, and a scheduled removal can be undone before then.

Provisioning walks a resumable sequence — application, volume, machine, dedicated address, branded hostname — and then polls the machine's own health endpoint. Only a genuine ready response flips the machine to ready and reveals its credentials.

A stuck provision is retried automatically for several minutes before it is marked failed, so a slow first boot is normal and not something to intervene in.

Reaching a machine

The web desktop

The primary path. Open web desktop on the machine's detail panel takes you to a connect page that polls the machine's health and then redirects straight into the Web Share URL on the machine's own branded hostname. The operator token travels in the URL fragment, so it never reaches a server.

Machines suspend when idle and wake on the first request — which is exactly what that health polling triggers. A cold start typically resolves in seconds, and the connect page waits for it rather than showing an error.

SSH

Every machine also runs sshd. The detail panel gives you the host, the port and the user, plus a copyable command:

ssh dev@m-your-machine.machines.tde.sh

An interactive login opens the desktop. The machine starts its TDE session during boot and waits for it to be ready before accepting SSH, so logging in attaches you to the running desktop rather than dropping you at a shell prompt. Press Ctrl-] to detach and get a normal prompt on the same connection.

Everything non-interactive is untouched. scp, sftp, rsync, git over SSH and ssh dev@… <command> all behave exactly as before, because the attach lives in the login profile rather than in the login shell — a non-interactive session never runs it. Two ways to skip it when you want a plain shell:

# just this once
ssh dev@m-your-machine.machines.tde.sh -o SetEnv=TDE_NO_LOGIN_ATTACH=1

# from now on, on that machine
touch ~/.tde/no-login-attach

A failed attach also drops you at a shell with the reason printed, so a broken desktop can never lock you out of your own machine.

Two more things to know:

• One key per account, applied per machine. You register a single OpenSSH public key in your account. Adding or changing it does not touch machines that are already running — the panel shows "Your SSH key changed" and offers an Apply SSH key action per machine, which reboots that box to pick it up.
• SSH does not wake a suspended machine. The web desktop port has a wake handler; port 22 does not. If SSH times out, open the web desktop once to bring the machine up, then reconnect.

For the session model behind the attach, see Sessions; for work that continues with nobody attached, see Runtime.

What is on the image

A machine boots a pinned TDE image — an explicit version tag, never a floating latest — with the tools a working machine needs already baked in: the tde binary itself, the RTK and CTX plugins, and the Claude, Codex and OpenCode agent CLIs. Nothing has to be downloaded on first boot for those to work.

Machines are intentionally headless: there is no login keyring and no session D-Bus. TDE's secret vault handles that case explicitly, and a vault problem never takes the Web Share endpoint down with it.

Updates

Machines never self-update. A new TDE version arrives as a whole-image rollout. When one is queued for your fleet, the panel shows Update pending — applies on next restart and the Restart button relabels to Restart & update. You choose when to take it; nothing reboots your machine underneath you.

Licensing and first boot

A machine is handed its license and its Web Share credentials as environment variables at creation time. There is no separate activation step for you to perform: the image activates against the license on boot and sync pulls your board, Brain and projects down.

Two consequences:

• A machine bought without a plan boots unactivated. It still provisions and still works standalone; sync lights up once you add a plan and activate from inside the desktop.
• Rotating your license propagates automatically. Every machine on the account is handed the new key and reboots into it.

The commands the image runs on boot are the same headless ones you can run yourself:

tde license activate --key "$TDE_LICENSE_KEY"
tde sync hydrate --credentials-only
tde sync hydrate --repos-only

tde bootstrap run is the non-interactive form of the first-boot wizard, with system package installation opt-in so an image boot can never block on a sudo prompt.

Monthly usage reports

Open Account → Reports → Machines to see a monthly statement for every Machine on your account. The report separates four measurements instead of collapsing them into one vague uptime number:

The current month updates as durable runtime and control-plane evidence arrives. Previous-month navigation appears only when your account actually has usage in an earlier month. Each statement includes per-Machine, per-Task and per-day breakdowns, plus an explicit coverage warning when measurement began partway through a period.

Usage telemetry is deliberately narrow. It records lifecycle boundaries, heartbeat times, Task identifiers and optional Task titles. It does not collect command output, file contents or viewer IP addresses. Titles are mutable metadata stored outside the append-only usage evidence, so they can be changed or removed without rewriting the measurement ledger.

Managing the fleet