The podman system service command starts a REST endpoint that accepts container-management requests. It supports rootful and rootless operation, listens on a configured UNIX or TCP socket, and can serve local or remote clients. section 9.1 section 9.0
Unlike Docker’s centralized daemon, Podman can manage the same containers and images without the service. Socket activation also avoids a permanent daemon: systemd starts the service on connection, and it exits five seconds after the last connection. section 9.1 section 9.1.1
The service exposes two REST interfaces over the socket:
- The compatibility API implements the released Docker API except for Swarm endpoints, allowing Docker clients and legacy tooling to work with Podman. section 9.2 section 9.3.1
- The native Libpod API exposes Podman-specific features such as pods and is recommended for new Podman integrations. section 9.2 section 9.3.2
- Remote Podman clients use the REST API through SSH; the --remote command presents the ordinary Podman CLI while executing operations on the server. section 9.5.2 section 9.5
Enable a rootless socket and probe the API
systemctl --user enable --now podman.socket curl -s --unix-socket $XDG_RUNTIME_DIR/podman/podman.sock http://d/v1.0.0/libpod/version | jq The rootless socket normally resides at $XDG_RUNTIME_DIR/podman/podman.sock. A Docker-compatible client can instead use DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock, enabling docker-py or docker-compose to address Podman. section 9.1.1 section 9.3.1 section 9.4
Table 9.1 Default locations for the podman.socket (view table figure)
Compare the default rootful and rootless podman.socket locations before configuring clients or systemd connections. section 9.1
