v0.4.14

Added

• A dashboard, and it tells you how much room the box has left. The home page is now an overview rather than the workspace list: free memory, free disk, what your running workspaces have been promised, and which of them are actually using it. Disk filling up during a migration is the worst state this product can get into, and until now nothing in the interface would have warned you.

  The workspace list has moved to /containers — update any bookmark that pointed at the old home page. Everything on it is unchanged, plus live CPU and memory bars on each running workspace.

• Live resource usage per workspace. CPU, memory, processes and network for every running workspace, on the dashboard, on each card in the list, and on the workspace's own page. Finding the workspace eating the host no longer means SSHing in and running docker stats. Readings are taken on demand and briefly cached; nothing is stored.

• Creating a workspace that will not fit is now refused, not discovered later. Ask for more memory than the host has available and the create stops with both numbers, instead of the workspace being killed under pressure some time afterwards. The create form warns before you submit and offers to go ahead anyway — memory limits are ceilings, not reservations, so overcommitting is a legitimate choice, just one worth making deliberately. Agents get the same refusal through create_container, with confirm_overcommit to proceed.

  On a host that cannot report its own memory the check simply does not apply.

• Agents can publish and withdraw workspace subdomains themselves. Two new MCP tools, Add container subdomain and Remove container subdomain, give an agent the same control the workspace detail page has: expose a port at <label>.<base-domain>, or stop publishing one and free the label. Grant them to a key on the API keys screen like any other tool.

  An agent that starts a dev server no longer has to stop and ask you to open the URL for it — it can publish the port, hand you the link, and take it down when the work is finished. Nothing restarts: the workspace, its processes and its terminal sessions carry on untouched. Both tools need a write grant on the workspace, both return the workspace's full subdomain list so the agent can see the resulting URLs, and where a deployment has several base domains the agent can name one (or leave it to the default).

Changed

• Upgrades no longer re-download a workspace image that has not changed. The workspace image is ~750 MiB and most releases do not touch it, but every upgrade fetched it again anyway — a download of some minutes for bytes already on the disk. A release that leaves the image alone now ships the copy you already have, and the installer says so (devgrail-container is unchanged in v0.4.14 — keeping v0.4.13) instead of downloading it.

  Nothing about verification is relaxed: an image is skipped only when the release names the exact build already installed and that build is still what the workspace tag points at, so a host that has rolled back is never told it is up to date. Only the images that genuinely changed are fetched, and the server image — which is stamped with the release it ships in — always is.

• The installer no longer stops on a prompt when there is nobody to answer it. Run from a container or any other environment with no terminal attached, it could fail with /dev/tty: No such device or address instead of taking the default it already had — it checked that the terminal device existed rather than that it could be opened, and in a container the first is true while the second is not. Unattended installs that supply their answers through the environment are unaffected either way; this only fixes the case that used to stop.

• The workspace image is now built from pinned versions, and it can tell you which ones. Until now the image tracked whatever was newest on build day: the base OS, Node, opencode, Claude Code and Codex all floated, so two builds of the same DevGrail release could ship different tools. A release tag now names one exact set. Every workspace also carries /etc/devgrail-workspace.json listing what it contains — base image, Node, Python, gh, and the three AI CLIs — so "which version of the agent is in here?" is a question you can answer from inside the terminal, and the same facts are on the image's labels for anyone looking from the host.