Docker and Docker Compose in Plesk — a step-by-step guide

Short answer: in Plesk, containers run through the Docker extension: you choose an image (e.g. from Docker Hub), set environment variables, port mapping, and volumes, then expose the container under a domain with a Docker Proxy Rules rule, using the domain's HTTPS certificate. Multi-container applications are described in a docker-compose.yml file and run as a stack. Important: in Plesk, containers are managed by the server administrator, and containers and their volumes are not included in Plesk backups.

The Docker extension in Plesk

The Docker extension adds a graphical interface to Plesk for the standard Docker Engine installed on the server. It lets you search for and pull images, run containers, set their parameters, view logs and resource usage, and run Docker Compose stacks. As of Plesk Obsidian 18.0.80, the extension also works on servers running CloudLinux 8 and 9.

Three things worth knowing before you start:

The administrator manages it. Clients and resellers don't have Docker access in Plesk, and service plans don't include a permission for it.
Containers aren't subject to account limits. They're not covered by the subscription's CPU and RAM limits (e.g. LVE in CloudLinux), so limits need to be set for each container individually.
Plesk backups don't cover them. Data in volumes needs to be secured with your own backup job.

Running a container step by step

In the Docker menu, open Images and search for an image, e.g. nginx, redis, or n8nio/n8n.
Choose a specific version (tag), not latest — that way an image update won't change how the application behaves without your knowledge.
Click Run. In the container settings, specify:
- Environment variables — the application's configuration (passwords, database addresses);
- Port mapping — manual, with internet access blocked (described below);
- Volume mapping — directories for persistent data;
- Memory limit;
- Automatic start after a system restart.
Start the container and check the logs tab.

Ports and network security

With automatic mapping, Docker publishes the container's port on all of the server's addresses — including the internet. Such ports can bypass the firewall rules managed by the panel. It's safer to:

turn off automatic mapping and set the port manually;
enable the option that blocks internet access to the port (the port then only listens on 127.0.0.1);
expose the application only through a domain and reverse proxy (next section).

Databases, Redis, and admin panels shouldn't have a public port.

Domain, reverse proxy, and HTTPS

To make the application in a container available at https://app.twojafirma.pl:

create a domain or subdomain and issue a Let's Encrypt certificate for it;
in the domain settings, open Docker Proxy Rules and add a rule: a URL path (e.g. /), the container, and its port;
Plesk adds a proxy_pass redirect to the container's port in the domain's nginx configuration — the domain handles HTTPS, and the container can just speak plain HTTP.

The proxy rule requires manual port mapping.

Volumes and persistent data

Anything a container writes to its own filesystem disappears when it's recreated (e.g. after an image update). Data that needs to survive — database files, uploaded files, configuration — should be stored in volumes, i.e. server directories mapped into the container. It's good practice to keep them in one directory, e.g. /var/www/vhosts/twojafirma.pl/docker/app/, outside the site's public directory. A container can write files owned by a different user (UID) than the subscription user — so don't map the httpdocs directory into a container.

Docker Compose: an example stack

A stack in Plesk is a docker-compose.yml file pasted into the editor, uploaded, or pointed to from the domain's directory. Here's an example application with a PostgreSQL database — with pinned versions, limits, and a port available only locally:

services:
  app:
    image: ghcr.io/twoja-firma/aplikacja:1.4.2
    restart: unless-stopped
    environment:
      DATABASE_URL: postgres://app:${DB_PASSWORD}@db:5432/app
      NODE_ENV: production
    ports:
      - "127.0.0.1:8080:3000"     # tylko lokalnie; na zewnątrz przez Docker Proxy Rules
    depends_on:
      - db
    mem_limit: 512m
    cpus: 0.5
    pids_limit: 256
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    mem_limit: 512m
    cpus: 0.5
    # bez sekcji ports: baza jest dostępna tylko dla kontenerów stosu

Keep passwords in an .env file next to the Compose file (outside your repository), not written directly into docker-compose.yml. You can start the stack (up, also pulling new images), stop it (stop), or remove it (down).

Backing up volumes

Plesk's backup doesn't cover containers, images, or volumes — not even the mapping configuration. The minimum safety net:

the docker-compose.yml file and a description of the configuration in your repository;
a regular database dump from the container, saved to a directory covered by the subscription backup:

docker compose exec -T db pg_dump -U app app | gzip > backup/app-$(date +%F).sql.gz

an archive of the volume directory with files (e.g. tar), taken while the application is stopped or using the application's own consistency mechanism;
a restore test — a backup nobody has restored is just a hope.

Resource limits, restart, and logs

Limits: you can set a memory limit in the panel; CPU, process count, and other limits are best described in the Compose file (mem_limit, cpus, pids_limit).
Restart: the restart: unless-stopped policy brings the container back up after a crash and after a server restart; the panel also has an automatic-start option.
Logs: viewable in the container's details. It's worth limiting log size so they don't fill up the disk.
Updates: change the image tag, pull it, and recreate the container. Data in volumes stays intact.

Common problems

The application works on its port but not under the domain — no Docker Proxy Rules rule, or automatic port mapping instead of manual.
Data disappeared after an update — it was being saved inside the container, not in a volume.
The container keeps restarting — a configuration error (missing variable, wrong database address) or an exceeded memory limit; check the logs.
The database port is visible from the internet — the port is published on all addresses; remove the mapping or restrict it to 127.0.0.1.
No permission to access files in a volume — the container runs as a different user (UID); set the directory owner according to the image's documentation.

FAQ

Can a hosting client run a container in Plesk themselves?

In Plesk, Docker management is only available to the server administrator, so on hosting, a container is usually started by the hosting provider.

Are containers included in the backup?

No. Plesk's backup doesn't cover containers or volumes — data needs to be secured separately.

Can I use an existing docker-compose.yml file?

Yes, as a stack. Before launching, pin the image versions, remove public database ports, and add resource limits.

Docker or the Node.js Toolkit?

A simple Node.js application works without a container, through the Node.js Toolkit. Docker makes sense when the application needs its own environment, several services at once, or a ready-made image from a vendor.

Technical verification: 17 September 2026, Plesk Obsidian 18.0.80 and Docker extension 2.x documentation. Docker hasn't been run on DoSieci servers yet. Related guides: Node.js applications in Plesk, PostgreSQL in Plesk. Packages: NVMe Performance and Pro.

Docker and Docker Compose in Plesk — how do I run a container?