CloudPanel , the open-source panel from MGT-COMMERCE, has been settling into that gap for the last couple of years. The community edition is the only edition, which is a refreshing change from the freemium pattern. As of v2.5.3 (December 2025) it sits at roughly 1.8k stars on GitHub and ships cloud images for every major hyperscaler. We have been running it on a VPS in our Bucharest datacenter for several weeks. This is the field report.

What CloudPanel actually is

Architecturally, CloudPanel is a thin management layer over a hardened Nginx, PHP-FPM, MySQL or MariaDB stack. It is not its own web server, not its own database, not a Docker swarm or a Kubernetes wrapper. The panel writes Nginx vhosts, manages PHP-FPM pools per site, provisions Linux users so each site is isolated at the OS level, and exposes a UI to do all of that without you remembering the exact php-fpm config knob you wanted last Tuesday.

If that sounds dull, that is the point. The interesting design decision in CloudPanel is what it does not try to be: it is not a hosting reseller platform, not a billing system, not a mail server, not a DNS authoritative server. Those omissions are deliberate, and they are also the first thing to understand before you adopt it.

The stack you get

• Web tier: Nginx, configured as the front for every site. There is no Apache option.
• PHP: multiple versions installed in parallel (7.x and 8.x), switchable per site with a click. Running an old PrestaShop on 7.4 next to a Laravel 11 app on 8.3 on the same box is a non-event.
• Databases: MySQL 8.4, 8.0, 5.7 or MariaDB 11.8, 11.4, 10.11, 10.6. You pick one at install time via a DB_ENGINE variable, the rest are not installed.
• Application types: PHP, Node.js, Python, static sites, and reverse-proxy passthroughs (handy for putting a panel-managed Nginx in front of an app you run elsewhere).
• TLS: Let’s Encrypt baked in, with HTTP-01 validation and auto-renewal.

The control plane itself is a Symfony PHP app behind its own Nginx vhost on port 8443. That single port is the entire management surface; close it to the world and the only people who can touch the panel are people on your management network.

What you get out of the box

The community edition (which, again, is the only edition) ships with:

• Site isolation at the OS level. Each site gets its own Linux user, its own PHP-FPM pool, its own home directory. A compromised WordPress on site A does not have read access to site B’s files. This is the single feature that matters most for shared environments.
• Free Let’s Encrypt SSL, one click per site, auto-renewed by cron.
• UFW firewall management with a sane default policy and a UI to add rules.
• Two-factor authentication for the panel admin, TOTP based.
• IP and Bot blocker, which lets you blacklist user agents and IP ranges without dropping into Nginx config.
• Cloudflare integration, primarily for trusting the right X-Forwarded-For chain so your access logs are not full of Cloudflare edge IPs.
• Vhost templates per app type, pre-configured for WordPress, Magento, Symfony, Node, generic PHP, and so on. The templates are sensible (gzip, brotli, security headers) and editable.
• Per-site cron, FTP, file manager, and database management UI.
• Backup destinations to S3-compatible buckets, including MinIO and Backblaze B2, configurable per site.

What it does not ship: a mail server, a DNS authoritative server, a billing/customer portal, a one-click app installer like Softaculous, or any kind of multi-server clustering. If your mental model of a control panel is “cPanel feature parity”, CloudPanel will feel sparse. If your mental model is “the smallest thing that lets me stop hand-editing Nginx vhosts”, it will feel right-sized.

Installing CloudPanel on a VPS

The install path is genuinely a one-liner and the docs do not pretend otherwise. Minimum sane resources are 1 vCPU, 2 GB RAM, 10 GB disk. Supported OSes are Debian 11, 12, 13 and Ubuntu 22.04, 24.04 LTS, on x86_64 or arm64. Anything older than Debian 11 is not supported and you should not try.

On a fresh server, log in as root and update the base packages first:

apt update && apt -y upgrade && apt -y install curl wget sudo

Then run the installer. The exact command from the official docs (with sha256 verification, which you should not skip):

curl -sS https://installer.cloudpanel.io/ce/v2/install.sh -o install.sh; \
echo "6eac061df80f08b75224fcd7fce2f115e201696d8a6122e31abf7259a813b462 install.sh" | \
sha256sum -c && sudo DB_ENGINE=MYSQL_8.4 bash install.sh

Pick the DB_ENGINE value that matches your needs. Common choices are MYSQL_8.4, MYSQL_8.0, MARIADB_11.8, MARIADB_10.11. If you want MariaDB because your app stack assumes it, decide now, the database engine is not swappable post-install without manual surgery.

The script will install Nginx, PHP, the chosen database, the panel itself, and the supporting cron jobs. It takes 3 to 6 minutes on a 1 vCPU VPS, longer on slow disks.

Once it finishes, the management UI is at https://<your-server-ip>:8443/. The first request lands on a setup wizard where you create the admin user, and that is the moment of risk: between the install finishing and you completing the wizard, anyone who can reach port 8443 can claim the admin account. The official guidance is to access the panel “as fast as possible”. The better guidance is to firewall port 8443 down to your own IP before you even start the install:

ufw allow from YOUR_OFFICE_IP to any port 8443
ufw deny 8443

If you are running this on a DreamServer VPS , put the same rule in your provider-side network firewall too. Host-level rules are fine, network-level rules are better, both is correct.

After the wizard, turn on TOTP two-factor for the admin account from Account > Security. There is no excuse not to.

Adding a real PHP site with SSL

The mental model is: every site is an isolated user with a dedicated docroot under /home/<sitename>/htdocs/<domain>/. You do not edit Nginx vhosts by hand, the panel does that for you when you create or modify a site.

In the UI, Sites > Add site:

• Site type: pick the closest match (WordPress, Magento, Symfony, generic PHP, Node.js, static, reverse proxy). The template prefills sensible defaults for that app type.
• Domain: example.com plus any aliases. Wildcard subdomains are supported via DNS-01 if you wire it up to Cloudflare or Route53; otherwise stick to explicit names.
• PHP version: 7.4 through 8.3 in the dropdown. Switchable later.
• Site user: the Linux user that will own this site. Defaults to a sane derivation of the domain.

Save, point your A/AAAA records at the panel host, then come back and click SSL/TLS > Let’s Encrypt. The panel does the HTTP-01 dance, drops the cert into /etc/nginx/ssl/, and reloads. Sixty seconds, no manual certbot.

To verify the site is actually live:

curl -I https://example.com

You should see a 200 (or your app’s redirect) and a server: nginx header. If you see Apache or anything other than Nginx, something is wrong with your DNS, not with CloudPanel.

Configuration patterns worth knowing

A few patterns we have found useful beyond the defaults.

Use the per-site PHP settings, not php.ini

CloudPanel exposes memory_limit, max_execution_time, upload_max_filesize, and friends per site in the UI. Use those. Editing the global /etc/php/8.3/fpm/php.ini works exactly once, until your next package update wipes it.

Vhost custom snippets, not direct edits

Every site has a Vhost > Custom snippets field where you can paste extra Nginx directives. Use that for cache rules, redirects, security headers. Do not edit the panel-generated vhost file directly; the next save through the UI will overwrite your edits.

Cron over web cron

For WordPress in particular, disable WP-Cron in wp-config.php (define('DISABLE_WP_CRON', true);) and add a real cron entry in the panel’s Cron Jobs tab. WP-Cron firing on every page load is one of the more common reasons a small WordPress site feels slow under modest load.

Backups: panel + filesystem, both

CloudPanel’s S3 backups are good for application files and databases. They are not a substitute for a full-VM backup. We pair the panel’s backups with Proxmox Backup Server snapshots at the hypervisor level, so a “rebuild this VPS from scratch” recovery is a single restore instead of a panel-reinstall plus a per-site restore.

Trust the bot blocker more than your gut

The IP and Bot blocker has a curated list of known scrapers and credential stuffers. Turn it on for any public site and check the access logs a week later. The number of requests it silently drops, mostly stale WordPress brute-force toolkits, is consistently higher than people expect.

CloudPanel vs the alternatives

For completeness:

• cPanel/WHM: the industry default, mature, expensive, RHEL-centric. If you bill clients per cPanel account and need feature parity with the rest of the cPanel ecosystem (CageFS, JetBackup, WHMCS integration), it is still the right answer. CloudPanel is not trying to compete here.
• Plesk: similar pricing tier to cPanel, friendlier UI, runs on more OSes. If you are already paying for Plesk and it works, there is no reason to switch.
• aaPanel: free, broad feature set, Chinese-origin with an opaque telemetry story that has made some operators nervous. The UI is dense in a way that CloudPanel deliberately is not.
• HestiaCP: free, fork of VestaCP, ships with mail and DNS, more “do everything” in scope. Older codebase, more rough edges, but the right pick if you specifically need bundled mail and DNS.
• CyberPanel: free community edition, OpenLiteSpeed-centric, optimized for LiteSpeed cache. Good if you have already committed to the LiteSpeed ecosystem; otherwise Nginx is more portable.

CloudPanel ended up being the cleanest fit for “I want a modern panel that manages Nginx, PHP and databases for a small number of sites, without giving me features I will not use”. Your weights might be different.

Where CloudPanel is not the right answer

Worth being honest about the limits.

• No mail server. If you need IMAP/SMTP hosting on the same panel, CloudPanel will not give it to you. You will run a separate mail box (or, more sensibly, route mail through a managed provider).
• No authoritative DNS. The panel does not run BIND/PowerDNS for you. You manage DNS at your registrar, at Cloudflare, or on a separate authoritative service. For our customers this is usually fine because we provide DNS at the LIR/network layer anyway.
• No multi-server. One panel manages one server. There is no concept of a cluster, no shared filesystem story, no failover. If you have more than a handful of servers, you are looking at orchestration tooling, not a panel.
• No customer billing. This is not a hosting-reseller platform. If you need to sell hosting plans with invoicing, you bolt the panel onto a separate billing system.
• Self-hosting is still self-hosting. You patch the OS, you watch the disk fill up, you deal with the occasional MySQL surprise. If your team does not want that, a managed service is cheaper in operator hours than free software is in your time.

So, should you run it?

If you self-host a handful of PHP, Node or Python sites on a VPS or dedicated server, and you have been hand-editing Nginx vhosts long enough to be bored of it, CloudPanel is worth a Sunday afternoon. The install is a single command, the UI gets out of your way, and the per-site Linux user model means a compromised plugin on one site is not a panel-wide incident.

If you are running it in production, put it on a server with a real backup story (Proxmox Backup, snapshots, your call), firewall the management port, and treat the panel as critical infrastructure. The Nginx and PHP configs the panel writes are easy to rebuild; the database of site definitions and users is what you would actually miss.

We run CloudPanel ourselves in front of a few internal sites and recommend it to customers who ask for “something between bare Nginx and cPanel”. If you want to try it on infrastructure you do not have to build first, our VPS plans start small enough to make the experiment cheap, and our server administration service covers the install and tuning if you would rather skip the learning curve. If something does not fit, get in touch and we will tell you honestly whether it is the right tool for the job.

The code is on GitHub , the install is one command, and you will know within an hour whether it earns a spot in your stack.

SafeLine , the open-source WAF maintained by Chaitin Tech , has been quietly building momentum around that exact gap. As of v9.3.4 (released 17 April 2026) it sits at 21k+ stars on GitHub, runs on more than 180,000 installations and is licensed under GPL-3.0. We have been testing it on a VPS in our Bucharest datacenter for a few weeks. This post is the field report.

What SafeLine actually is

Architecturally, SafeLine is a reverse proxy with a detection engine in front of your origin. Traffic hits SafeLine on ports 80/443, gets inspected, and either passes through to your upstream application or is challenged, throttled, or blocked. The reverse proxy is built on a hardened Tengine fork (Tengine being Alibaba’s nginx derivative), with detection logic implemented as native modules in C++ and Lua. The management plane is a Go service backed by PostgreSQL.

If that sounds a lot like nginx + ModSecurity, the comparison is fair on paper and unfair in practice. The interesting part is what happens between request arrival and the upstream call.

Why the detection engine is different

Most open-source WAFs you have probably touched, ModSecurity with the OWASP Core Rule Set being the canonical example, are fundamentally regex engines. They match patterns in the request and decide. The trade-off is well known: tighten the rules and you start blocking legitimate users, loosen them and attacks slip through. Anyone who has ever paranoia-mode’d ModSecurity in front of a WordPress site knows the false-positive tax.

SafeLine takes a different route. It parses the request as a syntactic structure (SQL grammar for query parameters that look database-shaped, JS AST for script content, shell parser for command patterns) and then evaluates whether the parsed result has the semantic shape of an attack. A query with quotes is not automatically suspicious; a query whose parsed form would change SQL execution flow is. The Chaitin team publishes benchmark numbers around 99.4% true-positive accuracy in their balance mode, which is in the range of commercial offerings.

You should still verify on your own traffic, all WAF benchmarks have a strong “tested on the dataset we built” flavour, but in practice the false-positive rate on our test workloads has been substantially lower than ModSecurity with CRS at paranoia level 2. That alone changes the operational story: a WAF you do not have to constantly whitelist around is a WAF that stays on.

What you get out of the box

The community edition (which is what we are talking about, the Pro edition is announced but not generally available at the time of writing) ships with:

• Web attack detection for the OWASP-canonical categories: SQL injection, XSS, command and code injection, XXE, SSRF, path traversal, deserialization patterns.
• Rate limiting per IP, per path, per session, with configurable windows and burst behaviour.
• Anti-bot challenge, a JavaScript proof-of-work that legitimate browsers solve transparently and headless scrapers stumble on.
• Authentication challenge, a separate gate you can put in front of admin panels (think: a captcha-like step before reaching /wp-admin/).
• Dynamic HTML/JS encryption, which mangles client-side identifiers per request so scrapers and credential-stuffing tools cannot easily target form fields.
• Geo blocking by country, useful for sites with no business outside a specific region.
• Logging and analytics dashboard, which is genuinely useful (more on this below).

What it does not do: it is not a CDN. It does not cache static assets, does not give you POPs around the world, does not protect against L3/L4 volumetric DDoS at the network edge. SafeLine is a layer-7 application firewall. If you are taking 100 Gbit of UDP reflection, you need network-layer mitigation upstream, the kind we run at AS57050 with our own RTBH and sFlow setup , before the traffic ever reaches your VPS.

Installing SafeLine on a VPS

This is the part where most “open source WAF” projects make you regret the decision. SafeLine genuinely does not. The official one-liner does the right thing on a clean Debian or Ubuntu box.

Minimum sane resources: 2 vCPU, 4 GB RAM, 10 GB free disk. The script will warn under 5 GB free. SSSE3 CPU instructions are required (any x86 CPU made in the last 15 years has them, but if you are running on something exotic, check /proc/cpuinfo). Both x86_64 and arm64 are supported.

On a fresh server:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/setup.sh)"

The script will:

1. Install Docker and the Compose plugin if they are missing.
2. Drop a docker-compose stack at /data/safeline/.
3. Pick an unused private subnet (it tries 172.22.222.0/24, 169.254.222.0/24, 192.168.222.0/24 in order).
4. Generate a random 32-char Postgres password.
5. Pull and start four containers: safeline-pg, safeline-mgt, safeline-detector, safeline-tengine.

Once it finishes, the management UI is at https://<your-server-ip>:9443/ with a self-signed certificate. To grab the initial admin credentials:

docker exec safeline-mgt resetadmin

That command prints a one-time username and password you can use for the first login. Change the password immediately after you are in. While you are at it, restrict port 9443 with a firewall rule, the management plane should not be exposed to the internet:

ufw allow from YOUR_OFFICE_IP to any port 9443
ufw deny 9443

If you are running this on a DreamServer VPS , the same rule belongs in your provider’s network firewall too, do not rely on host-level rules alone for management interfaces.

Putting a real site behind it

Adding a protected site is straightforward but the mental model takes a minute to click. SafeLine becomes the public-facing endpoint; your real application becomes an internal upstream that only SafeLine talks to.

In the management UI, Sites > Add site:

• Domain: example.com (and any aliases you serve).
• Port: 80 for plain HTTP, 443 for HTTPS, both if you want SafeLine to do the redirect.
• Upstream: the IP and port of your origin, for example 10.0.0.5:8080. If your origin lives on the same box, use the docker bridge gateway (typically 172.17.0.1 or whatever the script picked) and the port your application listens on.
• TLS certificate: paste a cert and key, or upload a Let’s Encrypt-issued one. SafeLine does not currently auto-issue certificates, you bring your own.

Save, then point your domain’s A/AAAA records at the SafeLine host. Within a few seconds the site shows up under Detection logs and you can watch live traffic flow through.

The first thing to verify is that SafeLine is genuinely inline. Send a deliberately bad request:

curl -k "https://example.com/?id=1' OR '1'='1"

You should get a SafeLine block page (HTML body, HTTP 403 by default) and a corresponding entry in the detection log. If the request goes through to your application, your DNS or upstream config is wrong, fix that before you trust anything else.

Configuration patterns worth knowing

A few patterns we have found genuinely useful beyond the defaults.

Whitelisting health checks

If your monitoring system pings /health from a known IP, do not let SafeLine score those requests. Add an Allow rule at the top of the policy chain matching source IP and path, with action “skip detection”. The point is not to save CPU, it is to keep your detection logs uncluttered with traffic you trust.

Rate limit before block

When you turn on rate limiting for a login endpoint, prefer challenge over block for the first threshold. A bot that runs into a challenge silently dies; a human who fat-fingered their password three times in a row gets through. Reserve the block action for the second threshold (say, 30 requests per 5 minutes from a single IP).

Anti-bot for the entire site, not just login

Counter-intuitive but useful: turn on the JS challenge sitewide for low-value paths (the homepage, the blog) on a small percentage of traffic. The bots that fail the challenge there are the same ones that would later try your login form. You learn a lot about what is hitting you before any sensitive endpoint sees the traffic.

Authentication challenge for admin paths

For anything matching /admin*, /wp-admin*, /phpmyadmin*, add an authentication challenge layer. SafeLine implements this as an extra gate that requires solving a CAPTCHA-style challenge before the request reaches your application. It does not replace your application’s auth, it just stops automated tools from ever knocking on the door.

Read the logs

The dashboard at Statistics > Detection logs shows every blocked request with the parsed reason: which engine triggered (semantic SQLi, regex XSS, anti-bot), the request body, the score. Spend an hour going through it the day after you turn SafeLine on. You will find that most of your “weird traffic” looks the same: a handful of mass-scanning toolkits hitting the same WordPress admin paths and the same exposed .env URLs.

Where SafeLine is not the right answer

It is worth being honest about the limits.

• Not a CDN. No caching, no edge POPs. If your performance story depends on edge proximity, you still need a CDN in front of (or beside) SafeLine.
• Not for sub-millisecond paths. Every request goes through detection. Median overhead in our tests was 1 to 3 ms on warm caches, which is fine for almost any web app, but if you are running an HFT API, this is not your tool.
• Pro features are not all open. Some of the more sophisticated dynamic-protection features and the multi-node clustering are clearly aimed at the upcoming Pro edition. The community edition is generous, but if you are protecting a fleet of dozens of sites with HA requirements, plan for that.
• Self-hosting is not free. You are running another stateful service that needs backups, OS patching, and the occasional Postgres babysitting. If your team does not want that, a managed WAF will be cheaper in operator hours.

Alternatives we considered

For completeness: we also looked at BunkerWeb (nginx-based, very approachable, weaker semantic detection), Coraza (a Go-native ModSecurity reimplementation, great if you want to embed WAF logic directly in a service mesh), and the OWASP CRS on a stock nginx with ngx_security_module (battle-tested, infinitely tunable, false positives are your hobby now).

SafeLine ended up being the cleanest fit for “I want a real WAF in front of a small fleet of self-hosted sites without becoming a WAF specialist”. Your weights might be different.

So, should you run it?

If you self-host PHP, Node, Python or Go web applications on a VPS or dedicated server and you have been meaning to “do something about security headers and bot traffic”, SafeLine is worth a Sunday afternoon. The install is genuinely fast, the detection works without you fighting it, and the dashboard tells you something true about your traffic.

If you are running it in production, put it on a server with a real backup story (Proxmox Backup, snapshots, your call) and treat the management plane as critical infrastructure. The detection containers can be rebuilt in a minute; the configuration in Postgres is what you would actually miss.

We run SafeLine ourselves in front of a couple of internal services and recommend it to customers who ask. If you want to try it on infrastructure you do not have to build first, our VPS plans start at small enough sizes to make the experiment cheap, and our server administration service covers the install and tuning if you would rather skip the learning curve.

Either way, kicking the tires on SafeLine is a better way to spend an evening than reading another “top 10 WAF” listicle. The code is on GitHub, the install is one command, and you will know within an hour whether it earns a spot in your stack.

This is where we will publish promotions, campaigns, tutorials, recommendations and technical articles about the hosting services we run. If it helps a customer configure, deploy or troubleshoot a dedicated server, VDS or VPS, we want to write it down here.

What to expect

• Promotions and campaigns - when we launch a deal, drop a price, bundle a service or open a new configuration, you will read it here first.
• Tutorials - step-by-step guides with commands you can paste and configuration files you can reuse, focused on getting your servers up and running the way you actually want them.
• Recommendations - platforms, control panels, operating systems and applications that work well on our infrastructure, and how to pick between the usual alternatives.
• Technical articles - dedicated server setup, VDS and VPS management, Linux administration, networking, storage, backups and security hardening - the same topics that come up in our support tickets, written up once so you can find the answer faster next time.

How we write

Honest, source-linked, no fluff. When something needs proof we cite the documentation, the RFC or the vendor knowledge base. When we make a mistake we correct it inline with a dated note.

Stay in touch

• RSS - subscribe in your feed reader at /en/blog/index.xml .
• Email - contact@dreamserver.ro for sales, noc@dreamserver.ro for network operations, or open a ticket from the client area .
• Services - browse dedicated servers , VPS and VDS .

Thanks for stopping by. More posts coming soon.