cPanel is heavy, expensive to license, and hides what is actually running on your server. For a lot of devs that tradeoff stopped making sense years ago. A modern VPS panel gives you nginx, PHP, MySQL, and SSL with one click, then gets out of your way. This post walks through a full WordPress deploy on a fresh VPS in about 5 minutes, with no cPanel license and no manual config files to edit.
The example uses Molixa Forge, but most of the steps translate to any panel that speaks SSH. If you already have a server running WordPress elsewhere, the same flow works for a second site or a staging clone.
What you need before you start
Three things, nothing exotic.
- A VPS from any provider. Hetzner, DigitalOcean, Vultr, Linode, AWS Lightsail, OVH, Contabo. Any plan with at least 1 GB of RAM handles a single WordPress site comfortably.
- SSH access as root, or a sudo user with passwordless sudo. The panel uses this once during the initial connect and never logs back in interactively.
- A domain name with DNS access. You need to add an A record, so registrar access or a DNS provider like Cloudflare is fine.
That is it. No licenses, no control panel accounts from the VPS host, no preinstalled stack. Start from a fresh image and the panel handles the rest.
Step 1. Spin up a fresh VPS
Create a new Linux VPS from your provider of choice. Ubuntu 24.04 LTS is a sensible default. It has a long support window, the package repos are current, and every panel worth using tests against it first.
Pick the smallest plan that fits your traffic. A Hetzner CX22 or a $6 DigitalOcean droplet handles a normal WordPress site with caching turned on. If you expect bursts, size up the RAM first, not the CPU.
Paste your SSH public key during creation. That one step saves you the password dance later and is the only thing the panel needs to connect.
Step 2. Connect the VPS to your panel
Log into the panel, click Add Server, paste the IP address, and paste the SSH private key. Thirty seconds later the panel has a working connection and reports back what it found on the box.
The detection pass is fast because it is just a handful of shell checks. You get a readout that looks roughly like this.
[+] Connected to 203.0.113.42 as root [+] Detected: Ubuntu 24.04 LTS (noble), kernel 6.8.0 [+] Package manager: apt [+] Existing services: none (fresh image) [+] Ports available: 80, 443 [+] Sudo: passwordless OK [+] Firewall: ufw inactive Ready to install stack.
No ambiguity about what the server looks like. You know exactly what is installed before anything runs.
Step 3. Install the WordPress stack with one click
In the panel, pick a server and click Install WordPress. Under the hood this is a single apt transaction plus a few config writes. Here is what actually gets installed.
- nginx as the web server, tuned for a single WordPress site out of the box.
- PHP-FPM 8.3 with a dedicated pool, the right php.ini defaults for WordPress (upload_max_filesize, memory_limit, opcache), and the extensions WP actually needs: mysqli, gd, curl, mbstring, xml, zip, imagick, intl.
- MySQL 8 with a fresh database, a dedicated user, and a random 32 character password the panel stores for you.
- WordPress core downloaded straight from wordpress.org, verified against the official checksums, then unpacked to the site root.
- wp-cli installed globally so you can run plugin, theme, and database commands from SSH.
The whole stack install takes two to three minutes depending on your server location and the network weather that day. No prompts mid-install, no Y/N for dependency questions. It runs to completion or it reports exactly what failed.
Step 4. Point your domain at the VPS
In your DNS provider add an A record for the domain pointing to the VPS public IP. If you want the bare root and the www subdomain to both work, add two records.
Type Name Value TTL A @ 203.0.113.42 300 A www 203.0.113.42 300
TTL of 300 seconds is safe while you are setting things up. You can raise it to 3600 later once everything is stable.
Before you hit the SSL step, the panel runs a preflight DNS check from its own resolver. If the A record has not propagated yet, you see a clear message instead of a cryptic cert failure. Wait a minute and try again.
Step 5. Issue a free SSL cert
Click Issue Certificate on the site. The panel requests a cert from Let's Encrypt using the HTTP-01 challenge, which means Let's Encrypt pings a specific path on your site over HTTP to prove you control the domain. Twenty seconds later the cert is installed in nginx and HTTPS works.
Renewals run automatically 30 days before expiry. HSTS, OCSP stapling, and TLS 1.3 are on by default. You never touch certbot.
Step 6. Run the WordPress install wizard
Open your domain in a browser. WordPress shows the standard install page. Pick a site title, a username, and an email address. WordPress writes the database tables and you are in.
If you prefer to skip the browser wizard entirely, wp-cli can finish the install from SSH.
$ wp core install \
--url=https://example.com \
--title="My New Site" \
--admin_user=admin \
--admin_password='use-a-real-one' \
--admin_email=you@example.com
Success: WordPress installed successfully.That is the whole deploy. From a fresh VPS to a working HTTPS WordPress site in about 5 minutes, most of which was waiting for apt and Let's Encrypt.
What used to be hard now just works
If you have ever set up WordPress by hand, none of the below is news. The point is that a good panel handles every one of these without asking.
- nginx vhost with the correct try_files rule and a PHP location block that points at the right FPM socket. Easy to typo by hand, miserable to debug later.
- A dedicated PHP-FPM pool so your WordPress site does not fight a different site on the same box for worker processes.
- A MySQL database and a user with the right GRANT scope, not the root password dumped into wp-config.php.
- SSL config that actually passes an SSL Labs A+ rating. Most hand-rolled nginx configs pass an A at best.
- A working wp-cron via a real system cron, so scheduled posts and plugin cron jobs run even on low-traffic sites.
- A firewall that blocks everything except 22, 80, and 443, with fail2ban watching sshd and wp-login.
All of this is set up once, on install, and stays correct as you add more sites. You can still SSH in and read every config file. Nothing is hidden. The panel just writes sensible defaults so you do not have to.
If you want a deeper look at the stack Molixa Forge installs and the options you get per site, the WordPress on Molixa page walks through it. The full feature list covers monitoring, backups, and the AI assistant that runs wp-cli commands for you.
When you might still want cPanel
Being honest about this matters. cPanel still wins for a couple of use cases, and it is worth knowing before you switch.
cPanel ships with a full email stack, so if you are hosting inbox email for dozens of client domains on the same box, that is a real feature. Most modern panels, Molixa Forge included, assume you send transactional mail through an SMTP provider and receive it on a managed service. If you need Dovecot and SpamAssassin right there on the server, cPanel covers that out of the box.
Reseller hosting is the other one. cPanel and WHM give you a built-in tenant model where each reseller client sees their own cPanel login with quotas and branding. Most developer-focused panels support teams and site ownership, but the full reseller billing and branding workflow is cPanel and Plesk territory.
For everything else, a modern panel is smaller, faster, free or nearly so, and does not hide what it is doing. Compared with SpinupWP, you also get a free tier and an AI that runs commands for you. Before you pick a stack for a new project, check the pricing page so the numbers match your plan.
Where to go from here
Once the first site is up, the interesting part starts. Turn on nightly backups. Wire a staging clone to a subdomain. Add a second site on the same box, which takes about 60 seconds once the stack is installed. Point the AI assistant at the server and ask it to audit PHP versions or plugin updates.
The point is that the tedious parts are done. What is left is the work you actually wanted to do when you paid for the VPS.