Docker on cPanel and DirectAdmin — The Honest Truth

Verdict at the top: you cannot run Docker on shared hosting. Not on Domain India's, and not on any conventional shared host. It is not a configuration problem or a permissions setting, and it is not something a support ticket can change. If you came here looking for "how to install Docker on cPanel" or "Docker on DirectAdmin shared", the answer is no — and if any tutorial tells you otherwise, close that tab.

This article explains exactly why, what people typically try anyway (and how it ends), and what your real options are: keep building with Docker on your laptop and deploy the built artifacts to shared hosting, run your Dockerfile on the App Platform, or move to a VPS and run Docker properly.

Why Docker can't run on shared hosting

Docker isn't an application; it's a thin wrapper around Linux kernel features. To start a container, the Docker daemon needs:

• CAP_SYS_ADMIN — the most powerful Linux capability. Lets a process create new mount points, manipulate the kernel keyring, set hostnames, and configure network interfaces.
• Mount namespaces — to give the container its own filesystem view.
• PID namespaces — to give the container its own process tree (so PID 1 inside is your app, not the host's init).
• Network namespaces — to give the container its own network stack.
• cgroup controllers (write access) — to enforce CPU/memory/IO limits per container.
• A long-lived daemon process running as root or via a privileged socket.

Shared hosting accounts get the exact opposite of all of those. On Domain India's cPanel and DirectAdmin servers, CloudLinux runs every account inside its own LVE (Lightweight Virtual Environment), with CageFS isolating the file system. Webuzo accounts are ordinary unprivileged users too. From inside a shared account:

• You are not root.
• You cannot create new mount or network namespaces; the syscalls return EPERM.
• You cannot write to cgroups; CloudLinux already owns that subtree.
• You cannot run a daemon with CAP_SYS_ADMIN; CageFS strips capabilities at process spawn.
• You cannot install kernel modules.
• You cannot run a process as anyone other than your own UID.

Docker is, fundamentally, a tool that requests all of those privileges. A shared-hosting environment is, fundamentally, a system that denies all of those privileges. The two are designed to be mutually exclusive.

This is the same reason you can't run Docker inside another Docker container without the --privileged flag. CloudLinux wraps every shared account in something architecturally similar to a non-privileged container, and there is no --privileged you can pass — it's enforced by the host system, not your account.

Why the existing tutorials are wrong

Search "Docker on cPanel" and you'll find blog posts that look authoritative. They usually fall into one of three traps:

1. They're talking about WHM root, not cPanel user. Some VPS / dedicated server admins running cPanel on their own machine can install Docker — because they have root on the machine. That isn't "Docker on cPanel"; that's "Docker on a server that happens to also have cPanel". A shared-hosting customer logging in over jailed SSH is not in that situation.
2. They're describing rootless tools that aren't really Docker. udocker, Singularity (now Apptainer) and similar projects let you extract image filesystems and chroot into them as a regular user. They cannot run a Docker daemon, cannot use most Docker images that require root inside the container (most do), and don't give you the isolation, networking, or volume features that are the point of Docker. They are filesystem-extraction toys, not container runtimes.
3. They're outright misleading. Some "guides" tell you to extract a Docker image with tar, then run the binaries inside it directly with PHP exec. This is not Docker, and on Domain India shared hosting exec and similar functions are disabled anyway. It is a quick way to use up your account's file (inode) allowance.

Trust nothing on this topic that isn't honest about the kernel-level barriers.

How the attempt usually goes

The pattern is predictable:

A developer reads a Docker tutorial, sees docker run nginx in three lines and thinks "I can use this for my site". They open the jailed shell, run docker --version and get command not found. They try curl -fsSL https://get.docker.com | sh, which fails at once because there is no root and no package manager. They find advice about extracting a Docker image by hand, download a large image tarball and run tar -xf image.tar. A few minutes later the account is near its disk or file-count limit, the file manager is slow, and mail may stop arriving. The site goes down.

The fix is to delete the extracted directory (cPanel's Disk Usage tool shows the largest folders under your home). The problem isn't incompetence: the tutorials really are misleading, and "can I just try this" is a reasonable engineering instinct. This guide exists so you can skip that afternoon.

What you should actually do — three patterns

Pattern 1: Docker for local development, deploy plain artifacts

This is what we recommend for almost every shared-hosting customer who's heard about Docker. Use Docker on your laptop to get the same PHP / Node / Python / MySQL versions your hosting account has. Build, test, and develop locally. When deploying:

• PHP / Laravel / WordPress projects — upload with FTP/SFTP, or git pull over SSH (jailed SSH is off by default; ask support to enable it). Composer can't run on shared hosting, so run composer install locally or in CI and upload the project with vendor/. PHP runs natively on the server; no container is involved in production.
• Node.js apps — develop locally with Docker, then deploy with "Setup Node.js App" on cPanel or DirectAdmin, which runs your app through Phusion Passenger. See Deploy a Node.js app on shared hosting.
• Static front-ends (React, Vue, Next.js export, Astro) — npm run build locally, upload the dist/ or out/ folder.
• Python (Flask/Django) — develop in Docker locally, deploy with "Setup Python App" on cPanel or DirectAdmin, which creates a virtualenv. See Deploy a Python app on shared hosting.

Your docker-compose.yml becomes the source of truth for your dev environment. It never goes near production.

What you give up: production isn't a 1:1 mirror of your dev environment. The hosting PHP build has its own set of extensions and some functions are disabled (see PHP disabled functions on shared hosting). phpinfo() is disabled on cPanel, so compare extensions with a small script that prints get_loaded_extensions(), or run php -m in the jailed shell, against your Docker image's php -m output before assuming parity.

Pattern 2: Build artifacts in CI, deploy via SSH/Git/FTP

For teams that want reproducible builds without running Docker in production, the cleanest setup is: GitHub Actions (or any CI) builds your code in a Docker container, then deploys the built output to shared hosting. The CI uses Docker; the production server doesn't need to.

Typical workflow:

• CI runs your build inside the same Docker image you use locally, including composer install or npm run build.
• CI packs the output into an archive and uploads it over SFTP or scp (rsync is not available in the jailed shell), or over FTPS if SSH isn't enabled.
• Over SSH, a short script unpacks the archive and, for Laravel, runs php artisan migrate --force and php artisan optimize.

You get reproducible builds and a deploy path that doesn't need Docker on the destination. See GitHub Actions deploys to cPanel for a full pipeline.

Pattern 3: Run your Dockerfile on the App Platform

If your app is a single web service with a Dockerfile, the Domain India App Platform can build and run it for you: Node.js apps are detected automatically, and every other language runs from your own Dockerfile. PostgreSQL and free SSL are included on every plan. You deploy with Deploy Now or a deploy token from CI; there is no automatic deploy on every push. It is not a general Docker host: there is no SSH, no Docker Compose stack, no Redis add-on and no WebSocket support.

Pattern 4: Move to a VPS

If your application is genuinely a multi-service stack — app + Redis + MySQL + queue worker + scheduled jobs — you've outgrown shared hosting. A VPS is the right answer. On a VPS:

• You have root.
• You can install Docker Engine from Docker's official repository in a few commands (below).
• You can run docker compose up -d and have your whole stack online.
• You can update kernel, install monitoring, configure firewall — all the things you can't do on shared.

The cost gap is smaller than people expect: Domain India VPS plans start at ₹553 a month, excluding 18% GST (list price, 30 September 2026). A Domain India VPS is self-managed, with full root access on KVM virtualisation.

The threshold — when does it become "you need a VPS"?

Concrete signals. If two or more of these are true, you've reached the upgrade point:

• You need any long-running service besides your web application — Redis (not available on any shared plan), a queue, a search index (Meilisearch, Typesense), a vector database, a WebSocket server. Long-running processes are stopped on shared hosting.
• You need a runtime the panel tools don't offer — Bun, Deno, Go, Rust, Elixir, or a Node.js or Python version that isn't in the panel's list.
• Your app needs persistent background workers — Laravel Horizon, BullMQ, Sidekiq, a Celery worker fleet, a video transcoder.
• You need system-level libraries outside the server's standard build — ImageMagick with specific delegates, FFmpeg with non-default encoders, custom OpenSSL.
• Your deployment is docker-compose.yml and your team treats that file as the source of truth. Trying to map it onto control-panel features is fighting the platform.
• You need scheduled jobs more often than every 4 minutes. On Domain India shared hosting, cron jobs set to run every 1, 2 or 3 minutes are changed to every 4 minutes.
• You need your own IP address or egress controls. A shared hosting account's IP can't be changed.

The first three are hard limits: any one of them means shared hosting won't work. For the rest, if two are true, you'll spend more time fighting the platform than building.

Setting up Docker on a Domain India VPS — the short version

If you've decided to move, here's the whole setup. SSH into your VPS as root (or a sudo user). Use the commands for the operating system you installed:

# AlmaLinux / Rocky Linux (RHEL-compatible)
sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker

# Ubuntu / Debian: Docker's convenience script
curl -fsSL https://get.docker.com | sudo sh

# Allow your normal user to run docker without sudo (log out and back in afterwards)
sudo usermod -aG docker "$USER"

# Confirm
docker --version
docker run --rm hello-world

That's it. You now have Docker. From here, your existing docker-compose.yml runs unchanged:

cd /home/myapp
git clone https://github.com/me/myapp.git
cd myapp
docker compose up -d

If you came from cPanel/DA shared, three things will feel different:

1. You're responsible for the firewall. Configure firewalld or UFW, and remember that ports published with -p 8080:80 are opened by Docker's own firewall rules, which can bypass UFW. Publish internal services on 127.0.0.1 only (-p 127.0.0.1:8080:80). Read the VPS security checklist before exposing anything.
2. You're responsible for backups. Domain India's cPanel and DirectAdmin plans include weekly JetBackup copies, but a VPS includes no backups or snapshots. Back up your volumes and databases to storage outside the VPS yourself.
3. You're responsible for SSL. Use Caddy as a reverse proxy (automatic Let's Encrypt certificates) or nginx with certbot. Don't expose your container directly on 443 with a self-signed certificate.

This is more work than shared, but it's what you wanted when you wanted Docker.

Common errors and what they actually mean

When customers do try Docker on shared hosting anyway, they hit a small set of error messages. Verbatim strings — Google indexes these and someone troubleshooting will find this page.

docker: command not found You're on a shared hosting account and Docker is not installed. It cannot be installed by you. This is not a bug.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? You installed the Docker client somehow (perhaps via NodeSource or a package manager that succeeded), but you cannot start the Docker daemon — that needs root and CAP_SYS_ADMIN, which you don't have. The client is useless without the daemon.

permission denied while trying to connect to the Docker daemon socket Same as above on a different stage of the same problem.

Error response from daemon: cgroups: cgroup mountpoint does not exist: unknown You're running inside a container (probably CloudLinux's LVE) and trying to nest another container without the privilege to do so. Not fixable on shared.

runc: exec failed: write /sys/fs/cgroup/...: no space left on device Same root cause, different symptom — you're inside a sandboxed cgroup and can't write a child cgroup.

tar: ./var/lib/docker/...: Cannot mknod: Operation not permitted You're trying to extract a Docker image's filesystem manually. The image contains device nodes (/dev/null, /dev/zero etc) that require root. Don't do this — it's not a path forward.

disk quota exceeded or No space left on device during tar -xf of a Docker image You've hit either the disk-space quota or, more often, the inode quota of your shared account. Delete the extracted directory immediately. cPanel → Disk Usage → look for the largest folder under your home; that's it.

Your site shows a 508 or 503 error, or a "resource limit is reached" page The account hit its per-account limits: entry processes give a 508, memory and process limits give 500 or 503. This often happens when someone tries to run a long-lived process (a daemon, a queue worker, a WebSocket server) on shared hosting; such processes are stopped anyway. Stop what you started and read the resource limit guide.

What about Podman / Apptainer / udocker?

Three rootless container tools exist. None of them are practical on shared hosting:

• Podman in rootless mode still needs subuid/subgid mappings and the setuid newuidmap helper, which a jailed shared account doesn't provide.
• Apptainer (formerly Singularity) can run as an unprivileged user, but only where the kernel allows unprivileged user namespaces and the tools are installed; neither is something a shared account can set up.
• udocker is the closest to "works on shared". It's a Python script that downloads images and runs them via proot or runc in user mode. It works for the most basic single-process images but fails on anything that expects networking, port binding, or system services. It's a research/HPC tool, not a production hosting solution.

If you're determined to run any kind of containerised workload, the answer is still: the App Platform for a single Dockerfile app, or a VPS for anything more.

Frequently asked questions

When you're ready

Build on your laptop. Deploy to shared until your app outgrows it. Move to a VPS the moment two of the threshold signals above are true. Don't fight the platform — every hour spent trying to make Docker work on cPanel is an hour you're not building your product.

Ready to move? Compare VPS plans or the App Platform, and if you're unsure which fits, ask on 24/7 live chat or open a support ticket. Tickets get a first response within 15 minutes; there is no phone support.