Found: 2026-08-05, during a controlled study of building a BioEngine app from the skill alone (Tier 4, frontend). Reporter is an AI build agent; behaviour reproduced across 3 deploys and 25 status polls.
Summary
bioengine apps deploy ./dir --app-id <id-of-running-app> uploads a new artifact version but leaves the running application on the old version, silently and indefinitely. SKILL.md states it "updates if it matches a running one".
Observed
- App running as
nuclei-seg, version 1.0.0, status RUNNING/HEALTHY.
bioengine apps deploy ./dir --app-id nuclei-seg with a bumped manifest.- Artifact gained version 1.0.1.
- Running app stayed
status=RUNNING, running_version=1.0.0, and the newly added method was absent from available_methods.
- Polled 25 times over >8 minutes. The app never entered DEPLOYING. No error, no warning, exit code 0.
bioengine apps run <artifact> --app-id nuclei-seg --version 1.0.1 rolled it forward correctly in ~20 s.
Why this is worse than it looks, for apps with a frontend
The static site serves the artifact HEAD while the backend serves its deployed version. After a no-op apps deploy, a browser is served the v1.0.1 index.html against a v1.0.0 backend. If the new HTML calls a method added in the same bump, the UI fails at runtime while apps status reports RUNNING/HEALTHY throughout. There is no signal anywhere that the two halves are out of step.
Contributing factor
apps run accepts --version. apps deploy accepts no version flag at all, so there is no way to express "deploy this specific version to this running app" through the command the docs point you at.
Expected
Either (a) apps deploy --app-id <running-id> triggers a redeploy to the new version, or (b) it fails loudly and tells the user to use apps run --version. Silently succeeding while doing nothing is the worst of the three.
Additionally, consider surfacing artifact-head-vs-deployed-version skew in apps status for apps that serve a frontend.
Related minor finding
references/service_ids.md claims the replica suffix "changes on every redeploy". It stayed 875b97ef, byte-identical, across 3 deploys of the same app id. The advice to re-resolve the service ID is still correct, but the stated rationale is wrong, and the agent briefly used an unchanged suffix as a false "redeploy succeeded" signal.
Environment
Worker bioengine-worker-europa; CLI 0.14.0 installed via pip install "bioengine[cli] @ git+https://github.com/aicell-lab/bioengine.git"; app format_version: 0.6.0, CPU-only, entry: + frontend_entry:.
Provenance: found by an AI build agent in a controlled skill-only study (Tier 4), reproduced across 3 deploys. Filed on the reporter's behalf.
Found: 2026-08-05, during a controlled study of building a BioEngine app from the skill alone (Tier 4, frontend). Reporter is an AI build agent; behaviour reproduced across 3 deploys and 25 status polls.
Summary
bioengine apps deploy ./dir --app-id <id-of-running-app>uploads a new artifact version but leaves the running application on the old version, silently and indefinitely.SKILL.mdstates it "updates if it matches a running one".Observed
nuclei-seg, version 1.0.0, status RUNNING/HEALTHY.bioengine apps deploy ./dir --app-id nuclei-segwith a bumped manifest.status=RUNNING,running_version=1.0.0, and the newly added method was absent fromavailable_methods.bioengine apps run <artifact> --app-id nuclei-seg --version 1.0.1rolled it forward correctly in ~20 s.Why this is worse than it looks, for apps with a frontend
The static site serves the artifact HEAD while the backend serves its deployed version. After a no-op
apps deploy, a browser is served the v1.0.1index.htmlagainst a v1.0.0 backend. If the new HTML calls a method added in the same bump, the UI fails at runtime whileapps statusreports RUNNING/HEALTHY throughout. There is no signal anywhere that the two halves are out of step.Contributing factor
apps runaccepts--version.apps deployaccepts no version flag at all, so there is no way to express "deploy this specific version to this running app" through the command the docs point you at.Expected
Either (a)
apps deploy --app-id <running-id>triggers a redeploy to the new version, or (b) it fails loudly and tells the user to useapps run --version. Silently succeeding while doing nothing is the worst of the three.Additionally, consider surfacing artifact-head-vs-deployed-version skew in
apps statusfor apps that serve a frontend.Related minor finding
references/service_ids.mdclaims the replica suffix "changes on every redeploy". It stayed875b97ef, byte-identical, across 3 deploys of the same app id. The advice to re-resolve the service ID is still correct, but the stated rationale is wrong, and the agent briefly used an unchanged suffix as a false "redeploy succeeded" signal.Environment
Worker
bioengine-worker-europa; CLI 0.14.0 installed viapip install "bioengine[cli] @ git+https://github.com/aicell-lab/bioengine.git"; appformat_version: 0.6.0, CPU-only,entry:+frontend_entry:.Provenance: found by an AI build agent in a controlled skill-only study (Tier 4), reproduced across 3 deploys. Filed on the reporter's behalf.