ISPmanager 6 lets you manage Docker containers alongside regular sites on the same server: the panel deploys the module, and after that containers are created and maintained either through the web interface or directly via docker over SSH. This section covers installation, creating a container, common errors, and the point past which container management is better handled outside the panel.

Installing the Docker module for ISPmanager

# Installation via CLI
ispmanager plugin.install docker

# Or via the interface:
# ISPmanager → App Store → Docker

The module installs Docker Engine itself if it is not already on the system, and adds a container management section to the panel. This is a separate package, not part of the base installation — if the section does not appear in the menu after installing, check the license: the Docker module is not available in every ISPmanager edition. Installation takes a couple of minutes and requires a panel restart before the interface picks up the new menu item.

Creating a container via ISPmanager

After installing the module: Tools → Docker → Containers → Create

Image: nginx:alpine
Ports: 8080:80
Volumes: /var/www/myapp:/usr/share/nginx/html:ro
Restart: always

Container creation fields

Field	What it means
Image	Image name and tag from Docker Hub or a private registry
Ports	Mapping host_port:container_port
Volumes	Mapping host_dir:container_dir, the `:ro` suffix means read-only
Restart	Restart policy: no / always / on-failure / unless-stopped

Managing via CLI

# ISPmanager stores configs in /etc/ispmgr/docker/
docker ps --format "table {{.Names}}	{{.Status}}	{{.Ports}}"

# Container logs
docker logs -f mycontainer --tail 100

Containers created through the panel remain ordinary Docker containers: they show up in docker ps and can be restarted with standard commands. The panel only keeps a declarative description alongside its own configuration so it can restore state after a server reboot. This is convenient for troubleshooting: if a container misbehaves, there's no need to go back to the web interface — every standard Docker command works directly from SSH.

Common errors when working with containers

Message	What it means
`Error: bind: address already in use`	The host port is already taken by another process or container — for example, the server's own Apache/Nginx listening on port 80
`Error response from daemon: pull access denied`	The image was not found in the public registry, or authorization is required for a private registry
`Cannot connect to the Docker daemon`	The `docker` service is not running, or the panel user is not in the `docker` group
Container stuck in `Restarting` loop	The process inside the container crashes right after starting — check `docker logs`, usually an application config error

Docker Manager in ISPmanager vs. plain CLI: comparison

Criterion	Via ISPmanager	Via CLI directly
Speed of creating one container	Faster for simple scenarios	Faster for repeated tasks with scripts
Docker Compose (multi-service stack)	Pro edition only	Always available
Configuration versioning	No built-in support	docker-compose.yml can be kept in git
Access for a client without SSH	Yes — via the web interface	No, SSH access is required

When managing through ISPmanager is not the right fit

You need a full orchestrator with scaling and health checks — that's a job for Docker Swarm or Kubernetes, not a hosting panel
The stack has 5+ linked services with networks and startup dependencies — managing that through separate container cards in a UI is impractical; you need docker-compose or a dedicated CI/CD pipeline
You need automatic CI/CD that rebuilds the image on every commit — the panel does not replace a build pipeline
Containers are critical for uptime and you need monitoring with alerts — use dedicated tools (Prometheus, Grafana), since ISPmanager's Docker Manager does not provide this
Several servers need to act as a single cluster with shared state — the panel manages containers only on the server it is installed on, with no clustering between nodes

Verifying the result

After creating a container, confirm it is not merely in the Up state but actually responds on the mapped port.

# Container status
docker ps --filter "name=mycontainer"

# Check that the port really responds
curl -I http://127.0.0.1:8080/

If curl hangs or returns Connection refused while the status is Up, check that the application inside the container listens on 0.0.0.0 rather than 127.0.0.1 — in the latter case, the port mapping from the host will never reach the process. Also check the volumes: files changed inside the container should show up on the host as well. A related topic is running Node.js and Python applications in ISPmanager without containers.