Knowledge Base | VoxiHost

Now Live: Hourly VPS Hosting - The Ultimate Flexibility for Your Projects

2026-04-10T00:00:00Z

At VoxiHost, we strive to make your infrastructure as dynamic as your ideas. Today, we are taking a massive leap forward by introducing one of our most requested features: Hourly VPS Hosting.

Whether you need a server for 3 hours of testing or want to run short-term scripts without committing to a monthly subscription, the new Hourly offer is built for you.

Why Choose Hourly VPS?

The Hourly system isn't just a different way to pay, it's a total shift in how you manage your resources.

1. Pay Only for What You Use

No more paying for unused time. If your compute needs only last a few hours a week, the Hourly model will save you real money. Prices start as low as:

€0.01 / hour on the Budget VPS plan
€0.02 / hour on the Premium VPS plan

2. Full Flexibility of Choice

We don't compromise on quality. Hourly billing is available for both our Premium VPS and Budget VPS base models.

For full transparency, here is how we calculate the hourly rate based on your selected resources:

Element	Budget VPS	Premium VPS
Base (minimum)	€0.01/hr (2 vCPU, 2 GB RAM, 10 GB SSD)	€0.02/hr (1 vCPU, 2 GB RAM, 10 GB SSD)
CPU Upgrade	+€0.0023/hr (per +2 vCores)	+€0.01/hr (per +1 vCore)
RAM Upgrade	+€0.0023/hr (per +2 GB)	+€0.0046/hr (per +2 GB)
Disk Upgrade	+€0.0023/hr (per +10 GB)	+€0.0023/hr (per +10 GB)

How is the Price Calculated?

The system is simple and transparent. Every server has a Base Configuration (starting point) with a fixed price (e.g., €0.01/hr).

If you need more resources, you simply increase the specific parameter — for instance, every additional 2 GB of RAM adds +€0.0023/hr to your base rate. You decide how much you want to "crank up" your server, and the price updates dynamically with every adjustment.

The final total hourly price is calculated by summing up the base price and any additional parameter upgrades. The final result is always rounded to 2 decimal places (e.g., €0.03).

Flexibility vs. Cost: You can use the Hourly model for long-term projects, but the total monthly cost will be higher than choosing a predefined Monthly Plan. Specifically, hourly rates are approximately 1.46x higher for Budget and 1.77x higher for Premium models compared to our fixed monthly packages. You are paying for the absolute freedom to delete or change your instance at any second. For long-term 24/7 projects, our Monthly plans are always the most economical choice.

3. Intelligent Server Management

We’ve introduced several features to make life easier for Hourly users:

Self-Destruct Button (Destroy): Want to stop paying immediately? One click and the server is deleted, and billing stops instantly.
Price Comparison: The dashboard will automatically notify you when it’s more cost-effective to switch to a Monthly plan if your server configuration matches one of the standard monthly tiers (Which are long-term more cost-effective).

Major Promotion

To celebrate the launch of our Hourly model and the new server deployment flow, we have a special offer. If you prefer the stability of a monthly plan, we have something to sweeten the deal:

Promo Code: DEPLOYMENT

Apply it at checkout to receive:

-45% Discount on any Monthly plan.
Offer valid until April 18, 2026.

Note: This code applies exclusively to Monthly billing cycles.

Conclusion

The introduction of Hourly offers is the next stage in building the most developer-friendly hosting platform on the market. We pride ourselves on giving you tools that adapt to you, not the other way around.

Ready to get started? Head over to the Deployment Wizard and spin up your first hourly server today!

March 2026: VoxiHost DevBlog

2026-04-01T00:00:00Z

March has been an incredibly productive month at VoxiHost. We’ve been listening to your feedback and working hard to bring features that make managing your cloud infrastructure faster, more secure, and more flexible.

From low-level server access to a massive expansion of our supported operating systems, here is everything we’ve rolled out over the past few weeks.

1. Direct Server Access with VNC Console

One of our most requested features is finally live: VNC Console support directly in your dashboard.

We know how frustrating it is to be locked out of your server because of a firewall misconfiguration or a broken SSH config. With the new VNC support, you can access your VPS "at the hardware level" through your browser. This means you can troubleshoot boot issues, fix network settings, or manage your server even if SSH is completely unavailable.

2. 7 New OS Distributions Live (Alma, Rocky, Fedora, CentOS)

We believe in giving you the freedom to choose the environment that fits your workflow. This month, we've significantly expanded our OS library, adding some of the most stable and modern distributions for enterprise and development work.

New additions include:

AlmaLinux 9 & 10 (The perfect CentOS successor)
Rocky Linux 9 & 10 (Community-driven enterprise Linux)
CentOS Stream 9 & 10
Fedora 43 (For those who need the absolute latest packages)

All these distributions are now available for one-click deployment on all our Premium and Budget VPS plans.

Security and convenience shouldn't be a trade-off. To make your life easier, we have implemented Google OAuth support.

You can now link your Google account to VoxiHost and log in with a single click. This not only speeds up your workflow but also allows you to leverage Google’s advanced multi-factor authentication (MFA) to protect your hosting account.

4. Verified Reviews via Trustpilot

Transparency is one of our core values. We’ve redesigned our reviews section and integrated it directly with Trustpilot. You can now see verified feedback from our users with direct links to the original reviews.

We want you to know exactly what to expect from our hardware and support before you even spend a penny.

5. Improving the Platform Experience

Beyond the big features, we’ve made dozens of small improvements:

New Blog Platform: You are looking at it! We launched our blog to bring you more high-quality Linux tutorials and news.
Promotion System: A new smart banner on the homepage will now always show you the best current discounts available.
Bug Fixes: We resolved an issue on the Contact page where special characters were being incorrectly rendered.

What's Next?

March was huge, but we aren't stopping there. We are already working on several networking upgrades and more automated tools for your dashboard.

Stay tuned for more updates, and as always, thank you for choosing VoxiHost!

Ready to try the new VNC console? Log in to your Dashboard and check out your active instances today!

How to Update Fedora 43 & Newer: The Complete Server Guide

2026-03-25T00:00:00Z

Fedora moves fast. It's the distro that ships what RHEL will be running in two years, which means you get bleeding-edge kernels, newer toolchains, and packages that are actually current. The tradeoff is you need to stay on top of updates more actively than you would on a long-term-support distro.

Starting with Fedora 41, the default package manager switched to dnf5, a full rewrite of dnf that's faster, uses less memory, and has a cleaner API. If you're on Fedora 43, you're using dnf5. The command is dnf5, though dnf still works as an alias pointing to the same binary.

Before we start: if you are deploying a fresh server with a premium provider like VoxiHost, the system automatically runs a full package update immediately after deployment on first boot. But as your server runs over time, you will still need to know how to maintain it yourself.

The basics: dnf5 upgrade

To update a Fedora 43 server, you run:

sudo dnf5 upgrade -y

This checks for available updates, downloads them, and installs them in one pass. The -y flag skips the confirmation. That's it for routine updates.

If you want to see what would change before committing:

sudo dnf5 check-upgrade

Short list, nothing gets touched. Good habit before running updates on a machine that's actually serving traffic.

One difference from older dnf: dnf5 separates the concepts of update and upgrade more clearly. In practice, dnf5 upgrade is the command you want, it handles both package updates and dependency resolution. dnf5 update is an alias and works the same way.

Cleaning up (dnf5 autoremove)

After upgrades, orphaned packages pile up. Old kernels, old libraries that newer versions replaced. Clean those up:

sudo dnf5 autoremove -y

Fedora by default also keeps the last two kernel versions installed, which is sensible, it gives you a fallback if something goes sideways. If you want to prune old kernels specifically:

sudo dnf5 repoquery --installonly --latest-limit=-2 -q

That shows you what would be removed. Add --remove to actually do it. Be careful on systems where you don't have out-of-band console access.

Do you need a reboot? (needs-restarting)

Fedora doesn't write a reboot-required file like Ubuntu does. Instead, use:

sudo needs-restarting -r

Exit code 1 means a reboot is needed (usually a kernel update). Exit code 0 means you're fine. If the tool isn't installed:

sudo dnf5 install dnf-utils -y

On a server, you can also check which services are running against outdated libraries and restart only those, avoiding a full system reboot:

sudo needs-restarting -s

This is particularly useful on Fedora, where kernel updates are frequent. Restarting a handful of services is much less disruptive than taking the machine down.

Automating patches with dnf-automatic

For servers that sit in the background without regular manual attention:

sudo dnf5 install dnf-automatic -y

The config file controls what gets updated automatically:

sudo nano /etc/dnf/automatic.conf

If missing package nano install it first:

sudo dnf5 install nano -y

Key settings:

[commands]
# security = only security patches (recommended for servers)
upgrade_type = security

# Actually install the updates, not just download them
apply_updates = yes

# Emit output to the journal
emit_via = stdio

Enable the systemd timer to run it daily:

sudo systemctl enable --now dnf-automatic.timer

Verify it's scheduled:

sudo systemctl status dnf-automatic.timer

On Fedora, security patches come through regularly given how active the project is, so automatic security updates make a real difference.

The quick one-liner

SSH in, do your thing, leave it clean:

sudo dnf5 upgrade -y && sudo dnf5 autoremove -y

Then check needs-restarting -r. Two minutes of work, system stays current.

Upgrading to the next Fedora release

Fedora moves to a new release every six months, and each release is supported for about 13 months. When it's time to move from 43 to 44:

sudo dnf5 system-upgrade download --releasever=44
sudo dnf5 system-upgrade reboot

The upgrade happens on the next boot in a controlled environment. This is the supported path, don't try to manually swap repos and run dnf5 distro-sync, you'll end up in a broken state.

Before upgrading: snapshot the VM, read the Fedora 44 release notes for anything that might break your workload, and if possible test on a clone first.

The SELinux and config file traps

Two things to watch after updates on Fedora:

SELinux denials. If a service stops working after an update, check the audit log:

sudo ausearch -m avc -ts recent

If missing package ausearch install it first:

sudo dnf5 install ausearch -y

A policy update might have changed what your service is allowed to do, or an updated binary might need a new label. Most of the time this sorts itself out, but it's the first thing to check.

RPM config file conflicts. When a package ships a new default config, it creates a .rpmnew file instead of overwriting yours:

sudo find /etc -name "*.rpmnew" -o -name "*.rpmsave" 2>/dev/null

Check those after any significant update. Merge what matters, delete what doesn't.

Fedora is a solid server operating system if you're staying current. The six-month release cycle sounds fast, but the system-upgrade path is smooth and rarely causes surprises. If you want a clean VPS to test a Fedora upgrade without risking your production machine, our Budget VPS plans are a cheap way to run through the whole process.

How to Update AlmaLinux, CentOS Stream & Rocky Linux: The Complete Server Guide

2026-03-25T00:00:00Z

If you're running AlmaLinux, CentOS Stream, or Rocky Linux, you're on distros that take stability seriously. But stability doesn't mean you can leave the system untouched for months. Packages still get CVEs, the kernel still gets security patches, and OpenSSH vulnerabilities wait for no one.

Good news: all three distros share the exact same package manager, dnf. Same commands, same behavior, same output. So this guide applies to AlmaLinux 9, AlmaLinux 10, CentOS Stream 9, CentOS Stream 10, Rocky Linux 9, and Rocky Linux 10 without any changes.

The basics: dnf update and dnf upgrade

Unlike apt, which splits "refresh index" and "install updates" into two separate commands, dnf update does both in one shot. It fetches the latest metadata and installs whatever's new:

sudo dnf update -y

That's genuinely all you need for routine maintenance. The -y flag skips confirmation prompts, which is convenient when you're SSH'd in to do something else and don't want to babysit a package upgrade.

If you want to check what would be updated before actually running it:

sudo dnf check-update

This is the equivalent of apt update, it shows you the list of available updates without touching anything. Good habit before running updates on something you're not sure about.

One note on naming: dnf upgrade is an alias for dnf update. They're identical on these three distros. You'll see both in documentation; don't let that confuse you.

Cleaning up (dnf autoremove)

After updates, old packages tend to accumulate. Dependencies that were pulled in for something that's since been updated, libraries nothing uses anymore. Clean those up with:

sudo dnf autoremove -y

Same concept as apt autoremove. Not critical to run every time, but worth doing after a major update or once a month. It keeps the system clean and the disk usage predictable.

Do you need a reboot? (needs-restarting)

Kernel updates don't take effect until you reboot. Unlike Debian-based systems that leave a /var/run/reboot-required file, RHEL-family distros use a tool called needs-restarting:

sudo needs-restarting -r

If the command exits with code 1 and tells you a reboot is required, you need one. If it exits cleanly with code 0, you're fine. This tool is part of the dnf-utils package, if it's not installed:

sudo dnf install dnf-utils -y

It can also check for services that need restarting without a full reboot. Worth knowing if you're trying to minimize downtime:

sudo needs-restarting -s

This lists services that have loaded outdated libraries. Restarting those individually is often enough to pick up security fixes without taking the whole system down.

Automating patches with dnf-automatic

For servers you don't log into daily, automatic security updates are a practical safety net. Install the package:

sudo dnf install dnf-automatic -y

Then edit the config to set the behavior you want:

sudo nano /etc/dnf/automatic.conf

If missing package nano install it first:

sudo dnf install nano -y

The key settings:

[commands]
# Options: default, security, security-severity:Critical, minimal, minimal-security
upgrade_type = security

# Actually apply the updates (not just download)
apply_updates = yes

# Reboot if required after updates (be careful in production)
reboot = never

Set upgrade_type = security to only auto-apply security patches, not general package updates. That's the sensible default for a production machine, you don't want feature releases going in automatically, just CVE fixes.

Enable and start the timer:

sudo systemctl enable --now dnf-automatic.timer

Check that it's active:

sudo systemctl status dnf-automatic.timer

The quick update one-liner

When you SSH in for something else and want to leave the server in a clean state:

sudo dnf update -y && sudo dnf autoremove -y

Run it, let it finish, check needs-restarting -r, done. Takes a minute, saves you from finding out your server was running a year-old kernel next time something breaks.

Upgrading to a new major release

Jumping from AlmaLinux 9 to 10, CentOS Stream 9 to 10, or Rocky Linux 9 to 10 is a bigger operation than a routine update. Each project has its own migration tool:

For AlmaLinux, the official path is through ELevate, a tool from the AlmaLinux project that handles the switch between major versions including dependency resolution and package replacement. Same tooling also handles Rocky Linux and CentOS Stream migrations.

Before attempting any major release upgrade:

Take a full snapshot of the VM
Read the release notes for the target version
Test on a non-production clone first

Don't do a major upgrade via SSH on a machine with no out-of-band access. If something goes wrong mid-upgrade, you'll want a way in.

What to watch out for

The most common gotcha on RHEL-family systems is SELinux. If an update changes file permissions or binary paths, SELinux policies might block the service from starting correctly after the update. Check the audit log if something stops working after an update:

sudo ausearch -m avc -ts recent

If missing command ausearch install it first:

sudo dnf install setroubleshoot-server -y

Config file handling in dnf is somewhat more aggressive than apt. When a package ships a new default config, dnf might overwrite your customized version with a .rpmnew suffix on the original. Always check for those after a major update:

sudo find /etc -name "*.rpmnew" -o -name "*.rpmsave"

Look at what's changed, decide if you need to merge anything, then clean up.

If you want a clean RHEL-based VPS to practice this on without risking anything, our Budget VPS plans are cheap enough to spin up a test box, run the whole process, and discard it.

How to Transfer Files to Your VPS using SFTP & FileZilla

2026-03-25T00:00:00Z

When you rent a brand new Linux VPS, you are usually greeted with a terrifying black terminal screen.

While you can technically upload files directly through the command line using scp or rsync, dragging and dropping your website's folder using a visual interface is infinitely easier, especially for beginners.

The absolute best way to do this is using SFTP (Secure File Transfer Protocol) with a free desktop client called FileZilla.

Important Note: Do not confuse standard FTP with SFTP. Standard FTP sends your passwords and files over the internet in plain, unencrypted text. SFTP routes all FTP commands through your server's secure SSH tunnel. Because of this, you do not need to install an FTP server like vsftpd on your Linux VPS. If you have an SSH connection, SFTP will work automatically!

Step 1: Download FileZilla

If you haven't already, download the FileZilla Client (not the Server version) from the official FileZilla website. It is completely free and available for Windows, macOS, and Linux.

Step 2: Configure the Site Manager

Do not use the "Quickconnect" bar at the very top of the application. It does not securely save your SSH keys or complex server settings.

Instead, open the Site Manager. You can find it by clicking the very first icon on the top-left toolbar, or by navigating to File > Site Manager (or CTRL + S on Windows).

Click New Site.
Name the site something recognizable, like "My VPS Web Server".

Step 3: Select the SFTP Protocol

Look at the right side of the Site Manager window. Under the Protocol dropdown, it defaults to standard FTP.

You must change this. Click the dropdown and select:
SFTP - SSH File Transfer Protocol

If you skip this step, FileZilla will constantly fail to connect to your server securely.

Step 4: Add Your Credentials or SSH Key

Now you need to tell FileZilla where to go and how to log in.

Host: Enter your server's public IP address (e.g., 192.168.1.100).
Port: Leave this blank unless you have manually changed your SSH port.
Logon Type: This is where most beginners get stuck. Change this to Key file if you use SSH keys, or Normal if you use a password.
User: Enter your username (usually root for a fresh server deployment).
Key file: Click Browse and select the private key file on your computer.

If you use a Password:

While we highly discourage using passwords for server access (as they are vulnerable to brute-force attacks), if you must:

Set the Logon Type to Normal.
User: Type root (or whatever user account you created).
Password: Enter your standard SSH password.

If you use SSH Keys (Recommended):

If you generated an SSH key pair (like id_rsa or id_ed25519) to log into your server securely without a password:

Set the Logon Type to Key file.
User: Type your username (like root or admin).
Click the Browse button and locate the private key file on your desktop (not the one ending in .pub).

(If FileZilla asks for a password during the connection, it is asking for the passphrase you put on your private key, not the server's root password).

Step 5: Connect and Transfer

Click the Connect button at the bottom of the window.

The very first time you connect to the server from this computer, a scary-looking window will pop up titled "Unknown host key". This is a standard security measure preventing "Man in the Middle" attacks.
Check the box that says "Always trust this host..." and click OK.

The FileZilla Interface

If your credentials are correct, you will successfully connect. You are now looking at two massive split windows:

Left Side: Your local computer (your hard drive).
Right Side: Your Linux VPS (the remote server).

To transfer files, simply drag and drop them from the left window to the right window.

A common place to upload web files is:
/var/www/html/

Navigate there in the right-side window, drag your index.html from your desktop (left side) to that folder, and your website is live!

If you don't have a server to practice on, Budget VPS plans from VoxiHost are a perfect, affordable playground to learn how to manage Linux without breaking the bank. You can deploy a clean instance in seconds and start transferring files immediately.

How to Set Up a WireGuard VPN Server on Ubuntu & Debian

2026-03-25T00:00:00Z

WireGuard is a modern, revolutionary VPN protocol that has completely dominated the privacy landscape. It is significantly faster, more secure, and connects almost instantaneously without heavily draining cell phone batteries compared to older standards like OpenVPN.

While you can manually configure IP tables and NAT forwarding rules to install it, you shouldn't. It is extremely error-prone for beginners.

Instead, the global open-source community relies on a highly audited, universally trusted bash script by developer Angristan to seamlessly configure WireGuard on any VPS securely in less than two minutes.

Here is how to deploy your own private VPN on any Linux VPS to bypass restrictions and browse securely.

Step 1: Download the Trusted Install Script

Log into your server via SSH. Make sure you update your system before executing the installation:

sudo apt update && sudo apt upgrade -y

Now, download the official installation script directly from Angristan's GitHub repository:

curl -O https://raw.githubusercontent.com/angristan/wireguard-install/master/wireguard-install.sh

Step 2: Run the Auto-Installer

Before you can run the file, you must tell Linux that this text file is actually an executable script:

sudo chmod +x wireguard-install.sh

Now, execute the script with root privileges:

sudo ./wireguard-install.sh

Step 3: The Configuration Prompts

The brilliant thing about this script is that it automatically detects your server's network interfaces, public IP addresses, and DNS configurations.

When you run the script, it will ask you to confirm several settings. For 99% of deployments, you should simply press Enter to accept the default values for every single prompt.

The prompts will look roughly like this:

IPv4 or IPv6 public address: (Auto-filled with your IP)
Public interface: (Auto-filled, usually eth0 or enp3s0)
WireGuard port: [51820]
First DNS resolver to use for the clients: [1.1.1.1]

Press Enter through all of them. The script will then rapidly download the wireguard packages via apt, configure all the complex IP forwarding traffic rules in the Linux kernel, set up the firewall routing, and generate the master server encryption keys.

Step 4: Generate Your First Client Key

WireGuard uses highly secure peer-to-peer cryptography. To connect your phone or laptop to the VPN, you need to generate a client configuration file (.conf) for each device.

Immediately after installing the server packages, the script will automatically prompt you to create your first client:

Client name:

Type a recognizable name without spaces, like daniel_iphone or my_macbook, and press Enter.

Client's DNS server: [1]

Press Enter to accept the default DNS (usually Cloudflare or Google).

The script does something incredibly helpful here. Not only does it create the .conf file in your root folder, but it also renders a massive QR code directly in your terminal window using ASCII characters!

Step 5: Connect Your Devices

Connecting a Mobile Phone (iOS/Android):

Connecting your mobile phone is absurdly simple.

Go to the App Store or Google Play Store.
Download the official, free WireGuard app.
Open the app and tap the + icon to add a new tunnel.
Select "Create from QR code".
Point your phone's camera at the giant QR code currently sitting on your computer terminal screen.

Name your connection, flip the toggle switch to "On", and you are immediately encrypting all your mobile traffic through your VPS!

Connecting a Laptop or PC (Windows/Mac/Linux):

Laptops cannot scan terminal QR codes easily. Instead, you need to retrieve the actual .conf file the script generated.

If you named your client my_macbook, the script saved a file named my_macbook.conf in the directory where you ran the script (usually /home/youruser/ or /root/).

Download the my_macbook.conf file to your personal computer. (The easiest way to do this securely is using an SFTP client like FileZilla or WinSCP).
Download the official WireGuard application for Windows or Mac Desktop from their website.
Click "Import tunnel(s) from file" and select .conf file.
Click "Activate". Your traffic is now secured!

Generating More Clients

If you want to add a second laptop, a smart TV, or grant secure connection access to a team member, you do not need to reinstall WireGuard.

Simply run the script again:

sudo ./wireguard-install.sh

Because WireGuard is already installed, the script transforms cleanly into a management menu.

Press 1 to instantly generate another .conf file and QR code.

If you want a safe playground to test your WireGuard configuration, Budget VPS plans from VoxiHost are a perfect starting point. You can deploy a fresh instance in seconds and start building your private network right away.

How to Set Up SSL with Let's Encrypt & Certbot on Ubuntu & Debian: The Complete Guide

2026-03-25T00:00:00Z

In the modern web, serving your website over plain HTTP is no longer acceptable. Browsers will aggressively warn users that your site is "Not Secure," search engines like Google will heavily penalize your SEO rankings, and any submitted forms (like passwords or credit cards) will be transmitted in plain text for anyone to intercept.

You need an SSL/TLS certificate to enable HTTPS. Years ago, this was an expensive and deeply frustrating process. Today, thanks to the non-profit Let's Encrypt project and their automated client called Certbot, you can get enterprise-grade, cryptographically secure certificates completely for free in about two minutes.

Prerequisites

Before you begin, you must have two things in place:

A web server with a configured domain block: You must have either Nginx or Apache installed, and a Server Block (Nginx) or Virtual Host (Apache) officially configured for your domain name. If you haven't done this, check out our Nginx installation guide or Apache installation guide.
Proper DNS settings: Your domain (e.g., your_domain.com and www.your_domain.com) must have A records actively pointing to your server's public IP address. Certbot will fail if the domain doesn't resolve to your server.

Step 1: Install Certbot

Certbot is the tool that reaches out to the Let's Encrypt servers, proves you own the domain, downloads the certificates, and injects them directly into your web server's configuration files.

First, update your package index:

sudo apt update

Next, you need to install Certbot along with its plugin for your specific web server.

If you are using Nginx:

sudo apt install certbot python3-certbot-nginx -y

If you are using Apache:

sudo apt install certbot python3-certbot-apache -y

Step 2: Confirm Firewall Settings

Certbot needs to communicate over HTTP (Port 80) to validate your domain, and your secure website will be served over HTTPS (Port 443).

If you followed our UFW Firewall guide, you need to ensure the firewall is allowing this traffic.

For Nginx:

sudo ufw status

If you only see Nginx HTTP allowed, you need to upgrade to Nginx Full:

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

For Apache:
If you only see Apache allowed in your sudo ufw status, upgrade the profile:

sudo ufw allow 'Apache Full'
sudo ufw delete allow 'Apache'

Step 3: Obtain and Install the SSL Certificate

This is where the magic happens. By using the web server plugins you installed in Step 1, Certbot will handle the entire validation, downloading, and configuration process automatically.

Run Certbot for Nginx:

sudo certbot --nginx -d your_domain.com -d www.your_domain.com

Run Certbot for Apache:

sudo certbot --apache -d your_domain.com -d www.your_domain.com

The Certbot Prompts

When you run the command for the first time, Certbot will ask you a series of questions:

Email Address: You must provide a valid email address. Let's Encrypt uses this strictly to notify you of impending expirations (if auto-renewal fails) or major security events.
Terms of Service: Type Y to agree to the Let's Encrypt TOS.
EFF Mailing List: Type Y or N based on whether you want promotional emails from the Electronic Frontier Foundation (the creators of Certbot).

Certbot will then communicate with the Let's Encrypt API and run a challenge to verify you actually control the domain.

If it succeeds, it will automatically edit your Nginx .conf or Apache Virtual Host file to enable HTTPS. Modern versions of Certbot will automatically configure your server to aggressively redirect all unencrypted HTTP traffic entirely to the secure HTTPS connection.

When it finishes, navigate to https://your_domain.com in your browser to verify the padlock icon appears!

Step 4: Verify Auto-Renewal

Let's Encrypt certificates are absolutely free, but to minimize the impact of stolen or abandoned certificates, they only last for 90 days.

Thankfully, you never have to repeat Step 3. The certbot package on Ubuntu and Debian installs a systemd timer (a background background scheduled task) that runs twice a day. It checks for any certificates expiring in the next 30 days and smoothly auto-renews them in the background without dropping web traffic.

You can verify the timer is active by running:

sudo systemctl status certbot.timer

You should see "Active: active (waiting)".

To test the renewal process and ensure there are no configuration errors blocking it, you can run a dry run:

sudo certbot renew --dry-run

If the dry run finishes without any errors, you are successfully set up! Your server is now continuously and permanently secured.

Need a blistering-fast environment ready to deploy secure web apps? Pick up an exceptionally affordable Budget VPS, setup your Nginx block, slap a free SSL on it, and launch your project safely to the world.

How to Set Up Netdata for Real-Time VPS Monitoring

2026-03-25T00:00:00Z

Command-line tools like htop and df are excellent for quick troubleshooting when you are currently logged into an SSH session. But what if you need historical graphs? What if you want to see exactly how your CPU reacted when a burst of traffic hit your website 2 hours ago?

For that, you need a full monitoring suite.

While enterprise teams rely on complex stacks like Prometheus and Grafana (which are tedious to set up and difficult to configure), there is a radically simpler, instantly beautiful alternative: Netdata.

Netdata installs in a single command, automatically detects all running services (like Nginx, Apache, MySQL, Docker), and instantly generates thousands of real-time metrics presented in a stunning web dashboard.

Step 1: Install Netdata Using the Kickstart Script

Netdata provides an official, universally supported "kickstart" script. This handles identifying your OS architecture, downloading the required package dependencies, and installing the monitoring agent perfectly whether you are running Ubuntu, Debian, AlmaLinux, CentOS, or Fedora.

First, download the script to a temporary folder and execute it:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

The script will prompt you for confirmation. Press Y to confirm.

It handles everything invisibly in the background. Once the installation is finished, Netdata automatically registers itself as a systemd service, starts running its daemons, and configures itself to boot whenever your server starts.

To verify it is running smoothly, check the service status:

sudo systemctl status netdata

Look for active (running).

Step 2: Configure the Firewall

Netdata creates a lightweight web server strictly for serving its dashboard. By default, this web server listens on Port 19999.

Because you are likely (and should be!) running a firewall, port 19999 is blocked from the public internet. You need to explicitly open it so you can reach the dashboard from your browser.

If you are using UFW (Ubuntu/Debian):

sudo ufw allow 19999/tcp

If you are using firewalld (AlmaLinux/CentOS/Fedora):

sudo firewall-cmd --permanent --add-port=19999/tcp
sudo firewall-cmd --reload

Step 3: Access Your Dashboard

You are completely set up!

Open your favorite web browser and navigate to your server's public IP address, appending the :19999 port number.

http://your_server_ip:19999

You will immediately be loaded directly into the Netdata Local Dashboard. No passwords, no configurations, no waiting.

Scroll down the right-hand bar. Netdata will have already found and mapped graphs for:

CPU usage by active core
Hard drive I/O (read/write speeds)
Total and available Memory (RAM) handling
Network bandwidth interfaces
Interrupts, IPv4 tracking, and even background container (Docker) statistics.

Security Note

By default, Netdata's local dashboard is accessible to anyone who has your server's IP address and knows to append :19999. While they cannot see your passwords or private code, they can map out what software you are running based on identifying the graphs (e.g., admitting you run MySQL to attackers).

If you are running a production server, it is highly recommended to eventually bind Netdata strictly to localhost and access it via a Reverse Proxy (using an Nginx Server Block) with a required password prompt (htpasswd).

However, for a fresh testing or development environment, leaving the port open is fine for rapid monitoring. If you want to dive into complex performance metrics or monitor massive database loads efficiently, grab a remarkably robust Budget VPS, spin up some intense applications, install Netdata, and watch the graphs dance perfectly in real-time.

How to Set Up a LEMP Stack (Linux, Nginx, MariaDB, PHP) on Ubuntu & Debian

2026-03-25T00:00:00Z

The LEMP stack is the modern, high-performance foundation for millions of websites worldwide. It is an acronym representing the four critical pieces of software required to host dynamic, database-driven applications (like WordPress or Laravel):

Linux: The operating system (Ubuntu or Debian).
ENginx (pronounced Engine-X): The lightning-fast web server.
MariaDB: The community-driven, drop-in replacement for MySQL.
PHP: The backend processing language.

Compared to the older LAMP (Apache) stack, LEMP is highly favored for environments handling heavy, concurrent traffic because of Nginx's asynchronous architecture.

Step 1: Install Nginx (The Web Server)

First, update your package index to ensure you are downloading the latest software versions.

sudo apt update
sudo apt upgrade -y

Install Nginx:

sudo apt install nginx -y

If you followed our UFW Firewall Guide, you need to allow Nginx traffic through the firewall. Open both HTTP (Port 80) and HTTPS (Port 443):

sudo ufw allow 'Nginx Full'

You can verify Nginx is running by typing your server's public IP address into your web browser. You should see the standard "Welcome to nginx!" page.

Step 2: Install MariaDB (The Database)

Now that you have a web server, you need a database system to store and manage your application's data. MariaDB is a highly optimized, fully open-source fork of MySQL that is standard on modern Linux distributions.

Install the MariaDB server:

sudo apt install mariadb-server -y

Once installed, the database is active but completely unsecured. You need to lock it down using the built-in security script.

sudo mysql_secure_installation

You will be asked a series of prompts:

Current root password: Press Enter (there is no password yet).
Switch to unix_socket authentication: Type Y.
Change the root password: Type N (modern MariaDB secures the root user dynamically using your Linux sudo privileges).
Remove anonymous users: Type Y.
Disallow root login remotely: Type Y.
Remove test database: Type Y.
Reload privilege tables: Type Y.

Your database is now locked down and ready.

Step 3: Install PHP (The Processing Language)

Nginx is incredibly fast at serving static files (HTML, images, CSS), but it cannot process dynamic PHP code natively the way Apache can.

To process PHP, we must install PHP-FPM (FastCGI Process Manager). Nginx will pass all .php files it receives directly to this background processor. You also need the php-mysql package so PHP can talk to your MariaDB database.

Install both packages:

sudo apt install php-fpm php-mysql -y

Note: Depending on your exact Debian/Ubuntu version, apt will automatically install the correct PHP version (e.g., php8.1-fpm or php8.3-fpm). Make a mental note of which version it installs, as you'll need it in the next step.

Step 4: Configure Nginx to use PHP

We need to explicitly tell Nginx how to handle PHP files.

Let's assume you are configuring the default Nginx Server Block. Open the default configuration file in nano:

sudo nano /etc/nginx/sites-available/default

Look for the index directive. You need to add index.php to the very beginning of the list, telling Nginx to prioritize PHP files over standard HTML files.

# Add index.php before index.html
index index.php index.html index.htm index.nginx-debian.html;

Next, scroll down to the location ~ \.php$ block. Uncomment (remove the # symbol) from the relevant lines so it looks exactly like this. Make sure the phpX.X-fpm.sock matches the version you installed in Step 3!

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
}

Save the file and exit nano.

Test your Nginx configuration for syntax errors:

sudo nginx -t

If it reports syntax is ok, reload Nginx to apply the changes:

sudo systemctl reload nginx

Step 5: Test PHP Processing on Nginx

To prove that Nginx is successfully handing off code to PHP-FPM, we will create a classic PHP info script.

Create a new file in your web root directory:

sudo nano /var/www/html/info.php

Paste the following PHP code:

<?php
phpinfo();
?>

Save and exit.

Open your browser and navigate to: http://your_server_ip/info.php

You should see a massive, detailed purple and gray table outlining your server's exact PHP configuration and modules. This proves your complete LEMP stack is functioning perfectly!

Crucial Warning: Delete this file immediately. Leaving it publicly accessible exposes extremely sensitive information about your server's configuration to hackers.

sudo rm /var/www/html/info.php

Your server is now a fully powered production machine. Ready to host millions of hits? Deploy an intensely fast Premium VPS, install your LEMP stack, get a free Let's Encrypt SSL, and launch your database-driven application directly to the world.

How to Set Up a LAMP Stack (Linux, Apache, MySQL, PHP) on Ubuntu & Debian

2026-03-25T00:00:00Z

The LAMP stack is the undisputed grandfather of open-source web hosting. For decades, it has been the most reliable, thoroughly documented, and widespread foundation for hosting dynamic web applications like WordPress, Drupal, and Joomla.

LAMP stands for four components:

Linux: The operating system (Ubuntu or Debian).
Apache: The incredibly robust, highly customizable web server.
MySQL: The most popular relational database management system.
PHP: The server-side scripting language handling the backend logic.

Compared to the newer LEMP (Nginx) stack, LAMP remains universally beloved because Apache processes PHP dynamically natively (no need to configure external FPM sockets) and relies on highly flexible .htaccess files for easy, per-directory configuration overrides.

Step 1: Install Apache (The Web Server)

Before installing any software, always update your local package indexes so you are downloading the latest security patches.

sudo apt update
sudo apt upgrade -y

Now, install the Apache web server (the package is named apache2 on Debian/Ubuntu systems):

sudo apt install apache2 -y

If you are running the ufw firewall (which you should be, per our Security Guide), you need to allow Apache traffic to pass through. You want to open both HTTP (Port 80) and HTTPS (Port 443).

sudo ufw allow 'Apache Full'

To verify your web server is alive, type your server's public IP address into your favorite web browser (http://your_server_ip). You should see the default "Apache2 Ubuntu Default Page".

Step 2: Install MySQL (The Database)

Your server can serve static HTML now, but to store application data (like user accounts, blog posts, and settings), you need a database.

Install the official MySQL server:

sudo apt install mysql-server -y

Once the installation finishes, the database is running but its default configuration is dangerously open. You must lock it down using the interactive security script:

sudo mysql_secure_installation

You will be asked several questions to configure the security profile:

Validate Password Plugin: Type y if you want MySQL to actively block weak passwords, or n to skip it.
Remove anonymous users: Type y.
Disallow root login remotely: Type y (root should only ever access the database from inside the server).
Remove test database: Type y.
Reload privilege tables: Type y.

MySQL is now secure.

Step 3: Install PHP

You have a web server and a database, but they cannot communicate with each other yet, nor can they process dynamic code. You need PHP.

For Apache, installing PHP requires three main packages: the core php package, the php-mysql extension allowing PHP scripts to talk to your database, and the vital libapache2-mod-php package, which magically binds PHP processing directly into the Apache runtime.

sudo apt install php libapache2-mod-php php-mysql -y

Step 4: Configure Apache Index Priorities

When a user visits a directory on your website (like yoursite.com/blog/), Apache automatically looks for a default "index" file to serve. By default, it looks for index.html first, and if it doesn't find it, it eventually looks for index.php.

For dynamic applications, we want Apache to prioritize index.php.

Open the dir.conf file in the nano text editor:

sudo nano /etc/apache2/mods-enabled/dir.conf

It will look like this:

<IfModule mod_dir.c>
    DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
</IfModule>

Move the index.php string from the middle of the list directly to the first position, immediately after DirectoryIndex, so it looks like this:

<IfModule mod_dir.c>
    DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm
</IfModule>

Save and exit nano.

Whenever you alter Apache's configuration modules, you inherently must restart the web server for the changes to take effect:

sudo systemctl restart apache2

Step 5: Test the LAMP Stack

Your environment is complete! However, the golden rule of system administration is to verify your work. We are going to write a tiny PHP script to prove that Apache can process dynamic code.

Create a new file in Apache's default web root directory:

sudo nano /var/www/html/info.php

Paste the standard initialization function:

<?php
phpinfo();
?>

Save the file. Open your web browser and navigate to http://your_server_ip/info.php.

If the installation was successful, you will be greeted by a massive, highly detailed table detailing your PHP version, installed modules, memory limits, and Apache integration settings.

Critical Security Warning: The info.php page contains an extensive roadmap of your internal server architecture. Leaving this file public is a massive security risk. Once you have confirmed the stack works, delete the file immediately:

sudo rm /var/www/html/info.php

Congratulations! You have successfully built a tried, tested, and rock-solid foundation for hosting on Linux. Do you have a heavy e-commerce site, forum, or high-traffic blog ready to launch? Pair your new LAMP stack with one of our high-tier Premium VPS environments or a highly cost-effective Budget VPS, install a free SSL via Certbot, and build the ultimate web experience.

How to Set Up fail2ban on Ubuntu & Debian: The Complete Server Guide

2026-03-25T00:00:00Z

fail2ban watches your auth logs and bans IP addresses that rack up too many failed login attempts. It's one of those tools that runs quietly in the background and only makes itself known when you check the ban list and realize it's blocked hundreds of addresses that were hammering your SSH port.

It's not a silver bullet, if you've already set up SSH key auth with passwords disabled, brute-force attacks against SSH are already useless. But fail2ban covers everything else: web services, mail servers, any application that logs authentication failures. And for servers where password auth is still in use for some services, it's a practical first line of defense.

fail2ban is often not installed by default on fresh Linux images, though premium providers like VoxiHost pre-install it on their templates with a sensible baseline configuration. If you need to install it from scratch or tune it for your specific setup, this guide covers that too.

Installing fail2ban

If it's not already installed:

sudo apt update
sudo apt install fail2ban -y

Once installed, the service starts automatically. Verify:

sudo systemctl status fail2ban

Configuring fail2ban jails

fail2ban works through "jails", each jail monitors a specific log file for a specific failure pattern, and bans IPs that exceed the threshold.

Never edit /etc/fail2ban/jail.conf directly. That file gets overwritten on updates. Instead, create a local override:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Now edit jail.local:

sudo nano /etc/fail2ban/jail.local

Global defaults

At the top of the file, set global defaults that apply to all jails:

[DEFAULT]
# IP whitelist, never ban these
ignoreip = 127.0.0.1/8 ::1 YOUR.HOME.IP.ADDRESS

# Ban duration in seconds (3600 = 1 hour, -1 = permanent)
bantime = 3600

# Time window to count failures in
findtime = 600

# How many failures before a ban
maxretry = 5

# Use systemd journal backend (better on modern Ubuntu/Debian)
backend = systemd

Add your home or office IP to ignoreip, you don't want to lock yourself out after mistyping your password a few times.

SSH jail

Scroll down to find the [sshd] section, or add it:

[sshd]
enabled = true
port = ssh
# If you changed the SSH port, put the new port here:
# port = 2222
filter = sshd
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400

A shorter maxretry and longer bantime than the global defaults are reasonable for SSH, three failed attempts in the window bans for a full day.

Integrating with ufw

By default, fail2ban uses iptables to ban IPs. If you're running ufw, tell fail2ban to use it instead for consistency:

In jail.local under [DEFAULT]:

banaction = ufw

This inserts ufw deny rules for banned IPs, which plays nicely with your existing firewall config.

Enabling and verifying fail2ban

Reload fail2ban to apply your config changes:

sudo systemctl restart fail2ban

Check the status of the SSH jail specifically:

sudo fail2ban-client status sshd

You'll see something like:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed: 47
|  `- File list: /var/log/auth.log
`- Actions
   |- Currently banned: 3
   |- Total banned: 12
   `- Banned IP list: 203.0.113.1 198.51.100.5 ...

That "currently banned" and "total banned" count are your proof it's working.

Unbanning an IP

If you accidentally ban yourself or a legitimate user:

sudo fail2ban-client set sshd unbanip 203.0.113.1

Replace the IP with the one you need to unban. Changes take effect immediately, no restart required.

Checking the fail2ban log

See what fail2ban has been doing:

sudo tail -f /var/log/fail2ban.log

You'll see entries for each ban and unban action in real time. On a public-facing server, the log fills up quickly. If you see thousands of attempts from the same subnet, that's a hint to ban the whole subnet range manually through ufw rather than letting fail2ban handle individual IPs.

Protecting Nginx and Apache

fail2ban ships with filters for common web services. To add Nginx protection:

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 5

[nginx-limit-req]
enabled = true
filter = nginx-limit-req
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10

For Apache:

[apache-auth]
enabled = true
filter = apache-auth
port = http,https
logpath = /var/log/apache2/error.log
maxretry = 5

After adding jails, restart fail2ban:

sudo systemctl restart fail2ban
sudo fail2ban-client status

The last command shows all active jails and their ban counts.

If you want a clean VPS to test fail2ban on before rolling it out to production, our Budget VPS plans are cheap enough to run through the whole setup without risk.

How to Set Up fail2ban on AlmaLinux, CentOS, Rocky Linux & Fedora: The Complete Server Guide

2026-03-25T00:00:00Z

fail2ban monitors authentication logs and automatically bans IP addresses that accumulate too many failed login attempts. On a server with a public IP, it quietly blocks hundreds of automated scanners that would otherwise churn through your ports looking for weak credentials.

For servers running AlmaLinux, CentOS Stream, Rocky Linux, or Fedora, the setup is almost identical to any other Linux system. The one meaningful difference is the firewall backend: these distros use firewalld, and fail2ban needs to know that so it inserts bans through firewalld rather than attempting raw iptables commands that might conflict.

While premium providers like VoxiHost pre-install fail2ban on their templates with a working baseline configuration, most default Linux images do not. This guide walks through installing and tuning it for your specific needs.

Installing fail2ban

On RHEL-based systems, fail2ban is available from EPEL (Extra Packages for Enterprise Linux). If it's not already installed:

sudo dnf install epel-release -y
sudo dnf install fail2ban -y

On Fedora, it's in the main repos:

sudo dnf install fail2ban -y

Enable and start it:

sudo systemctl enable --now fail2ban

Configuring fail2ban jails

fail2ban's behavior is controlled by "jails", each one watches a specific log for failure patterns and bans offending IPs.

Don't edit /etc/fail2ban/jail.conf directly. Package updates overwrite it. Create a local override instead:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Global defaults

[DEFAULT]
# Never ban these IPs
ignoreip = 127.0.0.1/8 ::1 YOUR.HOME.IP.ADDRESS

# Ban duration in seconds (86400 = 24 hours, -1 = permanent)
bantime = 3600

# Window to count failures in
findtime = 600

# Failures before ban
maxretry = 5

# Use systemd journal (correct backend for these distros)
backend = systemd

Add your home IP to ignoreip, saves you from a frustrating self-lockout.

firewalld integration

This is the critical difference from Debian-based systems. fail2ban defaults to iptables, which conflicts with firewalld. Set the correct backend:

[DEFAULT]
# Use firewalld for banning (required on RHEL/Fedora)
banaction = firewallcmd-ipset
banaction_allports = firewallcmd-allports

Without this, fail2ban may appear to work but won't actually be blocking anything, or will create iptables rules that firewalld ignores.

SSH jail

Find or add the [sshd] section:

[sshd]
enabled = true
port = ssh
# If you changed the SSH port:
# port = 2222
filter = sshd
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400

Three strikes and you're out for 24 hours is a reasonable policy for SSH.

Enabling and verifying fail2ban

Apply the configuration:

sudo systemctl restart fail2ban

Check the SSH jail status:

sudo fail2ban-client status sshd

Expected output:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed: 34
|  `- Journal matches: _SYSTEMD_UNIT=sshd.service
`- Actions
   |- Currently banned: 2
   |- Total banned: 8
   `- Banned IP list: 203.0.113.45 198.51.100.12

If Currently banned is non-zero, something already tried and failed against your SSH. Good, it's working.

Verify that firewalld is actually enforcing the bans:

sudo firewall-cmd --list-rich-rules | grep fail2ban

You should see fail2ban-sshd rules listed. If that command returns nothing, the banaction wasn't set correctly, go back and check jail.local.

Unbanning an IP

To remove a specific ban immediately:

sudo fail2ban-client set sshd unbanip 203.0.113.45

No restart needed. The firewalld rule is removed on the spot.

Checking the logs

Watch what fail2ban is doing in real time:

sudo tail -f /var/log/fail2ban.log

On a public server you'll see this fill up quickly. Ban events, unban events, and occasionally errors if something is misconfigured. If you stopped seeing bans but know SSH is still getting hammered, check whether fail2ban is still running:

sudo systemctl status fail2ban

Protecting web services

fail2ban ships with filters for Nginx and Apache. Add jails for them:

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 5

[nginx-limit-req]
enabled = true
filter = nginx-limit-req
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10

Restart after adding jails:

sudo systemctl restart fail2ban
sudo fail2ban-client status

The status command shows all active jails. Each one you've enabled should appear with its own counter.

SELinux note

On systems where SELinux is enforced (which is the default), fail2ban generally works without issues because it interacts with firewalld at a higher level. If you see permission denials in /var/log/audit/audit.log related to fail2ban, check:

sudo ausearch -m avc -ts recent | grep fail2ban

Most common issues are solved by installing the fail2ban package through the official repos (which includes correct SELinux contexts) rather than manual installation.

If you want a clean RHEL-based server to test this setup on, our Budget VPS plans let you spin up, configure, and experiment without touching anything important.

How to Set Up Docker Compose: A Complete Guide to Managing Multi-Container Apps

2026-03-25T00:00:00Z

Docker Engine is fantastic for running single, isolated containers. But modern applications rarely exist in total isolation. You usually have a web server, a backend API, a database (like MySQL or PostgreSQL), and maybe a caching layer (like Redis).

Trying to start all of those containers manually and manually linking their internal networking together via exhausting, mile-long docker run commands is frustrating and severely prone to human error.

Enter Docker Compose. It allows you to declare your entire application stack in a single, clean .yml (YAML) configuration file. With one central command, Docker builds the internal networks, pulls all necessary images, and launches the entire stack sequentially.

Step 1: Verify Docker Compose is Installed

If you followed our Docker installation guides for Ubuntu/Debian or AlmaLinux/Rocky/Fedora, you actually already have Docker Compose installed!

Modern Docker distributions have shifted away from the old standalone docker-compose binary (written in Python) to a native Docker Compose V2 Plugin (written in Go) embedded directly into the Docker CLI.

Verify it is installed by checking its version:

docker compose version

(Notice there is a space between docker and compose, not a hyphen!)

You should see an output like:
Docker Compose version v2.32.x

If you receive a "command not found" error, you need to install the plugin via your package manager:

Ubuntu/Debian: sudo apt install docker-compose-plugin
AlmaLinux/RHEL: sudo dnf install docker-compose-plugin

Step 2: Set Up a Project Directory

Docker Compose relies absolutely on the context of the directory you run the command in. It looks for a file named docker-compose.yml in whatever folder you are currently inside.

First, let's make a dedicated home for your new project so files stay organized:

mkdir my-webapp
cd my-webapp

Step 3: Create the docker-compose.yml File

Now, let's create a functional, real-world example. We are going to deploy the official WordPress image and attach it to a secure MySQL database backend, cleanly configuring everything through Compose.

Open a new file with nano:

nano docker-compose.yml

Paste the following YAML block entirely:

services:
  database:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: secure_root_password
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: secure_wp_password
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    restart: always
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: database
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: secure_wp_password
      WORDPRESS_DB_NAME: wordpress
    depends_on:
      - database

volumes:
  db_data:

Breaking Down the Configuration:

services: We defined two containers: database and wordpress.
image: Tells Docker which container template to pull from Docker Hub.
environment: Injects secure variables (like passwords and usernames) automatically into the containers so they configure themselves silently on first boot. Look at how the wordpress container knows its host is database (the exact name of the other service). Docker Compose automatically built an internal, invisible network for them to talk to each other seamlessly!
ports: Maps port 8080 on the public internet directly to port 80 (Standard HTTP) inside the internal isolated WordPress container.
volumes: In standard containers, when you delete a container, all the data goes with it. We mapped the database storage to a hard drive volume so your data persists even if you restart or delete the container!
depends_on: Ensures WordPress does not attempt to boot up until the database is successfully running.

Save and exit.

Step 4: Spin it Up

With one file, your entire infrastructure is declared. To launch it, run the up command. The -d flag tells it to run "detached" in the background so you can keep using your terminal console:

docker compose up -d

Docker will automatically:

Create a dedicated internal network for my-webapp.
Pull the heavy MySQL and WordPress images.
Start the database, assign the passwords, and build the persistent storage partition.
Start the WordPress server, attach it to the network, and map port 8080.

Once finished, open your web browser and navigate to your server's IP address combined with port 8080:
http://your_server_ip:8080

Security Warning: Docker manages its own network rules through iptables. When you use a ports: mapping in your docker-compose.yml file, Docker will bypass your UFW firewall completely. To keep a service private, map it to 127.0.0.1:8080 instead of just 8080.

You will instantly hit the famous WordPress installation screen!

Step 5: Manage Your Environment

Here are the crucial commands to memorize when operating in the directory containing your docker-compose.yml file:

See what's actively running in this project:

docker compose ps

Check the deeply detailed background system logs (useful if an app crashes to see why it died):

docker compose logs
# Add -f to follow the logs live in real-time
docker compose logs -f

Stop the containers temporarily without deleting them:

docker compose stop

(You can start them again using docker compose start)

Tear the entire project down (stops the containers, deletes them, and removes the internal network):

docker compose down

(By default, this does NOT delete your database volume, so your WordPress posts are completely safe upon re-deployment).

To deploy high-availability application stacks using containerized architecture, there is nothing like a high-performance backend infrastructure backing it. Spin up a Premium VPS, install Docker, copy in your YAML configs, and launch your complex, multi-layered infrastructures into production effortlessly.

How to Secure SSH on Ubuntu & Debian: The Complete Server Guide

2026-03-25T00:00:00Z

Port 22 is scanned constantly. The moment you spin up a VPS with a public IP, automated bots start hammering it for weak passwords and default credentials. Hardening SSH takes about 15 minutes and makes your server dramatically less interesting to anyone trying to get in.

Prerequisite: This guide disables root login. You must have a non-root user with sudo privileges ready before running any of these steps. If you haven't done that yet, follow our How to Create a Sudo User on Ubuntu & Debian guide first, then come back here.

Set up SSH key authentication

The single most effective change you can make. Password logins can be brute-forced. Key-based auth cannot, not in any realistic timeframe.

On your local machine, generate a key pair:

ssh-keygen -t ed25519 -C "your-server-label"

Use ed25519, it's faster and more secure than the older RSA algorithm. When prompted for a passphrase, set one. It encrypts the private key on disk, so even if someone compromises your laptop, they still can't use the key without it.

Copy the public key to the server. Replace youruser with your actual sudo username:

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@your-server-ip

Test the key works before moving on. Open a new terminal window and connect. If you get in without a password prompt, the key is installed correctly. Do not close your existing session yet, you still need to disable password auth as a separate step.

Optional: add an entry to ~/.ssh/config on your local machine for quick access:

Host myserver
    HostName your-server-ip
    User youruser
    IdentityFile ~/.ssh/id_ed25519

After this, ssh myserver is all you need to type.

SSH in as your sudo user from this point forward. Direct root login is a security risk, if your session is compromised, an attacker has full unrestricted access with zero additional steps.

Open the SSH daemon config:

sudo nano /etc/ssh/sshd_config

Find and update this line:

PermitRootLogin no

If you ever need root access on the server, SSH in as your sudo user and run sudo su from there.

Disable password authentication

Your key is working, so now eliminate password logins entirely:

sudo nano /etc/ssh/sshd_config

Set both of these:

PasswordAuthentication no
PubkeyAuthentication yes

Important: Some Ubuntu and Debian versions set PasswordAuthentication in a drop-in file under /etc/ssh/sshd_config.d/ that overrides the main config. Check for it:
grep -r "PasswordAuthentication" /etc/ssh/
If you see it set to yes anywhere in the output, edit that specific file, not the main sshd_config.

Tighten a few more settings

While you have sshd_config open, add these to reduce the attack surface further:

# Disconnect after 3 failed attempts
MaxAuthTries 3

# Close unauthenticated connections faster
LoginGraceTime 30

# Disable unused features
X11Forwarding no
AllowTcpForwarding no

If only specific usernames should be able to log in remotely, add an allowlist:

AllowUsers youruser

Any account not on the list will be refused at the SSH level, even with a valid key.

Change the default port

Port 22 appears in every scanner's default target list. Moving SSH to a non-standard port won't stop a determined attacker from port-scanning, but it eliminates virtually all the automated noise. Auth logs go from hundreds of failed login attempts per day to effectively zero.

In sshd_config, update the port:

Port 2222

Choose any unused port above 1024. Before restarting SSH, update your firewall to allow the new port and close the old one:

sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
sudo ufw status

Make sure 2222 shows as ALLOW in the output before proceeding.

Restart SSH and verify

Apply all your changes:

sudo systemctl restart ssh

Then, in a new terminal window (keep your current session open), test the connection on the new port:

ssh -p 2222 youruser@your-server-ip

If it connects cleanly, you're done. If it fails, return to your existing session and debug. Run sudo sshd -t to check sshd_config for syntax errors before restarting again.

Common issues:

Firewall not updated for the new port
PasswordAuthentication no set in a drop-in file that was missed

Check what the server is actually seeing

After locking things down, inspect live authentication attempts:

sudo journalctl -u ssh --since "1 hour ago" | grep "Failed"

On a properly hardened server you should see nothing, or just a handful of attempts on the old port being silently dropped by the firewall.

A note on fail2ban

With SSH key auth enabled and password auth disabled, brute-force attacks against SSH are already impossible. fail2ban becomes less critical for SSH itself. That said, it's still useful for protecting other services like Nginx and Apache, and running it alongside these settings adds a reasonable layer of defense in depth. See our fail2ban setup guide if you want to add it.

If you want a safe place to practice this hardening process without risking a production server, our Budget VPS plans are an affordable sandbox to lock down, break, and start fresh as many times as you need.

How to Secure SSH on AlmaLinux, CentOS, Rocky Linux & Fedora: The Complete Server Guide

2026-03-25T00:00:00Z

The moment a server with a public IP goes live, automated scanners start probing port 22. It's not personal, it's just what happens on the internet. Most of them are looking for root logins with weak passwords or default credentials from cloud images that haven't been touched.

Locking down SSH on AlmaLinux, CentOS Stream, Rocky Linux, and Fedora takes the same 15 minutes as on any Linux server, with one extra step that RHEL-based systems require: telling SELinux about any port changes you make. Skip that and you'll be wondering why SSH stopped working.

Prerequisite: This guide disables root login. You must have a non-root user with sudo privileges ready before running any of these steps. If you haven't done that yet, follow our How to Create a Sudo User on AlmaLinux, CentOS, Rocky Linux & Fedora guide first, then come back here.

Set up SSH key authentication

Do keys before anything else. Password authentication is the main vector for SSH brute-force attacks, and switching to keys eliminates it entirely.

On your local machine, generate an ed25519 key pair:

ssh-keygen -t ed25519 -C "your-server-label"

Set a passphrase when prompted. It encrypts the private key on disk, if someone gets your local machine, they still can't use the key without the passphrase.

Copy the public key to the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

Open a new terminal window and verify you can connect with the key before changing anything else. If you're in without a password prompt, the key works. Keep your original session open, you'll need it as a fallback if something goes wrong in later steps.

Direct root login is an unnecessary risk. If your key gets compromised, an attacker immediately has unrestricted access. Use a non-root account with sudo instead.

Edit the SSH config:

sudo nano /etc/ssh/sshd_config

Find and set:

PermitRootLogin no

If this isn't set, on RHEL-based systems the default may vary by cloud image. Always set it explicitly.

Disable password authentication

With your key confirmed working, disable passwords:

sudo nano /etc/ssh/sshd_config

Set:

PasswordAuthentication no
PubkeyAuthentication yes

On these distros, the main config file is usually authoritative. But double-check for overrides:

grep -r "PasswordAuthentication" /etc/ssh/

If anything in /etc/ssh/sshd_config.d/ is setting it to yes, fix that file.

Tighten a few more settings

Small changes that reduce exposure:

# Disconnect after 3 failed auth attempts
MaxAuthTries 3

# Reduce the window for incomplete connections
LoginGraceTime 30

# Disable features you're not using
X11Forwarding no
AllowTcpForwarding no

If only specific users should have SSH access:

AllowUsers youruser

Any system user not listed won't be able to authenticate remotely, even with valid credentials. Useful for keeping application accounts locked down.

Change the default port

This is where RHEL-based systems differ from Debian-based ones. SELinux controls which ports services are allowed to listen on. If you change the SSH port without updating SELinux, the service will fail to restart.

First, check which ports SSH is currently allowed to use:

sudo semanage port -l | grep ssh

Add your new port to the allowed list:

sudo semanage port -a -t ssh_port_t -p tcp 2222

If semanage isn't available:

sudo dnf install policycoreutils-python-utils -y

Then edit sshd_config:

Port 2222

Now update firewalld to allow the new port and remove the old one:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Verify:

sudo firewall-cmd --list-all

You should see 2222/tcp in the ports list and ssh removed from services.

Restart sshd and verify

On RHEL-family systems the service is sshd, not ssh:

sudo systemctl restart sshd

In a new terminal window, connect on the new port:

ssh -p 2222 user@your-server-ip

If it works, you're done. If not, use your existing session to debug. Check for config syntax errors first:

sudo sshd -t

That command validates the config without actually restarting, it will tell you if there's a typo or invalid setting.

Verify the SELinux port assignment

After restarting, confirm SELinux accepted the port:

sudo semanage port -l | grep ssh

You should see your new port listed. If the restart succeeded, this should already be fine.

Check the auth logs

See what's hitting your server:

sudo journalctl -u sshd --since "1 hour ago" | grep -E "Failed|Invalid"

On a properly hardened server with password auth disabled and running on a non-standard port, this log should be essentially empty.

SELinux audit denials

If sshd fails to start or connect after the port change, check for SELinux denials:

sudo ausearch -m avc -ts recent | grep sshd

That'll tell you exactly what SELinux blocked, which makes fixing it much simpler than guessing.

If you want a clean RHEL-based VPS to practice this on without risk, our Budget VPS plans are cheap enough to spin up a test box, harden it, and start fresh if anything breaks.

Knowledge Base | VoxiHost

Now Live: Hourly VPS Hosting - The Ultimate Flexibility for Your Projects

Why Choose Hourly VPS?

1. Pay Only for What You Use

2. Full Flexibility of Choice

How is the Price Calculated?

3. Intelligent Server Management

Major Promotion

Conclusion

March 2026: VoxiHost DevBlog

1. Direct Server Access with VNC Console

2. 7 New OS Distributions Live (Alma, Rocky, Fedora, CentOS)

3. Seamless Login with Google Auth

4. Verified Reviews via Trustpilot

5. Improving the Platform Experience

What's Next?

How to Update Fedora 43 & Newer: The Complete Server Guide

The basics: dnf5 upgrade

Cleaning up (dnf5 autoremove)

Do you need a reboot? (needs-restarting)

Automating patches with dnf-automatic

The quick one-liner

Upgrading to the next Fedora release

The SELinux and config file traps

How to Update AlmaLinux, CentOS Stream & Rocky Linux: The Complete Server Guide

The basics: dnf update and dnf upgrade

Cleaning up (dnf autoremove)

Do you need a reboot? (needs-restarting)

Automating patches with dnf-automatic

The quick update one-liner

Upgrading to a new major release

What to watch out for

How to Transfer Files to Your VPS using SFTP & FileZilla

Step 1: Download FileZilla

Step 2: Configure the Site Manager

Step 3: Select the SFTP Protocol

Step 4: Add Your Credentials or SSH Key

If you use a Password:

If you use SSH Keys (Recommended):

Step 5: Connect and Transfer

The FileZilla Interface

How to Set Up a WireGuard VPN Server on Ubuntu & Debian

Step 1: Download the Trusted Install Script

Step 2: Run the Auto-Installer

Step 3: The Configuration Prompts

Step 4: Generate Your First Client Key

Step 5: Connect Your Devices

Connecting a Mobile Phone (iOS/Android):

Connecting a Laptop or PC (Windows/Mac/Linux):

Generating More Clients

How to Set Up SSL with Let's Encrypt & Certbot on Ubuntu & Debian: The Complete Guide

Prerequisites

Step 1: Install Certbot

Step 2: Confirm Firewall Settings

Step 3: Obtain and Install the SSL Certificate

The Certbot Prompts

Step 4: Verify Auto-Renewal

How to Set Up Netdata for Real-Time VPS Monitoring

Step 1: Install Netdata Using the Kickstart Script

Step 2: Configure the Firewall

Step 3: Access Your Dashboard

Security Note

How to Set Up a LEMP Stack (Linux, Nginx, MariaDB, PHP) on Ubuntu & Debian

Step 1: Install Nginx (The Web Server)

Step 2: Install MariaDB (The Database)

Step 3: Install PHP (The Processing Language)

Step 4: Configure Nginx to use PHP

Step 5: Test PHP Processing on Nginx

How to Set Up a LAMP Stack (Linux, Apache, MySQL, PHP) on Ubuntu & Debian

Step 1: Install Apache (The Web Server)

Step 2: Install MySQL (The Database)

Step 3: Install PHP

Step 4: Configure Apache Index Priorities

Step 5: Test the LAMP Stack

How to Set Up fail2ban on Ubuntu & Debian: The Complete Server Guide

Installing fail2ban

Configuring fail2ban jails

Global defaults

SSH jail

Integrating with ufw