Docker on cPanel and DirectAdmin — The Honest Truth

Verdict at the top: You cannot run Docker on shared hosting. Not on Domain India's, not on anyone else's. It is not a configuration problem, it is not a permissions issue, it is not something a support ticket can fix. 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, deploy artifacts to shared hosting; or upgrade 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.

cPanel and DirectAdmin shared accounts get the exact opposite of all of those. CloudLinux runs every shared account inside a per-user container of its own — called an LVE (Lightweight Virtual Environment) wrapped by CageFS. From inside that environment:

• 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 via WebSSH is not in that situation.

1. 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.

1. 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. It is sometimes how customers exhaust their inode quota in twenty minutes and then suspend their own account.

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

The recurring shape of the ticket

We don't get a "help, Docker won't install" ticket every day, but we see the same pattern at a steady rhythm — usually once or twice a month — and it always ends the same way. Anonymised, the typical flow:

Customer reads a Docker tutorial, sees docker run nginx in three lines and thinks "I can use this for my site". Logs into cPanel via Terminal (or WebSSH), runs docker --version — gets command not found. Tries curl -fsSL https://get.docker.com | sh — script fails on the first apt-get with permission denied. Searches StackOverflow, finds advice about extracting a Docker image manually. Downloads a 1.5 GB image tarball with wget, runs tar -xf image.tar. Twenty minutes later, the cPanel account is at 240,000 of its 250,000 inode quota, the file manager is unusable, and email accounts stop accepting new mail. Customer opens a ticket: "my site is down".

What we do at that point: increase the inode display in cPanel, point them at the offending tar-extracted directory, ask them to delete it. They do. Site is back. Then we have the conversation in this article.

The problem isn't malice or incompetence — the tutorials really are misleading, and "can I just try this" is a reasonable engineering instinct. We're writing this guide because the front-loaded honesty is more valuable than yet another tutorial that lets you find out the hard way.

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 — git pull on the cPanel side, or upload via FTP/SFTP. The shared-hosting cPanel runs PHP via FPM directly; no container involvement needed in production.
• Node.js apps using cPanel "Setup Node.js App" — develop locally with Docker, then push the source. cPanel's Phusion Passenger runs your Node app outside Docker.
• 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 via cPanel's "Setup Python App" which provisions a virtualenv.

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. cPanel's PHP build may have slightly different extensions enabled. We try to keep our cPanel/DirectAdmin builds aligned with mainstream Docker images, but check the phpinfo() of your hosting account 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 on production, the cleanest setup is: GitHub Actions (or any CI) builds your code in a Docker container in CI, then deploys the built output to shared hosting over SFTP or rsync. 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.
• After build, CI compresses the output and rsync's it (or SFTPs it) to your cPanel home directory.
• A post-deploy hook clears OPcache, runs migrations, and (for Laravel) runs artisan optimize.

You get reproducible builds, identical local-and-CI environments, and a deploy path that doesn't require Docker on the destination. We have a separate article for the GitHub-Actions-to-cPanel pipeline.

Pattern 3: 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 in three commands: curl -fsSL https://get.docker.com | sh, usermod -aG docker $USER, systemctl enable --now docker. Done.
• 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. A Domain India VPS Starter is ₹553/month (1 vCPU, 2 GB DDR4 RAM, 64 GB NVMe, 2 TB bandwidth) — enough to run a small stack in production with Docker. Compare that to fighting shared-hosting limitations for an app that has clearly outgrown them.

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 two or more long-running services that aren't your web application — Redis, an in-memory queue, a search index (Meilisearch, Typesense), a vector database, a separate websocket server.
• You need a specific runtime version that cPanel doesn't offer — Python 3.13, Node.js 22, Bun, Deno, or a niche language like Elixir, Rust, Go.
• Your app needs persistent background workers that exceed cPanel's process limits and aren't suitable for cPanel cron — Laravel Horizon, BullMQ, Sidekiq, Celery worker fleet, video transcoder, scheduled scraper.
• You need system-level libraries outside the cPanel/DA EasyApache build matrix — 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 cPanel features is fighting the platform.
• You need scheduled jobs more frequent than once per minute (cPanel cron is 1-minute granularity; some apps need every 10 seconds).
• You need outbound traffic guarantees — fixed IP, custom egress controls, predictable latency for AI API calls.

If exactly one of those is true, you might still squeeze it onto shared with care. If two are true, you'll spend more time fighting the platform than building.

Setting up Docker on a Domain India VPS — the 90-second version

If you've decided to move, here's the whole setup. SSH into your VPS as root (or a sudoer):

# Install Docker engine (Ubuntu/Debian)
curl -fsSL https://get.docker.com | sh

# Allow your normal user to run docker without sudo
usermod -aG docker $USER
newgrp docker

# 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 UFW or iptables. By default, your container ports may be exposed to the internet. We have a separate VPS-firewall guide; read it before exposing anything to port 80/443.
2. You're responsible for backups. Shared hosting includes JetBackup; your VPS does not unless you provision a backup add-on.
3. You're responsible for SSL. Use Caddy as a reverse proxy (auto-SSL via Let's Encrypt) or Nginx + certbot. Don't expose your container directly on 443 with a self-signed cert.

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.

`Account suspended` or your site shows a CloudLinux LVE-limit page

You've been killed by the per-account resource limit (typically nproc, the process count). Often happens when a customer tries to run a long-lived process (Docker daemon, queue worker, Node.js websocket server) on shared. Open a ticket — we'll release the suspension once.

What about Podman / Apptainer / udocker?

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

• Podman still needs subuid/subgid mappings and newuidmap setuid binary; CageFS doesn't expose these.
• Apptainer (formerly Singularity) can run as an unprivileged user, but only with kernel unprivileged_userns_clone enabled — disabled on CloudLinux for security reasons.
• 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: get a VPS.

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.

If your application is already a multi-service stack and you want help sizing the right VPS, [email protected] can advise. If you're somewhere in the middle and not sure whether you've crossed the threshold, send us your docker-compose.yml and we'll tell you straight.