Launch Once,
Update In Place

A fast iteration loop for isolated environments

Digital Twin Universe

DTU builds complete, isolated environments from a declarative profile

You clone, install, and run code the way a real user would — inside a self-contained Incus container defined by a single profile.

So the real question is how fast you can iterate inside one.

▹A declarative profile describes the whole environment — no hand-built setup.
▹Isolation means you test in a real user’s shoes, not your own dev box.
▹Lifecycle commands: launch, update, status, list, destroy.

It’s real and shipped

`update` is a first-class, released lifecycle command

The function exists at current HEAD and the README lists it alongside launch, status, list, and destroy.

Status: Shipped and released (v0.3.1)

Which raises the question it was built to answer.

1347

engine.py line where def update lives

261

cli.py line for def update

v0.3.1

Release tag on the repo

5

Lifecycle commands in the README

The friction

Before `update`, every code change forced a full teardown-and-rebuild

To see a one-line change, you tore the whole environment down and built it back — slow enough to discourage testing.

The fix was to stop destroying the box on every iteration.

1Destroy the environment
2Re-provision the container
3Re-clone repos & reinstall dependencies
4Rebuild PyPI override wheels
5Re-run readiness checks

The change

On 2026-04-06, DavidKoleczek shipped `update` in one cross-cutting commit

Commit 1c0338a spanned code, profiles, docs, and E2E tests — a sizeable, whole-feature landing, not a sketch.

Here is exactly what it does when you run it.

17

Files changed in commit 1c0338a

665

Insertions

117

Deletions

167

Lines added to the E2E test file

How it works

`update <id>` re-runs your profile’s commands in place — it never destroys the container

It first checks the environment is still Running, then executes the profile’s declarative update.cmds inside it.

Does fresh code actually go live without a rebuild? A test proves it.

# update refuses if the env isn't running
state = incus.get_instance_state(container_id)
if state != "Running":
    raise RuntimeError(...)

# then re-run declarative update.cmds in place
_run_provisioning(container_id, profile.update.cmds)

# readiness re-runs unless --skip-readiness
if not skip_readiness:
    check_readiness(container_id)

The proof

An E2E test makes fresh code go live in the SAME running container

test_update_picks_up_new_code pushes a mutation after launch, runs update, and verifies the new version is live — no rebuild.

Fast iteration only counts if “ready” can be trusted, though.

1Launch environment at core 99.0.0
2Push a code mutation to Gitea (99.0.0 → 99.1.0)
3Run update on the same container
4Verify core 99.1.0 is live — no rebuild

Trustworthy readiness

The next day, “ready” became something you can trust from the outside

Commit e1017a4 (2026-04-07) added host-side access-port verification: ready is true only when in-container checks AND host-side access checks pass.

Together these close the loop: launch once, iterate fast, trust ready.

✓Host does a TCP connect to the mapped access port.
✓Host does an HTTP GET, retrying up to verify_timeout (default 30s).
✓ready is true only when in-container AND host access checks pass.

The pattern

Launch once. Update in place. Iterate fast.

In-place updates re-run your declarative commands without destroying the container — and host-side verification means the “ready” you iterate against can be trusted end-to-end.

Sources

Sources & Research Methodology

Repository examined: microsoft/amplifier-bundle-digital-twin-universe (local clone at HEAD 2087575). Note: the task named robotdad/* as source, but the actual git remote is microsoft/* and the update work is by DavidKoleczek — zero commits by ‘robotdad’ exist.

Feature status: Shipped and released (tag v0.3.1).

Commands run to verify every claim:

git show -s --format='%H | %an | %ad | %s' 1c0338a — update commit (DavidKoleczek, Mon Apr 6 2026)
git show 1c0338a --shortstat --numstat --format='' — 17 files, 665 insertions, 117 deletions; engine.py +81, cli.py +36, profile.py +17, test +167
git show 1c0338a -- .../engine.py .../cli.py .../profile.py — Running guard, update.cmds, --skip-readiness
git show -s --format='%H | %an | %ad | %s' e1017a4 — host-side access verification (Tue Apr 7 2026)
grep -rn '99.1.0' tests/ — UPDATED_CORE_VERSION='99.1.0', test_update_picks_up_new_code
grep -n 'def update' .../engine.py .../cli.py ; git tag ; git log --oneline -1 — engine.py:1347, cli.py:261, v0.3.1, HEAD 2087575
git log --format='%an' --all | sort | uniq -c | sort -rn — contributor counts

Gaps: No benchmark/timing numbers exist in the repo to quantify “slow” teardown-and-rebuild — treated as motivation, not a measured metric. PR numbers for 1c0338a and e1017a4 are not embedded in their commit subjects, so they are left unstated. “Patches” is a paraphrase: the mechanism is re-running declarative reinstall/restart commands, not a source patch.

Primary contributor: DavidKoleczek (38 commits across all branches; author of the update command, host-side readiness verification, and the declarative readiness system).

Launch Once,Update In Place