---
title: Docker
full: true
_openapi:
  preload:
    - ./specs/toolbox-api.json
  toc:
    - depth: 2
      title: Docker Engine status
      url: '#docker-engine-status'
  structuredData:
    headings:
      - content: Docker Engine status
        id: docker-engine-status
    contents:
      - content: >-
          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.
        heading: docker-engine-status
  methods:
    - GET
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

export default function Layout(props) {
  const { OpenAPIPage } = props.components ?? {};
  return (
    <>
      {props.children}
      <OpenAPIPage document="./specs/toolbox-api.json" webhooks={[]} operations={[{"path":"/docker/status","method":"get"}]} showTitle showDescription />
    </>
  );
}