Docker

Reports whether Docker Engine was started in this sandbox, who owns it, why it is in its state, and the process whose logs hold Docker's output (GET /processes/{id}/logs). Read-only: it never starts or restarts Docker. waitMs (clamped to 1000) waits for a starting state to settle before answering. A Docker failure never makes the sandbox unusable; it is reported here as failed. Windows sandboxes answer unsupported.

The sandbox environment variable DAYTONA_DOCKER_START selects who starts Docker (case-insensitive; unset, empty or an unknown value means auto):

• auto (default): if the image entrypoint is a recognized Docker entrypoint (dockerd, the docker:dind dockerd-entrypoint.sh when it will run dockerd, or docker-entrypoint.sh dockerd), the entrypoint starts Docker and the daemon waits for its socket. Otherwise, if the image has a dockerd, the daemon starts it (owner daemon), waits for it, then starts the entrypoint.
• entrypoint: the image entrypoint starts Docker; the daemon only waits for the socket (owner entrypoint) and never launches dockerd itself.
• off: the daemon neither starts nor waits for Docker (disabled). The image entrypoint still runs, so a recognized Docker entrypoint starts Docker itself anyway; that is reported as unmanaged with owner entrypoint, reason docker-start-off-entrypoint-owns-docker and the entrypoint's processId, and the engine is not probed.

Docker storage that is not ready (unsupported/failed) takes precedence over every mode, and a DOCKER_HOST other than the default local socket makes auto and entrypoint report unmanaged without starting anything.

Recognition is deliberately narrow. An entrypoint that starts dockerd some other way (sh -c "dockerd …", tini -- dockerd, a supervisor) is not recognized, so under auto the daemon starts its own dockerd first; the entrypoint's dockerd then typically fails against the one already running, and any flags it passes are lost. Set DAYTONA_DOCKER_START=entrypoint for such images.