This series explains step-by-step how to create a complete website, from purchasing the domain to installing and configuring WordPress, using the CyberPanel control panel. 

🔹Episode 0: The Foundation. Proxmox Cluster and High Availability (HA)

“If it is not on a solid foundation, a website is just a sandcastle waiting for the first system error.”

Welcome to the beginning of a fascinating journey. Before buying domains or installing WordPress, we need to talk about where your future project will live. Most tutorials teach you to put a site on cheap hosting and hope it works. In this series, we do things differently: we build our own Enterprise-grade infrastructure.

Why start with a Cluster?

Imagine your server has a hardware problem in the middle of the night. In a standard setup, your site disappears. In a Proxmox Cluster with a Quorum Device (QDevice), the other server takes over immediately.

What you will learn in this preface:

  • Transforming ordinary hardware: How to link two mini-PCs (NUCs) into a single intelligent entity.

  • The Power of the Arbiter (QDevice): How a third device (even an old laptop with Ubuntu) can decide who stays online in case of failure.

  • Real-world troubleshooting: I won’t just show you the “perfect” version, but also how to overcome SSH permission errors, locked repositories, and network configurations that give even professionals a headache.

Author’s note: This episode is the foundation. It might be the most technical part of the series, but once you are finished, you will have a peace of mind that no $5 hosting service can offer: the certainty that your site  stands on indestructible infrastructure.

Guide: Configuring a Quorum Device (Arbiter) in Proxmox 8/9

When you have a cluster made up of only two Proxmox nodes, you need a third vote to maintain the majority (Quorum) in case one server goes down. This role is fulfilled by a QDevice (a simple Linux container or PC).

⚠️ CRUCIAL NOTE: Choosing the File System Before running any command, make sure that during Proxmox installation, in the Target Harddisk -> Options screen, you selected zfs (RAID0).

Why ZFS and not the default LVM? Without ZFS, you will not be able to use the Replication (Mirroring) feature. ZFS allows us to automatically send data from one server to another every minute, ensuring that our site has an identical copy ready to start if the primary hardware fails.

a. Preparing the Proxmox nodes (PVE1 and PVE2)

By default, Proxmox comes with the “Enterprise” repositories enabled. For the free version, we need to clean up the apt sources in order to install the corosync package.

Commands to clean and enable No-Subscription sources:

# Remove enterprise sources (.list and .sources format)
rm -f /etc/apt/sources.list.d/pve-enterprise.list
rm -f /etc/apt/sources.list.d/pve-enterprise.sources
rm -f /etc/apt/sources.list.d/ceph.sources

# Add free sources
echo "deb http://download.proxmox.com/debian/pve trixie pve-no-subscription" > /etc/apt/sources.list.d/pve-no-sub.list
echo "deb http://download.proxmox.com/debian/ceph-squid trixie no-subscription" > /etc/apt/sources.list.d/ceph-no-sub.list

# Update and install QDevice package
apt update && apt install corosync-qdevice -y

b. Preparing the Arbiter (Ubuntu / Debian – IP: 192.168.1.101)

The arbiter needs the corosync network package and relaxed SSH access for the initial setup.

On the Arbiter:

sudo apt update && sudo apt install corosync-qnetd -y

Allowing access for Proxmox (Solution for “Permission Denied”): Proxmox enforces connections via the root user. If we use another user (e.g., bogdan), we must move the keys:

# Run on Ubuntu to allow root access using the user's key
sudo mkdir -p /root/.ssh
sudo cp /home/bogdan/.ssh/authorized_keys /root/.ssh/authorized_keys
sudo chmod 700 /root/.ssh
sudo chmod 600 /root/.ssh/authorized_keys

# Make sure SSH allows root login
sudo sed -i 's/#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
sudo systemctl restart ssh

Configuring SSH Password Access for Root: In order for the Proxmox nodes to install the Quorum service, the Arbiter laptop must allow login for the root user using a password (only for the initial setup stage).

# Edit the SSH configuration file
sudo nano /etc/ssh/sshd_config

# Find and modify these lines to look exactly like this (remove # if present):
PermitRootLogin yes
PasswordAuthentication yes

# Save (Ctrl+O, Enter) and Exit (Ctrl+X)
# Then restart the service to apply changes:
sudo systemctl restart ssh

# Set a password for the root user (if you haven't already):
sudo passwd root

Why is this step mandatory?

Even if we have copied the SSH keys, the pvecm qdevice setup utility (the command from step c.3) requires an initial password-based connection in order to exchange security certificates between the nodes and the Arbiter. Without PasswordAuthentication yes, you will receive a “Permission Denied” error at the end of the procedure.

Security tip: After you have verified with pvecm status that you have 3 votes, it is recommended to return to this file and change PasswordAuthentication back to n

c. Connecting the Cluster (The Great Union)

This step transforms individual servers into a single entity. Since Proxmox uses SSH for secure communication, we need to establish passwordless trust between nodes.

On Proxmox (PVE1):

# 1. Send SSH key to the Arbiter (ASUS)
# Note: If you previously had an old cluster, run first: ssh-keygen -f "/root/.ssh/known_hosts" -R "192.168.1.101"
ssh-copy-id [email protected]

# 2. Create the Cluster
pvecm create RenukaCluster

# 3. Final QDevice configuration (Arbiter)
# Use -f to force writing new security certificates
pvecm qdevice setup 192.168.1.101 -f

d. Status verification

To confirm that we now have 3 votes, run:

pvecm status

Expected result:

  • Total votes: 3

  • Quorum: 2

  • Flags: Quorate Qdevice

“By choosing ZFS and configuring this Arbiter, we have created an environment where data is not just stored, but alive and mobile. In the next episodes, we will install WordPress on this foundation and enable replication every 60 seconds. A system administrator’s peaceful sleep starts here.”

🔹 Episode 1: Choosing and buying a cheap domain – Namecheap –

1. Understanding the “Upselling” process (Avoiding unnecessary costs)

  • Namecheap will suggest SSL, VPN, or Premium DNS in your cart. Do not check them! In the following episodes, I will show you how to get the same benefits (and even better) using Cloudflare and our own server. Why pay an annual subscription when you can have total control and zero costs?

2. “Privacy Protection” (WhoisGuard)

  • While others charge you $10-15 a year just to keep your home address and phone number private, Namecheap offers this protection for FREE, for life.

⚠️ Watch out for “Renewal Price” and Auto-Billing
Even though Namecheap is one of the fairest platforms, you must be an informed buyer. Here are the two golden rules:

  • Check the year 2 price
    Many promotions (for example, .com domains at $5-6) are only valid for the first year. Before paying, look under the current price; you will see “Retail price” or “Renewal price”. Usually, this jumps to $14-16.

Tip: If your project is long-term, calculate your budget starting from the renewal price, not the promotional one.

  • Turn off “Auto-Renew”
    If you are just testing an idea and don’t want to find money taken from your card in 12 months, you must disable automatic renewal.

 

🔹 Episode 2: Configuring the Domain in Cloudflare + Free SSL

PREAMBLE


1. Why Cloudflare and not the paid SSL from Namecheap?

  • In the previous episode, we refused the $10-15/year SSL offers. Why? Because Cloudflare offers us the same thing (and much more) for FREE. Cloudflare is not just an SSL certificate provider; it is a security shield (WAF), a site acceleration system, and a DNS manager much faster than the standard one.

2. “DNS Propagation” (Patience is key)

  • After you change the Nameservers in Namecheap (https://www.google.com/search?q=ns1.cloudflare.com, https://www.google.com/search?q=ns2.cloudflare.com), you might panic if the site doesn’t work immediately. DNS Propagation can take anywhere from 5 minutes to 24 hours. Don’t start changing settings ten times; just check the status in Cloudflare until the green label appears: “Great news! Cloudflare is now protecting your site.”

⚠️ Pay Attention to SSL Configuration: “Full” vs “Flexible” Mode

Cloudflare offers several encryption options. Here’s what you need to know to avoid “Too many redirects” errors:

  • Flexible Mode: Encrypts only the traffic between the visitor and Cloudflare. (Useful if your server has no SSL at all).
  • Full / Full (Strict) Mode: Encrypts the entire path, from the visitor to your Proxmox/CyberPanel server.

Tip: Since we will be installing our own control panel in Episode 3, I recommend setting the Full mode now. It is the security standard for 2026.

Two “Must-Have” Settings in Cloudflare
Immediately activate these two options from the SSL/TLS -> Edge Certificates tab:

  • Always Use HTTPS: Automatically redirects any visitor who types http:// to the secure https:// version. Zero effort, maximum security.
  • Automatic HTTPS Rewrites: Fixes “Mixed Content” issues (when you have old images or scripts loading over insecure links).

 

🔹 Episode 3: Invisible Architecture. Cloudflare Tunnel and ZFS Replication

“True security isn’t just a high wall; it’s being impossible to find. Today, we make our new domain renuka.site invisible to hackers and indestructible against hardware failures.”

So far, we have a purchased domain and Cloudflare protection enabled. But how do we connect our home Proxmox server to the internet without exposing our real IP address? Normally, you would need to use Port Forwarding in your router, which exposes your private network and forces you to manage complicated firewall rules. In this episode, we eliminate this risk using Cloudflare Tunnels.

🚀 The Zero Trust Revolution: Goodbye Static IP and Port Forwarding

The biggest advantage of this model is that you no longer need a static IP from your internet service provider (ISP).

⚠️ NOTE FOR HOME USERS: > The biggest benefit? Forget about extra costs for a static IP! Since the tunnel initiates the connection from inside your network to Cloudflare (Inside-Out), your site will stay online even if your ISP (Digi/Orange/Vodafone) changes your IP address ten times a day. Cloudflare automatically updates the DNS routes (CNAME records) without you lifting a finger. It is the ideal solution for home hosting.

  • Secure Connection: Your server establishes an encrypted connection with Cloudflare.

  • DNS Automation: When you define a route in the tunnel, Cloudflare automatically creates a CNAME pointing to your server.

  • “Armored” Router: Your router remains closed. No open ports, no entry gates for attackers.

a. Preparing the Tunnel in Cloudflare Zero Trust

Before the server configuration, we prepare the digital “pipe” in the Cloudflare dashboard:

  1. Navigate to Zero Trust -> Networks -> Tunnels.

  2. Create a new tunnel named renuka-production-tunnel.

  3. Select the Debian (64-bit) connector.

  4. Copy the unique Token (the long string of characters at the end of the installation command). Keep it safe; this is the key that will link your container to the global network.

b. Creating the Container (CT) in Proxmox

We don’t install the connector directly on the server’s operating system (PVE), but in an isolated environment for better management:

  1. Download Template: In the Proxmox interface, go to storage local -> CT Templates -> Templates and download debian-12-standard.

  2. Create CT: Use this template for a new container (e.g., ID 105, name Cloudflare-Connector).

  3. Golden Setting (Nesting): After the container is created (but before starting it), go to: Container (105) -> Options -> Features -> Double click on Nesting and check it. Without this setting enabled, the tunnel service will not have the necessary permissions to start!

c. Installing the Connector (Terminal Commands)

Start the container, enter its console, and run the following commands to activate the tunnel:

# 1. Update the system and install curl utility
apt update && apt upgrade -y
apt install curl -y

# 2. Download the official Cloudflared package (the connector)
curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb

# 3. Install the package on the system
dpkg -i cloudflared.deb

# 4. Activate the tunnel service (Replace [TOKEN] with the one obtained previously)
cloudflared service install [YOUR_TOKEN_HERE]

Verification: In the Cloudflare dashboard, the tunnel status should turn green: Healthy.

d. ZFS Replication: Mirroring between PVE1 and PVE2

To ensure the continuity of the renuka.site website, we configure Proxmox to mirror this container onto the second server in the cluster:

  • Select the container (105) -> Replication -> Add.

  • Target: PVE2 (the second node in the cluster).

  • Schedule: */1 (every minute).

  • Result: If the main server (PVE1) has a hardware failure, the container can be started instantly on PVE2. The tunnel connection will be re-established automatically, and the site will be back online in a few seconds.

e. Mapping the Main Route

In the Public Hostname tab of Cloudflare Tunnel, we add the gateway for visitors:

  • Subdomain: (leave blank for the main domain)

  • Domain: renuka.site

  • Service: http://[SERVER_INTERNAL_IP] (Here we will enter the local address of the server where we will install WordPress in the next episode).

🔹 Episode 4: The Immortal Server. Installing CyberPanel & High Availability (HA)

“A running server is good. A server that revives itself after a hardware failure is invincible. Today, we transform our local infrastructure into a fortress using CyberPanel and Proxmox redundancy.”

After securing our connection to the outside world via Cloudflare Tunnel in the previous episode, today we focus on the “engine” of our site: CyberPanel-Server (VM 101). But, as often happens in the real life of an admin, the road was full of permission errors and technical hurdles that we solved step by step.

🚀 Total Resilience: Installing the Agent and the Permissions Battle

The most important step in preparing the virtual machine is installing the QEMU Guest Agent, the “translator” between Ubuntu and Proxmox.

⚠️ TECHNICAL NOTE: > Without this agent, ZFS replication cannot execute the fsfreeze function. This function “freezes” disk writes for a second, ensuring that the database snapshot is perfectly consistent and uncorrupted during synchronization between servers.

  • QEMU Agent: Allows Proxmox to see the internal IP and execute a Safe Shutdown.

  • Root Access: CyberPanel requires full privileges, making the sudo su - command mandatory.

  • Safe Install: Downloading the script to the disk eliminates “pipe” errors like /dev/fd/63.

a. System Preparation (Terminal Commands)

Before installing the panel, we update the system and enable communication with the hypervisor:

# 1. Update the system and install QEMU Agent
sudo apt update && sudo apt upgrade -y
sudo apt install qemu-guest-agent -y

# 2. Enable the service
sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent

b. CyberPanel Installation (CLI Troubleshooting)

To avoid the permission errors detected during the tutorial, we follow the local download method:

  1. Download: wget -O install.sh https://cyberpanel.net/install.sh

  2. Switch to Root: sudo su - (The hyphen loads the full root profile).

  3. Execute: Navigate to the folder where the script was downloaded: cd /home/[your_user]/ and launch sh install.sh.

c. Password Recovery (adminPass)

If login fails or the default password is not recognized, use the internal CyberPanel utility (mandatory from root mode):

# Reset admin password in case of access errors
sudo su -
adminPass your_new_secure_password

d. ZFS Replication and High Availability (HA)

To ensure the “immortality” of the server, we configure Proxmox to mirror the VM onto the second server in the cluster:

  • Select VM (101) -> Replication -> Add (Schedule: */1).

  • HA Manager: Add VM 101 in Datacenter -> HA with the setting Max. Relocate: 1.

  • Result: In the event of a power failure on PVE1, the cluster (aided by the QDevice/Arbiter) will automatically restart CyberPanel on PVE2 in less than 2 minutes.

e. Failover Test Result

In the system log, we can see the replication process working flawlessly:

  • Freeze: QEMU agent stops writes.

  • Snapshot: ZFS creates the reference point.

  • Sync: Data is sent to the second server.

🔹 Episode 5: From Local to Live. Cloudflare Tunnel and WordPress Installation

“A website being online is just the beginning. Today we finalize the connection between our local infrastructure and the public internet, demonstrating that you can have a functional site without opening any ports in your router and without complicated local SSL settings.”

After ensuring hardware redundancy through High Availability in the previous episode, today we focus on the “facade” of the project. We move from a local IP to a live domain, solving the port dilemma and performing the first WordPress installation under the protection of Cloudflare Tunnel.

🚀 Smart Connection: Cloudflare Tunnel on Port 80

The critical moment of this episode was finding the optimal route for traffic, avoiding SSL Handshake errors (Bad Gateway).

⚠️ TECHNICAL NOTE: In this configuration, we set the tunnel route to HTTP port 80. Since the Cloudflare Tunnel is already an encrypted and secure channel between our server and their network edge, it is no longer necessary to configure local SSL certificates on CyberPanel to see the site live.

  • Cloudflare Tunnel: The service that creates a secure link between the Proxmox container and the internet, keeping your home IP hidden.

  • No Open Ports: The router remains closed. Zero Port Forwarding means maximum security against direct attacks.

  • WordPress Live: We confirm that the entire system—from ZFS replication to the Cloudflare Tunnel—is working perfectly.

a. Configuring the route in Networks -> Tunnels

The essential step to make the site visible was defining the egress point in the Cloudflare panel:

  1. Public Hostname: In the Networks -> Tunnels section, we edited the active tunnel and added the desired domain.

  2. Service Type: We selected HTTP (not HTTPS), letting the tunnel handle the encryption.

  3. URL: We specified the internal IP of the VM and port 80 to eliminate the 502 error.

b. WordPress Installation via CyberPanel

With the domain now accessible from the outside, we proceeded to install the site engine through the CyberPanel interface:

  • Website Creation: We added the domain in CyberPanel, preparing the file structure.

  • Application Installer: We used the WordPress script to automatically configure the database and files.

  • Confirmation: We verified access to the Dashboard, confirming that the entire communication chain is functional.

c. Edge Security (Edge Certificates)

Although we use port 80 internally for stability, the visitor benefits from total encryption via Cloudflare:

  • Edge SSL: Cloudflare manages the SSL certificate at the “edge.”

  • HTTPS: The visitor sees the green padlock, with traffic being secured all the way to our local server through the tunnel.