Delete after

A delete-after timer permanently deletes a machine at a set time. Use it as a safety net for throwaway machines (forks for a task, demo machines, agent sandboxes), so a machine nobody remembered stops billing. boxd enforces the timer, not the machine. It fires whatever state the machine is in: running, on standby or hibernated, or stopped. A sleeping machine’s own clock is frozen, so a timer inside it would never fire.

Deletion is permanent. The machine’s disk goes with it, as with boxd machine remove. Snapshots you saved from it are kept.

Set a timer

Give a duration, from now:

boxd machine config set myapp delete-after 2h    # 3600, 90m, 2h, 1h30m, 7d
boxd machine new job-42 --delete-after 30m       # at creation
boxd machine fork base job-43 --delete-after 1h  # on a fork

await boxd.machines.setDeleteAfter("myapp", 7200);                    // seconds from now
await boxd.machines.create({ name: "job-42", deleteAfter: 1800 });
await boxd.machines.fork("base", { name: "job-43", deleteAfter: 3600 });

boxd.machines.set_delete_after("myapp", 7200)                         # seconds from now
boxd.machines.create("job-42", delete_after=1800)
boxd.machines.fork("base", "job-43", delete_after=3600)

Or a cron expression: the machine is deleted the next time it matches, in UTC. Anything with a space, or an @ nickname like @daily, is read as a cron expression:

boxd machine config set myapp delete-after "0 18 * * *"    # the next 18:00 UTC
boxd machine new demo --delete-after "0 9 * * 1"           # next Monday 09:00 UTC
boxd machine config set myapp delete-after @daily          # next midnight UTC

await boxd.machines.setDeleteAfterCron("myapp", "0 18 * * *");
await boxd.machines.create({ name: "demo", deleteAfterCron: "0 9 * * 1" });

boxd.machines.set_delete_after("myapp", cron="0 18 * * *")
boxd.machines.create("demo", delete_after_cron="0 9 * * 1")

A cron timer fires once, at the next match. The machine is gone afterwards, so there is no second match to wait for. In the console, it’s the Delete after setting on the machine’s Settings tab: pick a preset, or Custom for a cron expression. From inside a machine, the in-machine boxd takes the same command and defaults to the machine it runs on: boxd machine config set delete-after 2h, or --vm <name> for another of your machines.

Extend or clear it

Setting the timer again replaces it. That lets a script keep pushing its own deadline back while it is still working (see Leases below).

boxd machine config set myapp delete-after 4h   # replaces the earlier timer
boxd machine config set myapp delete-after off  # or 0: no timer

await boxd.machines.setDeleteAfter("myapp", 14400);
await boxd.machines.setDeleteAfter("myapp", 0);   // clears it; resolves to null

boxd.machines.set_delete_after("myapp", 14400)
boxd.machines.set_delete_after("myapp", 0)        # clears it; returns None

See the time left

boxd machine get myapp                     # delete-after: in 1h 59m (2026-10-05T14:00:00Z)
boxd machine list                          # the TTL column
boxd machine config get myapp delete-after

The SDKs return the deadline as machine.delete_at (Python) / machine.deleteAt (TypeScript), None/null when there’s no timer, and the cron expression it was set with as delete_after_cron / deleteAfterCron. The console shows Deletes in … on the machine and in the machine list.

Forks

A fork starts with its own copy of its parent’s timer, counted from the moment of the fork: a parent set to delete after 2 hours gives every fork a fresh 2 hours, however long the parent has left. A cron timer carries over as the expression and fires at its next match after the fork. Pass --delete-after on the fork to give it a different timer, or --delete-after 0 for none. A machine restored from a snapshot starts without a timer.

Leases

For a job whose length you can’t predict, keep the timer short and have the job extend it while it is alive. If the job dies, or the machine stops responding, the extensions stop and the timer deletes the machine:

# inside the machine, next to the job
while kill -0 "$JOB_PID" 2>/dev/null; do
  boxd machine config set delete-after 15m
  sleep 300
done

If auto-suspend is on for the machine (it is off by default, but you may have set it, and a fork inherits its source’s), a job with no network traffic puts the machine into standby, which freezes the job and the loop with it. The timer still deletes the machine on time, but the job won’t finish. For batch jobs, pass --auto-suspend-timeout 0 to be sure.

Delete when the task is done

A timer deletes at a time, not when work finishes. To delete a machine as soon as its task completes, have it delete itself as the last step of the job, and keep a delete-after timer as the safety net for a job that hangs or crashes.

Getting started

Guides

Integrations and automations

Use cases

References

Delete after

Set a timer

Extend or clear it

See the time left

Forks

Leases

Delete when the task is done

​Set a timer

​Extend or clear it

​See the time left

​Forks

​Leases

​Delete when the task is done

Set a timer

Extend or clear it

See the time left

Forks

Leases

Delete when the task is done