canonical: https://jentic.com/apis/docker.com/docker-engine # Docker Engine API The Docker Engine API is the HTTP interface that the docker CLI itself uses to talk to a Docker daemon. It exposes 104 endpoints across containers, images, networks, volumes, exec sessions, swarm services, nodes and configs. Talking to it directly lets a tool start and stop containers, build images, manage networks and orchestrate Swarm services without invoking the CLI. Typically reached over a Unix socket or TCP, with auth handled at the transport layer rather than in the spec. ## For AI agents Manage containers, images, networks, volumes, and Docker Swarm services on a Docker daemon as if you were the docker CLI itself. ## Scope Does not handle Kubernetes orchestration, host VM provisioning, registry hosting, or developer-machine GUI controls - use for managing a Docker daemon's containers, images and Swarm services only. ## Capabilities - Create, start, stop and inspect containers programmatically - Build, pull, tag and push images to and from a registry - Stream logs and exec commands inside a running container - Manage user-defined networks and attach containers to them - Create and mount volumes for persistent container data - Deploy and update Swarm services across a cluster - Manage Swarm nodes, secrets and configs for orchestration ## Use cases ### CI/CD Build and Deploy A CI runner can build images, run tests in throwaway containers and push images to a registry by hitting the Docker Engine API directly on the build host. POST /build creates the image, POST /containers/create plus /containers/{id}/start runs tests, and the runner can tear everything down on completion. Removes shell-out fragility from pipelines. Example prompt: POST /build with the build context tarball and tag, then POST /containers/create using the new image and start it with /containers/{id}/start to run a test command. ### Container Operations Tooling A platform team can build a custom ops dashboard that lists containers, shows live stats and drains nodes for maintenance using the Engine API. /containers/json gives the inventory, /containers/{id}/stats streams resource usage, and Swarm node endpoints handle drain and update operations. This avoids tying the dashboard to a specific container manager UI. Example prompt: GET /containers/json?all=true to list every container then GET /containers/{id}/stats?stream=false to capture a one-shot CPU and memory snapshot per container. ### Local Dev Environment Orchestration A developer-tool can spin up databases, message queues and supporting services on a developer's machine via the Engine API, without forcing them to write docker-compose files by hand. The tool creates the network, pulls images, starts containers with named volumes, and tears them down when the dev session ends. Example prompt: POST /networks/create for an app network, POST /containers/create for a postgres image attached to that network, then start it and verify with /containers/{id}/json. ### AI Agent DevOps Assistant Through Jentic, an AI agent embedded in a developer's workflow can answer 'why is the API container restarting?' or 'redeploy the worker service' by calling the Engine API. The agent searches Jentic for the relevant container or service intent, loads the operation and executes it against a configured Docker host. Useful for chat-driven ops and incident triage. Example prompt: Use Jentic to search 'inspect Docker container', load /containers/{id}/json, and execute it for a named container to retrieve its restart count and last exit code. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /containers/json | List containers | | POST | /containers/create | Create a new container | | POST | /build | Build an image from a build context | | GET | /_ping | Ping the Docker daemon for health | | POST | /commit | Create an image from a container | | POST | /auth | Check auth configuration with a registry | | GET | /configs | List Swarm configs | ## Key resources - **Containers** — Create, start, stop, inspect, exec into and remove containers - **Images** — Build, pull, tag, push and remove container images - **Networks** — Manage user-defined networks and container connections - **Volumes** — Create and mount persistent volumes for containers - **Swarm Services** — Deploy and update services across a Swarm cluster - **Nodes** — Manage worker and manager nodes in a Swarm - **Exec** — Run commands inside running containers ## Why Jentic - **Setup:** The Docker Engine API needs no bearer credential, so wiring it by hand mostly means reaching the daemon socket, handling any TLS, and passing registry auth through /auth yourself. Through Jentic you install once, import the Docker Engine API from the API Directory, and your agent calls it against your configured daemon. - **Permission scoping:** The Docker Engine surface can control a whole daemon, so scope your agent to the operations it needs, such as listing containers or building an image. You choose the operations it may call, so creating containers or committing images is not included unless you add them. - **Credential handling:** Your Docker daemon connection details and any registry credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'list Docker containers' or 'build an image', and Jentic returns the matching Engine operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **DigitalOcean API** — Provisions the VMs and Kubernetes clusters that host Docker workloads - **Kubernetes API** — Container orchestration API - alternative when scheduling spans many nodes rather than one Docker daemon - **AWS Lambda** — Run code without managing containers - alternative to Docker Engine for serverless workloads. - **GitHub REST API** — Build images from source repos before deploying with Docker Engine. ## FAQ ### What authentication does the Docker Engine API use? The Engine API itself does not define HTTP-level auth in the spec. Access is controlled by the transport - usually a Unix socket on the host, or a TLS-secured TCP socket configured on the daemon. Through Jentic, the connection details and any client certificates are stored in the vault rather than alongside agent code. ### Can I build an image with the Docker Engine API? Yes. POST /build accepts a tarball of the build context and a Dockerfile reference, returning a streaming response with build output. Pair it with POST /commit if you want to snapshot a running container into a new image instead. ### What are the rate limits for the Docker Engine API? The local Engine API has no enforced rate limit; throughput is bounded by the host's CPU, disk and the daemon's concurrency. Image pulls from Docker Hub do hit Hub's rate limits, so build pipelines should authenticate with /auth to lift anonymous pull caps. ### How do I exec a command in a container with the Docker Engine API through Jentic? Through Jentic, search 'docker exec command in container', load the exec create operation under /containers/{id}/exec, and execute with the command and AttachStdout flag. Jentic stores the daemon connection details so the agent never sees the raw socket path or TLS cert. ### Can I deploy a Swarm service with the Docker Engine API? Yes. POST /services/create deploys a new service from an image with replicas, networks and constraints. /services/{id}/update rolls out new versions and /nodes manages cluster membership. ### Is the Docker Engine API free? The Engine itself is free as part of Docker Engine open-source. Image pulls from Docker Hub follow Hub's pricing tiers, and Docker Desktop has its own commercial licensing for larger organisations. ### Can I limit what my agent is allowed to do with the Docker Engine API? Yes. Because Jentic One is self-hosted, you decide which Docker Engine operations your agent may call, so you can allow read-only actions like listing containers with GET /containers/json while withholding destructive ones. Creating containers, running exec commands, or committing images are not available to the agent unless you explicitly add those operations. Your daemon connection details and registry credentials stay in your own instance and are injected only at execution time, so the agent never handles them directly.