Guide CyberPanel Docker Manager: Run an App on Your Domain With SSL (and a Firewall Trap)

Guide CyberPanel Docker Manager: Run an App on Your Domain With SSL (and a Firewall Trap) - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel)
+---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials)
+----- Forum: CyberPanel Docker & One-Click Apps Guides (https://adminsforum.com/Forum-cyberpanel-docker-one-click-apps-guides)
+----- Thread: Guide CyberPanel Docker Manager: Run an App on Your Domain With SSL (and a Firewall Trap) (/Thread-guide-cyberpanel-docker-manager-run-an-app-on-your-domain-with-ssl-and-a-firewall-trap)

CyberPanel Docker Manager: Run an App on Your Domain With SSL (and a Firewall Trap) - JAY - 10-27-2026

CyberPanel Docker Manager: Run an App on Your Domain With SSL (and a Firewall Trap)

CyberPanel 3.0 has a built-in Docker Manager, so you can run apps that don't fit in a normal PHP website: monitoring, n8n, a small API, anything that ships as a Docker image. We tested the whole path on our lab server (CyberPanel 3.0, Ubuntu 24.04, OpenLiteSpeed): install Docker, run Uptime Kuma in a container, and put it on its own domain with a real SSL certificate.

It works, but three things are not obvious from the screens:

A new container is not started and does not come back after a reboot until you change a setting.
Without a volume, your app's data lives only inside the container.
If you publish a port to the internet, Docker opens it even though CyberPanel's firewall doesn't list it.

Step 1: Install Docker
In the left menu open Server and then Docker (or go straight to

Code:

https://YOUR-SERVER-IP:8090/docker/

). On a fresh server it says Docker is not installed and shows an Install Docker button. Click it and wait; the log scrolls in the same box. It took about a minute on our VPS.

It installs Ubuntu's own packages:

Code:

docker.io

(Docker 29.1.3 for us) and the old Python

Code:

docker-compose

1.29.2. The newer

Code:

docker compose

(with a space) is not installed, so commands from tutorials that use it won't work until you add the

Code:

docker-compose-v2

package.

The Docker page after the install:
[Image: attachment.php?aid=597]

You get three buttons: Manage Containers, New Container and Manage Images.

Step 2: Pull the image
Open Manage Images, type the app name in Search Docker Hub and press Enter. Pick the right publisher: for Uptime Kuma the official image is

Code:

louislam/uptime-kuma

(the one above it is a third-party copy). Type a tag in Exact tag; we used

Code:

2

. If you leave it empty you get

Code:

latest

, which can jump to a new major version the next time you pull.

Search, choose the tag, Pull:
[Image: attachment.php?aid=598]

Click Pull. When it's done the image shows under Local Images.

Step 3: Create the container
Click Create Container, choose the image and tag, and click Create Container again. The form has four parts:

Container Name: short and simple, we used
Code:
uptime-kuma
. Owner:
Code:
admin
. Memory Limit: required; 512 MB is plenty for Uptime Kuma.
Port Mapping: the container port (3001) is filled in from the image. Type the Host Port (we used 3001 too). Leave Host IP at
Code:
127.0.0.1
; see Step 5 for why.
Environment Variables: also filled in from the image. Leave them unless the app's docs say otherwise.
Volume Mapping: empty by default. Add one (below).

Host IP and ports:
[Image: attachment.php?aid=599]

Add a volume. Click Add Volume. Host path: a folder on the server, for example

Code:

/opt/docker-data/uptime-kuma

(it's created for you). Container path: where the app keeps its data. For Uptime Kuma that's

Code:

/app/data

; for other apps look for "volumes" or "persistent data" in their docs.
Volume mapping, filled in:
[Image: attachment.php?aid=600]

Without this, the data sits inside the container. When you delete or re-create it (which is also how you update to a newer image), the new container starts empty.

Step 4: Start it, and make it survive a reboot
After Create Container the status said created, CPU and memory 0%, Restart Policy: No and Start on boot: Disabled. The container existed but wasn't running.
What we got right after clicking Create Container:
[Image: attachment.php?aid=601]

Scroll down to Container Actions and click Start. Then open Settings, tick Enable automatic startup and Save Settings. Leave the box "I understand that editing ENV or Volumes will recreate the container" unticked; you don't need it for this.
Container Settings with automatic startup ticked (Restart Policy changed to Yes in the background):
[Image: attachment.php?aid=602]

Check from SSH:

Code:

docker ps --format '{{.Names}} {{.Status}} {{.Ports}}'
docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' uptime-kuma

Ours:

Code:

uptime-kuma Up About a minute (healthy) 127.0.0.1:3001->3001/tcp

and restart policy

Code:

always

Code:

curl -sI http://127.0.0.1:3001

answered with a redirect to

Code:

/setup-database

, so the app was running.

Step 5: Don't publish container ports to the internet
The Host IP field says you can use

Code:

0.0.0.0

for public access. Before you do that, know this: Docker adds its own iptables rules and does not go through CyberPanel's firewall (firewalld). We started a test container on port 3999 with the default

Code:

0.0.0.0

. The firewall only allowed ssh, ftp and a few mail and web ports, and 3999 was not in the list. The port was still open from the internet.
Our test, with a throwaway container on port 3999:
[Image: attachment.php?aid=603]

And this is what anyone on the internet saw on port 3999:
[Image: attachment.php?aid=604]

That was a brand-new Uptime Kuma waiting for someone to create the admin account. Anyone who found it first could have taken it. We removed the test container right away.

So: keep Host IP at

Code:

127.0.0.1

and let the web server in front of it (next step) handle the public side, with SSL. If an app really must be reachable on its own port, limit it in Docker itself, not only in the CyberPanel firewall.

Step 6: Put the app on a domain with SSL
OpenLiteSpeed passes the requests on to the container. You need a normal CyberPanel website for the domain:

Add a DNS A record for the name (ours:
Code:
kuma.cyber.adminslab.com
) pointing to your server. If you use Cloudflare, set it to DNS only (grey cloud) until the certificate is issued.
Websites > Create Website with that domain (any PHP version, it isn't used).
Issue SSL for it. Ours was issued on the first try.

Now open the website: Websites > List Websites > Manage, tab Config. Two edits are needed.

a) vHost Conf. Click vHost Conf, scroll to the very bottom and add:

Code:

extprocessor uptimekuma {
  type                    proxy
  address                 127.0.0.1:3001
  maxConns                100
  pcKeepAliveTimeout      60
  initTimeout             60
  retryTimeout            0
  respBuffer              0
}

websocket /socket.io/ {
  address                 127.0.0.1:3001
}

Code:

uptimekuma

is just a name you pick; you use it again in the rewrite rule.

Code:

127.0.0.1:3001

is the Host IP and Host Port from Step 3. Click Save configuration.
The end of our vHost Conf:
[Image: attachment.php?aid=606]

b) Rewrite Rules. Click Rewrite Rules. On a new website the box wasn't empty: it showed an error text,

Code:

cat: /home/kuma.cyber.adminslab.com/public_html/.htaccess: No such file or directory

. Delete that text first, or it ends up in your .htaccess file. Then paste:

Code:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
RewriteRule ^(.*)$ http://uptimekuma/$1 [P,L]

The first rule sends visitors from http to https. The last one passes everything to the

Code:

uptimekuma

proxy from the vHost Conf. Click Save Rewrite Rules.
Our rewrite rules:
[Image: attachment.php?aid=607]

Test from SSH:

Code:

curl -sI http://kuma.cyber.adminslab.com/ | head -3
curl -sI https://kuma.cyber.adminslab.com/ | head -3

We got a

Code:

301

to https, then

Code:

HTTP/2 302

with

Code:

location: /setup-database

. That redirect comes from Uptime Kuma itself, so the proxy works.

Why the websocket block matters
Many apps (Uptime Kuma, n8n, chat apps, anything "live") use WebSockets. The rewrite rule above does not pass them on; only the

Code:

websocket

block in the vHost Conf does. Without it the page loads, but the dashboard stays empty or keeps "reconnecting". We tested a WebSocket connection to

Code:

wss://kuma.cyber.adminslab.com/socket.io/

with and without the block (our

Code:

wstest

is a tiny Node.js script that opens the connection and prints the first message):
With and without the websocket block:
[Image: attachment.php?aid=608]

Without the block:

Code:

non-101 status code

(refused). With it: the app's first WebSocket message. If your app uses a different WebSocket path, use that path instead of

Code:

/socket.io/

, or

Code:

/

for all of them.

Step 7: Finish the app's setup right away
As soon as the domain works, the app's setup page is public. Open your domain and create the admin account immediately. For Uptime Kuma: choose the database (SQLite is fine for small setups), then create the admin user.

Updating the app without losing data
Pull the new tag in Manage Images, then re-create the container with the same settings and the same volume. The data lives in the host folder, not in the container. We tested exactly that from SSH: deleted the container and ran a new one with the same volume. Uptime Kuma went straight to its dashboard instead of the setup page, and the database files were still there:
Delete and re-create, data still there:
[Image: attachment.php?aid=609]

The equivalent command, if you prefer SSH:

Code:

docker run -d --name uptime-kuma --restart always -m 512m \
  -p 127.0.0.1:3001:3001 -v /opt/docker-data/uptime-kuma:/app/data \
  louislam/uptime-kuma:2

Back up the host folder (

Code:

/opt/docker-data/...

) like any other data. CyberPanel's website backups don't include it.

Troubleshooting

503 on the domain: the container isn't running (we got exactly that after
Code:
docker stop
). Start it, and check Enable automatic startup.
Status "created", nothing happens: you didn't press Start (Step 4).
Page loads but the dashboard is empty or keeps reconnecting: the
Code:
websocket
block is missing or has the wrong path.
Data gone after an update: no volume mapping. Check with
Code:
docker inspect -f '{{json .Mounts}}' NAME
.
SSL won't issue: the A record must point to your server and, with Cloudflare, be DNS only during issuing.
docker compose: command not found: CyberPanel installs the old
Code:
docker-compose
(with a dash). Install
Code:
docker-compose-v2
for the new syntax.

More CyberPanel guides

Tested with CyberPanel 3.0 (Docker Manager), Docker 29.1.3 and Uptime Kuma 2 on Ubuntu 24.04 with OpenLiteSpeed, October 2026. The same steps work for other web apps in Docker; only the port, the data path and the WebSocket path change.