How to Install & Harden a Self-Hosted Control Panel on Netcup: Coolify v4, CloudPanel v2 & HestiaCP

Before executing an installation script, match the control panel’s underlying architecture to your workload. A common operational mistake is installing HestiaCP when you actually need containerized Next.js/Go deployments with Git webhook previews, or installing Coolify on a constrained 2 GB VPS where concurrent Nixpacks or Dockerfile builds will exhaust system RAM.

Each of the three panels mutates your base Ubuntu 24.04 LTS or Debian 12 system in fundamentally different ways. Coolify v4 keeps the host OS clean and runs its entire control plane (coolify, coolify-db PostgreSQL, coolify-redis, coolify-realtime Soketi, and coolify-proxy Traefik/Caddy) inside Docker containers under /data/coolify. CloudPanel v2 and HestiaCP, by contrast, install native systemd daemons (nginx, php8.3-fpm, mariadb, and for HestiaCP exim4/dovecot) directly onto the host filesystem. Because their package trees and port bindings conflict directly, you must always start from a freshly provisioned Netcup SCP OS image and never attempt to layer two panels onto the same host.

Coolify v4 transforms an 8 GB RAM Netcup VPS 1000 G12.5 or dedicated-core RS 1000 G12.5 into a full Platform-as-a-Service capable of building and running Next.js, Astro, Go, Python, Rust, and Laravel applications alongside one-click PostgreSQL, MySQL, Redis, Dragonfly, and MongoDB instances.

Because Coolify’s installer provisions Docker Engine and starts an unauthenticated onboarding screen on port 8000/tcp alongside a Soketi WebSocket server on port 6001/tcp, never leave port 8000 open to the public internet during installation. Even if you configure ufw first, remember that Docker’s DOCKER iptables chain inserts DNAT rules in PREROUTING before UFW’s INPUT filter. Complete your initial registration over a localhost SSH tunnel (ssh -L 8000:127.0.0.1:8000), configure an HTTPS instance domain (https://coolify.example.com) routed through Coolify’s built-in Traefik/Caddy proxy, and block ports 8000 and 6001 at the upstream Netcup SCP Firewall.

During Git-triggered deployments, Coolify’s Nixpacks or Dockerfile builder compiles TypeScript/Webpack bundles or Rust crates inside temporary build containers. On an 8 GB server already running PostgreSQL and Redis, two concurrent Next.js builds can spike memory demand by 4–5 GB. Provisioning a 4 GB swapfile on Netcup’s NVMe storage with vm.swappiness=10 provides an essential safety buffer that prevents the Linux kernel OOM killer from terminating live database containers during build peaks.

# 1. Prepare clean Ubuntu 24.04 system and configure UFW BEFORE running Coolify
sudo apt update && sudo apt full-upgrade -y
sudo apt install -y curl wget git jq ufw

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'Traefik HTTP'
sudo ufw allow 443/tcp comment 'Traefik HTTPS'
sudo ufw allow 443/udp comment 'Traefik HTTP/3'
sudo ufw --force enable

# 2. Download and inspect the official Coolify v4 installation script
curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o /tmp/install-coolify.sh
less /tmp/install-coolify.sh

# 3. Execute the audited installer as root
sudo bash /tmp/install-coolify.sh

# 4. Block Docker from exposing port 8000 (Coolify UI) and 6001/6002 (Soketi Realtime) publicly
# Access initial setup safely from your laptop via SSH tunnel:
# ssh -L 8000:127.0.0.1:8000 root@YOUR_NETCUP_IP -> open http://localhost:8000

# Concurrent Nixpacks / Next.js / Rust builds inside Coolify can spike RAM usage.
# Create a 4 GB swapfile on Netcup's fast NVMe storage with conservative swappiness=10:
sudo fallocate -l 4G /swapfile
sudo chmod 0600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system
free -h

               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.1Gi       5.4Gi        24Mi       1.3Gi       6.4Gi
Swap:          4.0Gi          0B       4.0Gi

If your workload centers on WordPress, WooCommerce, Magento, Laravel, Symfony, or Node.js/Python apps and you want maximum raw requests-per-second throughput without containerization overhead, CloudPanel v2 is purpose-built for Debian 12 and Ubuntu 24.04. It installs native Nginx with Brotli/Zstd compression, simultaneous PHP-FPM 7.1 through 8.4 worker pools, Redis object caching, Varnish page caching, and MySQL 8.0 or MariaDB 10.11/11.4.

From a security engineering perspective, CloudPanel v2’s strongest feature is strict per-site Linux system user isolation. When you create a site inside CloudPanel, it provisions a dedicated Linux account (/home/<site-user>) with strict 0750 directory permissions and binds that site’s PHP-FPM socket (listen.owner and user = <site-user>) exclusively to that UID. If one outdated WordPress plugin suffers a remote code execution vulnerability, the attacker is confined to that single /home/<site-user> directory tree and cannot read /home/<other-site>/wp-config.php.

# 1. Update base packages on a clean Ubuntu 24.04 LTS Netcup server
sudo apt update && sudo apt -y upgrade
sudo apt -y install curl wget sudo

# 2. Download the official CloudPanel installer and inspect it
curl -sS https://installer.cloudpanel.io/ce/v2/install.sh -o /tmp/install-cloudpanel.sh
head -n 45 /tmp/install-cloudpanel.sh

# 3. Run the installer selecting MariaDB 11.4 (or MYSQL_8.0) as the database engine
sudo DB_ENGINE=MARIADB_11.4 bash /tmp/install-cloudpanel.sh

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The installation of CloudPanel is complete!
CloudPanel can be accessed now: https://203.0.113.10:8443
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When you need a traditional multi-user control panel that combines Nginx + PHP-FPM web hosting with a complete self-hosted email suite (Exim4 SMTP, Dovecot IMAP/POP3, Roundcube Webmail, Sieve server-side mail filters, and automatic 2048-bit DKIM signing), HestiaCP is the most resource-efficient open-source choice.

Before using HestiaCP for outbound email on a Netcup VPS or Root Server, you must configure Forward-Confirmed Reverse DNS (FCrDNS). First create A and AAAA records for your mail hostname (e.g., mail.example.com) pointing to your server’s IPv4 and primary IPv6 (::1) addresses, then set the exact matching Reverse DNS (PTR) hostname for both IPv4 and IPv6 inside the Netcup Server Control Panel (SCP -> Network -> Reverse DNS). Without symmetric IPv4 and IPv6 PTR records alongside SPF, DKIM, and DMARC (v=DMARC1; p=quarantine;) TXT records, Gmail and Microsoft 365 will immediately reject outbound messages on port 25.

When invoking HestiaCP’s installer (hst-install.sh) on a 4 GB or 8 GB Netcup VPS, pass --apache no (using native Nginx + PHP-FPM directly rather than legacy Nginx-to-Apache reverse proxying) and --clamav no. The ClamAV antivirus daemon loads a viral signature database into resident memory that consumes 1.1 GB to 1.4 GB of constant RSS RAM; omitting ClamAV while keeping SpamAssassin and Fail2ban active keeps HestiaCP’s entire idle footprint around 520 MB.

# 1. Download official HestiaCP release installer
wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh -O /tmp/hst-install.sh
less /tmp/hst-install.sh

# 2. Run installer with Nginx + Multi-PHP + MariaDB + Exim4 + Dovecot + Sieve
# Note: Omit ClamAV (--clamav no) on <=4GB VPS instances to save ~1.1 GB of constant RAM usage
sudo bash /tmp/hst-install.sh \
  --nginx yes \
  --apache no \
  --phpfpm yes \
  --multiphp yes \
  --named no \
  --mysql yes \
  --exim yes \
  --dovecot yes \
  --sieve yes \
  --clamav no \
  --spamassassin yes \
  --iptables yes \
  --fail2ban yes \
  --hostname panel.example.com \
  --email [email protected] \
  --port 8083

Regardless of whether you chose Coolify (8000), CloudPanel (8443), or HestiaCP (8083), leaving the raw administrative port open to 0.0.0.0/0 exposes your login endpoint to continuous credential-stuffing and zero-day vulnerability scanners.

Because Netcup’s Server Control Panel (SCP) Stateful Firewall operates at the hypervisor bridge layer outside your VM, it enforces packet filtering even on ports published by Docker containers (like Coolify’s port 8000 and 6001). Configure the SCP Firewall policy to restrict management ports to your static admin IP or WireGuard VPN subnet (10.66.66.0/24), and schedule each panel’s native CLI backup tool (clpctl backup:run, v-backup-users, or pg_dump on coolify-db) to feed into your off-site Restic repository:

# --- Option A: Coolify v4 (Verify internal PostgreSQL control-plane dump) ---
sudo docker exec coolify-db pg_dump -U coolify -d coolify -Fc > /var/backups/coolify-control-plane.pgdump
ls -lh /var/backups/coolify-control-plane.pgdump

# --- Option B: CloudPanel v2 (Run clpctl native site & database backup) ---
sudo clpctl backup:run --ignoreDatabases=no
ls -la /home/*/backups/

# --- Option C: HestiaCP (Run v-backup-users and verify /backup tarballs) ---
sudo /usr/local/hestia/bin/v-backup-users
ls -lh /backup/