mim install <src> is shorthand for morloc make --install <src> run inside the target environment (the default, or the one named with --env). The installed program is identified by its module name — the module <name> declaration in the source — never by the file name or any -o. By convention the source lives in main.loc, so a program declaring module dna installs as dna regardless of the file name.

A view is what an adapter shows of an environment. The MCP view and the API view are independent sets, and eval is a separate capability. view edits a per-environment file recording that declared intent; nothing is served until start realizes it.

Installing a module makes it importable; adding it to a view makes it callable over the network. The two are independent, so a program can be installed and unreachable, which is the default. A module must be installed before it can be added (view add checks for the launcher and errors otherwise). --as takes a comma-separated list of mcp and/or api. view eval turns on the sandboxed eval capability with an import allow-list; --off disables it.

start launches a single serving front-end — one HTTP listener that answers /mcp (MCP), /call/<module>/<command> (JSON API), /discover (API discovery), and /health (liveness) — forwarding each call to that module’s own worker process.

With no --mcp, start serves the environment’s views; it errors if there are none rather than serving nothing. --mcp <module> is a quick one-off that ignores the declared views and serves that one module over MCP.

By default the endpoint binds the host’s 127.0.0.1 (loopback, reachable only from the host), so no token is required. Making the endpoint reachable elsewhere is a deliberate opt-in:

For AI assistants, start also prints an mcpServers client-config entry as pure JSON on stdout (so mim start …​ > dna.mcp.json is ready to drop into a client); human status goes to stderr.

status reads a runtime record written by start, so it reports the mode, served modules, and URL even under host networking where the engine shows no published port.

mim eval '<expr>' evaluates a Morloc expression against a running serve container’s sandboxed eval endpoint (enabled with view eval):

mim eval reaches the serve on the port it recorded when it started, so you do not have to remember which one it picked; --port overrides that. If the serve requires a bearer token, pass it with --auth-token or set MORLOC_MCP_TOKEN — the token is never written to disk, so mim can tell you that one is needed but cannot supply it for you.

Freezing turns the environment you have been working in into a container image that carries everything it needs.

The image is the environment with its mounted halves baked in. The morloc runtime is copied: the nexus, the shared library, the language bindings, and a launcher for every installed program, all of which were built after the environment’s image was. The language toolchain is installed from the environment’s own pixi.lock — a solved toolchain is not a directory you can copy, so what travels is the lock that reproduces it. The programs and the module sources behind them are copied too. Anything required and missing is reported by name, so freezing an environment that was never provisioned fails instead of building an image with holes in it.

Each program travels as the mirror of its project directory that install made, since the pools import sourced files from it. Whatever else the project held goes with it — which is fine for a data file the program reads and unfortunate for a build tree. So before anything expensive runs, freeze walks every installed program and prints what it will carry:

A tool-state directory — .git, a cargo target/, node_modules, pycache, .venv, an editor’s cache, and the like — is a refusal: nothing a program runs reads one, and the fix belongs in the project. Add it to the project’s .morlocignore (one pattern per line, target/ for a directory), reinstall the program, and freeze again; include: in package.yaml is the allowlist form of the same control. A program over 100 MB, or a file over 50 MB, is a question rather than a refusal, because only you know whether that is data the program needs: on a terminal freeze shows the sizes and asks; from a script, where nobody can answer, it stops. An environment with no programs installed is asked about the same way, since freezing one is usually a mistake but sometimes the point — a base to run programs in later. --force answers all of these.

Nothing appears in your working directory. The artifact is a tag in the engine’s image store, which is what makes it portable: you move it by pushing it to a registry, or as a file.

--save is the engine’s own docker save, so the tarball carries every layer including the base and needs nothing else to restore. There is no morloc-specific archive format.

The image above is the environment whole — the compiler, the Rust and C toolchains, pixi — which is what lets it evaluate expressions and rebuild a pool, and is also most of its size. When the programs are the point and nothing in the image will ever compile, freeze it slim:

A slim image keeps every interpreter and package the environment declared and removes what only built things: the compilers and their sysroot, rustc, make, git, the morloc compiler, pixi, and the runtime’s headers. The cut is computed from the environment’s own package records, so it also reaches the compiler chain that conda’s r-base drags in for install.packages — about half of a typical environment goes. What runs is exactly what the full image runs, at the same paths, and the image is checked after the build: every program’s launcher starts, and the nexus and every compiled pool resolve their shared libraries. The default tag ends in -slim, so the two flavours of one environment do not overwrite each other, and the morloc.flavor label says which one you hold.

A slim image cannot eval, so an environment that exposes eval is refused; drop the view or freeze without --slim. The same holds for anything a program compiles at run time — Cython at import, numba, R packages installed from source — which needs the full image.

An image that has left mim has nothing tracking it, so it carries its own provenance as labels — the morloc version, the environment it came from, the programs inside, and which of them answer on each adapter. docker inspect reads them back.

The image serves the environment’s views, and nothing else. Declare no views and the image has no default command — it is still complete, and you run programs in it by name:

The first form serves; the second runs a program through the command line the compiler generated for it. One image, both interfaces, from the same declarations.

Inside the container the service binds every interface, because a container’s loopback belongs to the container and a published port never reaches 127.0.0.1 in there. That address says nothing about who can reach the service, so the image does not treat it as if it did: it serves without a token, and says so once at startup. What can reach it is your decision, made outside the container — publish to loopback with -p 127.0.0.1:8080:8080, keep it on an internal network, or put a gateway in front. Set MORLOC_MCP_TOKEN to require a bearer token as well.

Eval is the exception. It runs expressions the caller writes rather than the functions you exported, and a single call can rebuild a pool, so it asks for a token even where the rest of the endpoint does not:

The first serves eval to holders of the token; the second waives the requirement, for a deployment where something in front already gates it. Without either, eval is locked: it is not advertised in the tool list, /discover reports it as not callable, and a request to it is refused with the reason. Everything else serves normally.

mim start waives the requirement by itself when the endpoint cannot leave the host, which is the case eval mostly exists for; --eval-allow-no-auth waives it when serving off-box.

mim manages environments, not images. It builds a deployment image and has no further relationship with it: status, logs and stop act on serves started from environments, so an image you run yourself is not something mim tracks, and needs neither mim nor the environment it came from.

The wire protocols behind these endpoints — the MCP handshake, the JSON API call/discover shapes, sessions, and status codes — are documented in the Model Context Protocol (MCP) and Building APIs chapters.