# Running Images
Every host accepts `.dftc` files. A `.dftc` is detected by its `DFTC`
magic and decoded by the shared app loader — the same loader that reads
`.dft` source — so an app runs identically whether it was shipped as
source or as an image.
## Host Commands
| Host | Command | What it does |
|---|---|---|
| CLI | `deft run app.dftc` | Headless run; script stdlib only |
| retro (GL) | `retro app app.dftc` | Opens a single-app workspace, app in its panel |
| retra (ANSI) | `retra app app.dftc` | Same, over ANSI/SSH |
| hydra | `hydra app.dftc` | Launches the app in an instance window |
`retro app <ref>` accepts a path (`.dft` or `.dftc`) or a package
reference exactly like the launcher. From the bundle directory:
```sh
retro app editor.dftc
# or from anywhere:
retro app /opt/vendor/packages/acme/pos/pos.dftc
````
## Three Ways to Say "Run" — Pick the Right One
The TUI hosts embed the full `deft` command line, which makes these
three invocations do very different things:
| Invocation | What happens |
|---|---|
| `retro app.dftc` | Script mode. The image is evaluated in a headless runtime, top-level code runs, and the process exits. For a panel app, nothing appears. |
| `retro run app.dftc` | CLI verb. Dispatches to the shared `deft` CLI, headless, with no TUI stdlib — apps using `tui/*` fail with `undefined symbol: tui/set-menu`. |
| `retro app app.dftc` | App mode. Opens a workspace and launches the image into a panel. This is the one you want for a GUI/TUI app. |
A plain script (no `tui/*` calls) may be fine with the first form;
`retro run` is useful for testing the non-TUI parts of an app. Panel
apps should always be launched with `app`.
## Installing Into a Package Root
A bundle directory is a drop-in package. Copy it under any `:pkgs`
root — owner-scoped for namespaced apps:
```sh
deft compile --app acme/pos -o /opt/vendor/packages/acme/pos
````
The launcher and the app selector discover compiled-only packages by
probing `<pkg>/<name>.dft`, then `<pkg>/<name>.dftc` (and the `src/`
forms). The bundle's copied `package.dft` is what makes the directory a
package; the image is what actually loads.
With lockdown's [`images-only`](lockdown-configuration) enabled, any
leftover source `.dft` is refused at load — only the images run.
## Capability Checks
The image manifest can record runtime capabilities
(`deft compile --app x --requires draw/text`). Before loading, the host
checks them against its registered plugins and refuses the image when a
requirement is missing:
```
app: pos.dftc requires unavailable capability 'draw/text'
````
Use `--requires` for host features an app cannot degrade without
(surface/GL functions, audio, and so on). It is separate from the
package's `platforms` metadata, which names the intended hosts
(`retro`, `retra`) but is not enforced by the loader.
## Assets
The image embeds code paths, not file bytes. Asset lookups that go
through `[import/resolve "<owner>/<name>/assets/…"]` fall back to the
image's own directory when the original package tree is gone, so a
bundle carrying `assets/` beside the image is fully standalone. Apps
that build file paths by hand need to place their files next to the
image under the same relative layout.