DEV Community: eServers

Setting Up Wazuh SIEM for Server Log Monitoring on Linux

olivia Millie — Fri, 11 Sep 2026 10:44:22 +0000

A firewall stops unwanted traffic from getting in. It tells you nothing about what happens after something gets past it — a compromised WordPress plugin, a leaked SSH key, a cron job that shouldn't be there. That's the gap a SIEM fills.

Wazuh is the most widely deployed open-source option for self-hosted server monitoring and intrusion detection. Hosting it on a Bare Metal Server gives the OpenSearch indexer the RAM it needs to process logs rapidly.

Step 1: Install the Central Components

Wazuh provides an all-in-one installation script that deploys the manager, indexer, and dashboard together:


bash
curl -sO [https://packages.wazuh.com/4.x/wazuh-install.sh](https://packages.wazuh.com/4.x/wazuh-install.sh)
sudo bash ./wazuh-install.sh -a


Save the auto-generated admin credentials!

Step 2 & 3: Firewall Configuration
Open the required ports: 443 (Dashboard), 55000 (API), and 1514/1515 (Agent communication).

Step 4: Install and Enroll an Agent
On each server you want monitored:

curl -sO [https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.x_amd64.deb](https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.x_amd64.deb)
sudo WAZUH_MANAGER='your-manager-ip' dpkg -i ./wazuh-agent_4.x_amd64.deb
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

Step 5: Enable File Integrity Monitoring (FIM)
Edit /var/ossec/etc/ossec.conf on the agent to watch specific directories for webshells or unwanted changes:

XML
<syscheck>
  <directories check_all="yes" report_changes="yes">/etc,/bin,/sbin</directories>
  <directories check_all="yes">/var/www/html</directories>
</syscheck>
Restart the agent: sudo systemctl restart wazuh-agent.

To see how to deliberately trigger SSH brute-force alerts to test the system and how to reduce dashboard noise, read the full tutorial here: https://www.eservers.uk/tutorials/howto/setup-wazuh-siem-ubuntu-debian/

Self-Hosted Kubernetes (K3s) on Bare Metal: Skip Proxmox Overhead

olivia Millie — Fri, 11 Sep 2026 10:07:03 +0000

Proxmox and VMware virtualize hardware into separate machines. Kubernetes orchestrates containers within machines. If what you actually need is to run and scale containerized workloads, installing a hypervisor first and Kubernetes on top of it is often unnecessary overhead.

K3s, a lightweight Kubernetes distribution, lets you skip the virtualization layer entirely and run directly on Bare Metal Servers.

Step 1: Install K3s on the Control Plane

K3s ships a single install script that handles the setup, including a bundled containerd runtime and Traefik ingress.


bash
curl -sfL [https://get.k3s.io](https://get.k3s.io) | sh -
sudo systemctl status k3s
sudo k3s kubectl get nodes

cPanel vs Plesk vs Webmin: Which Dedicated Server Panel is Best in 2026?

olivia Millie — Fri, 11 Sep 2026 08:18:11 +0000

Choosing the right control panel is one of the first real decisions you make after ordering a dedicated server. It decides how fast you can deploy websites, how easy email and DNS management will be, and how much time your team spends on routine admin.

cPanel/WHM: The Industry Standard

cPanel remains the best fit for agencies and hosting resellers who need a mature, widely-documented Linux panel. WebHost Manager (WHM) sits above individual cPanel accounts, letting you package hosting plans and allocate resources per account.

Trade-off: It is Linux-only, and it is resource-hungry compared to lighter panels.

Plesk: The Cross-Platform Alternative

Plesk is the stronger choice if you run mixed Linux/Windows environments or lean heavily on WordPress management. It was built to solve the problem cPanel can't: managing Windows and Linux servers from the same interface.

Strength: It features a built-in WordPress Toolkit for bulk updates, staging, security hardening, and cloning.

Webmin: The Free, Technical Route

Webmin (often paired with Virtualmin) is the right call for technical teams who want a free, highly configurable panel and don't mind a steeper learning curve.

Strength: It has zero licensing cost and a lightweight footprint, which frees up more RAM and CPU headroom for actual workloads.

Hosting on eServers UK

If you're deploying on Bare Metal Servers, control panel choice matters when paired with local latency. UK data centre placement keeps latency low for UK/EU traffic, which makes panel responsiveness faster.

Read the full side-by-side comparison here: https://www.eservers.uk/blogs/cpanel-vs-plesk-vs-webmin-dedicated-servers/

Self-Hosted MinIO Object Storage on Bare Metal: An AWS S3 Alternative

olivia Millie — Wed, 09 Sep 2026 11:50:19 +0000

Most teams reach for AWS S3 by default because it's the API everyone knows. The problem isn't the API — it's the bill. Object storage on public cloud platforms charges for storage and for every byte that leaves the network.

MinIO solves this by giving you the exact same S3 API running on Bare Metal Servers. Point any S3-compatible application at your MinIO endpoint instead of s3.amazonaws.com, and nothing else needs to change.

Step 1: Prepare the Storage Disk

Identify the disk you'll dedicate to MinIO and format it using XFS (recommended for large files):


bash
lsblk
sudo mkfs.xfs /dev/sdb
sudo mkdir -p /mnt/minio-data
sudo mount /dev/sdb /mnt/minio-data
echo "/dev/sdb /mnt/minio-data xfs defaults 0 2" | sudo tee -a /etc/fstab

WireGuard VPN Setup on a Dedicated Server: Secure Remote Access

olivia Millie — Wed, 09 Sep 2026 11:25:29 +0000

Exposing SSH, database ports, or admin panels directly to the public internet is one of the most common ways dedicated servers get compromised. A VPN closes that exposure: instead of opening ports to the world, you open them only to devices connected through an encrypted tunnel.

WireGuard operates at the kernel level on Linux, meaning connection setup and throughput are noticeably faster than userspace VPNs like OpenVPN. Setting this up on a Bare Metal Server gives WireGuard a dedicated network stack with no noisy-neighbour contention.

Step 1: Install WireGuard

Ubuntu 24.04 ships WireGuard in the default repositories:


bash
sudo apt update
sudo apt install wireguard -y

How to Set Up Postfix with DKIM, SPF, and DMARC on Ubuntu 24.04

olivia Millie — Fri, 04 Sep 2026 06:46:31 +0000

If you've ever sent an email from your own server and watched it land in someone's spam folder, the cause is almost always the same: nothing on the receiving end can verify the mail actually came from you.

On a Bare Metal Server, the reputation of your outbound IP is entirely yours. A new IP sending unauthenticated mail looks exactly like spam. SPF, DKIM, and DMARC are how you build trust deliberately.

Prerequisites

Ubuntu 24.04 LTS with Postfix installed.
A clean reverse DNS (PTR) record pointing your server's IP back to your mail hostname.

Step 1: Set Up SPF

SPF is a DNS TXT record that authorizes your MX servers. Add a TXT record at your domain's root:

yourdomain.com.   IN TXT   "v=spf1 mx ~all"


Step 2 & 3: Install OpenDKIM and Generate Keys
Postfix has no DKIM signing built in; it requires a milter.

Bash
sudo apt update
sudo apt install -y opendkim opendkim-tools
sudo mkdir -p /etc/opendkim/keys/yourdomain.com
sudo opendkim-genkey -b 2048 -d yourdomain.com -D /etc/opendkim/keys/yourdomain.com -s mail -v
sudo chown -R opendkim:opendkim /etc/opendkim/keys
Step 4: Configure OpenDKIM
Edit /etc/opendkim.conf to set the domain, selector (mail), and keyfile. You must also create the socket directory so Postfix's chroot can reach it:

Bash
sudo mkdir -p /var/spool/postfix/opendkim
sudo chown opendkim:postfix /var/spool/postfix/opendkim
sudo chmod 750 /var/spool/postfix/opendkim
sudo usermod -a -G opendkim postfix
Step 5: Connect OpenDKIM to Postfix
Append to /etc/postfix/main.cf:

Ini, TOML
milter_protocol = 6
milter_default_action = accept
smtpd_milters = local:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters
Restart services:

Bash
sudo systemctl restart opendkim
sudo systemctl restart postfix
Step 7: Publish a DMARC Record
Start with a monitoring policy (p=none):

Plaintext
_dmarc.yourdomain.com.   IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100"
For the complete DNS setup and testing commands, read the full tutorial here: https://www.eservers.uk/tutorials/howto/setup-postfix-dkim-spf-dmarc-ubuntu-24-04/


---

### 12. Hashnode (Technical Focus - Commercial Content Removed)

markdown

Infrastructure Engineering: Authenticating Postfix with SPF, DKIM, and DMARC

When provisioning a new mail server, mailbox providers like Gmail and Outlook do not inherently trust your outbound IP address. Without cryptographic verification, your outbound mail will be flagged as suspicious and routed directly to the spam folder.

To establish sender reputation and guarantee deliverability, you must implement three distinct DNS and cryptographic checks: SPF, DKIM, and DMARC. This guide details their implementation on a Postfix server running Ubuntu 24.04 LTS.

The Authentication Trinity

SPF (Sender Policy Framework): A DNS record specifying which IP addresses are authorized to send mail on behalf of your domain.
DKIM (DomainKeys Identified Mail): Cryptographically signs each outgoing message utilizing a private key.
DMARC: The policy layer instructing receiving servers how to handle messages that fail SPF or DKIM checks.

Prerequisite: You must have a valid Reverse DNS (PTR) record configured for your server's IP address pointing to your mail hostname. DKIM and SPF cannot compensate for a missing PTR record.

Step 1: SPF Implementation

Add a TXT record to your domain's root zone:


text
yourdomain.com.   IN TXT   "v=spf1 mx ~all"
Note: Use ~all (softfail) during initial testing to monitor failures without dropping legitimate mail. Transition to -all (hardfail) once verified.

Step 2: OpenDKIM Installation and Key Generation
Postfix requires a milter to handle DKIM signing. Install OpenDKIM:

Bash
sudo apt update
sudo apt install -y opendkim opendkim-tools
Generate a 2048-bit key (1024-bit is deprecated):

Bash
sudo mkdir -p /etc/opendkim/keys/yourdomain.com
sudo opendkim-genkey -b 2048 -d yourdomain.com -D /etc/opendkim/keys/yourdomain.com -s mail -v
sudo chown -R opendkim:opendkim /etc/opendkim/keys
Step 3: Milter Configuration
Edit /etc/opendkim.conf to declare your domain and keys:

Ini, TOML
Syslog              yes
Mode                sv
Canonicalization    relaxed/simple
Domain              yourdomain.com
Selector            mail
KeyFile             /etc/opendkim/keys/[yourdomain.com/mail.private](https://yourdomain.com/mail.private)
Socket              local:/var/spool/postfix/opendkim/opendkim.sock
Because Postfix runs in a chroot environment, the socket must be accessible:

Bash
sudo mkdir -p /var/spool/postfix/opendkim
sudo chown opendkim:postfix /var/spool/postfix/opendkim
sudo chmod 750 /var/spool/postfix/opendkim
sudo usermod -a -G opendkim postfix
Step 4: Postfix Integration
Append the milter configuration to /etc/postfix/main.cf:

Ini, TOML
milter_protocol = 6
milter_default_action = accept
smtpd_milters = local:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters
Restart the services:

Bash
sudo systemctl restart opendkim
sudo systemctl restart postfix
Step 5: Publishing DNS Records
Print your public key (cat /etc/opendkim/keys/yourdomain.com/mail.txt) and add it as a TXT record at mail._domainkey.yourdomain.com.

Finally, publish your DMARC monitoring policy:

Plaintext
_dmarc.yourdomain.com.   IN TXT   "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; pct=100"
After analyzing the aggregate reports sent to your email, tighten the policy from p=none to p=quarantine, and eventually p=reject.

Setting Up a PostgreSQL Cluster with Patroni on Bare Metal

olivia Millie — Fri, 04 Sep 2026 05:21:51 +0000

For enterprise applications, SaaS platforms, and large e-commerce sites, a database outage means catastrophic revenue loss. Relying on a single database server is a single point of failure.

To ensure true 100% uptime, you need a PostgreSQL High Availability (HA) Cluster. In this architecture, multiple database servers run in sync. If the primary master server crashes, the system automatically detects the failure and promotes a standby server to take over in seconds, with zero manual intervention.

This tutorial covers setting up a robust PostgreSQL HA cluster on Ubuntu 24.04 bare-metal servers using Patroni (for failover management), etcd (for distributed consensus), and HAProxy (for routing client traffic).

Step 1: Architecture & Prerequisites

To prevent a "split-brain" scenario where two servers both think they are the primary, a highly available cluster requires an odd number of nodes to maintain a quorum. Therefore, this setup requires three bare-metal servers.

Node 1 (db1): 10.0.0.11
Node 2 (db2): 10.0.0.12
Node 3 (db3): 10.0.0.13

Step 3: Install PostgreSQL & Dependencies

On all three nodes, install PostgreSQL, Python3, and etcd:


bash
apt install -y postgresql postgresql-contrib python3-pip python3-venv etcd curl

Bulletproof Disaster Recovery: Automating Encrypted Backups Using BorgBackup on Linux

olivia Millie — Thu, 03 Sep 2026 07:02:42 +0000

A common misconception in server management is that RAID constitutes a backup. It does not. RAID protects against hardware drive failure, but it will seamlessly and instantly replicate accidental file deletions, corrupted database tables, or ransomware encryption across all your mirrored drives.

For true disaster recovery on your Bare Metal Servers, you need an isolated, versioned, and encrypted backup strategy.

Enter BorgBackup (Borg). Borg is an open-source, deduplicating backup program that offers authenticated encryption. It only stores the changes made since your last backup, saving massive amounts of disk space.

Step 1: Install BorgBackup

This guide uses Ubuntu 24.04 LTS. Run as root:


bash
apt update
apt install -y borgbackup
borg --version
Step 2: Initialize the Encrypted Repository
A "repository" is where Borg stores your archives. We will create a local repository at /backup/borg-repo.

Bash
mkdir -p /backup/borg-repo
borg init --encryption=repokey /backup/borg-repo
You will be prompted to enter a passphrase. Do not lose this passphrase.

Step 3: Running Your First Backup
Let's back up /var/www/html and /etc:

Bash
borg create --stats --progress \
    /backup/borg-repo::"Backup-{now:%Y-%m-%d_%H:%M}" \
    /var/www/html /etc
Step 4: Automating Backups with a Bash Script & Cron
Create a bash script: nano /usr/local/bin/borg-backup.sh

Bash
#!/bin/bash
export BORG_PASSPHRASE="YOUR_SUPER_SECRET_PASSPHRASE"
REPOSITORY="/backup/borg-repo"
LOG="/var/log/borg-backup.log"

echo "Starting backup: $(date)" >> $LOG

borg create --stats \
    $REPOSITORY::"Auto-Backup-{now:%Y-%m-%d_%H:%M}" \
    /var/www/html /etc >> $LOG 2>&1

borg prune --list --keep-daily=7 --keep-weekly=4 $REPOSITORY >>$LOG 2>&1

echo "Backup finished: $(date)" >> $LOG
Make it executable and add to crontab to run at 2:00 AM:

Bash
chmod +x /usr/local/bin/borg-backup.sh
crontab -e
# Add: 0 2 * * * /usr/local/bin/borg-backup.sh
Step 5: How to Restore Your Data
List available archives:

Bash
borg list /backup/borg-repo
Extract the files into a recovery folder:

Bash
mkdir /tmp/recovery && cd /tmp/recovery
borg extract /backup/borg-repo::"Auto-Backup-2026-06-01_02:00"
Conclusion
To fulfill the 3-2-1 backup strategy, you must move these backups off-site. Pushing your encrypted Borg repositories to a secure London Data Centre ensures true disaster recovery.

Read the original tutorial here: https://www.eservers.uk/tutorials/howto/automate-encrypted-backups-borgbackup-linux/

Building an eBPF Layer 7 DDoS Firewall with XDP

olivia Millie — Thu, 03 Sep 2026 04:52:58 +0000

What is Layer 7 DDoS and Why Is It Harder to Stop?

A Layer 7 DDoS attack (also called an application-layer DDoS or HTTP flood) overwhelms a web server by sending enormous volumes of seemingly legitimate HTTP requests rather than raw network packets.

Unlike Layer 3/4 floods, Layer 7 attacks complete a full TCP three-way handshake — making them indistinguishable from real users at the network level. They bypass standard iptables rate-limiting rules without exhausting CPU resources first. Modern botnets frequently use this technique because traditional firewalls cannot inspect HTTP headers without terminating the TCP connection — an operation that is far too expensive at high traffic volumes.

Why XDP + eBPF Is the Right Tool

eBPF (Extended Berkeley Packet Filter) allows you to run sandboxed programs inside the Linux kernel without modifying kernel source code. Paired with XDP (eXpress Data Path), these programs execute directly inside the NIC driver — the earliest possible point in the networking stack.

XDP is the fastest software-based mitigation available on Linux. On a 10Gbps unmetered Bare Metal Servers, an XDP program can process and drop packets faster than the OS can schedule a user-space process to even acknowledge them.

The Challenge: Parsing All Four Network Layers in eBPF

XDP operates at the lowest level of the Linux networking stack. To reach Layer 7 (HTTP data), your eBPF program must manually walk the entire packet structure: Ethernet (14 bytes), IPv4 (20 bytes), and TCP (20 bytes). The Linux kernel eBPF verifier performs strict bounds checking on every memory access.

Step 1: Write the eBPF C Program

This guide is tested on Ubuntu 24.04 LTS. Create a file named l7_firewall.c. When it detects a malicious HTTP signature, it returns XDP_DROP, discarding the packet instantly at the NIC level.


c
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/in.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int xdp_l7_filter(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data     = (void *)(long)ctx->data;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end) return XDP_PASS;
    if (eth->h_proto != __constant_htons(ETH_P_IP)) return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end) return XDP_PASS;
    if (ip->protocol != IPPROTO_TCP) return XDP_PASS;

    struct tcphdr *tcp = (void *)ip + (ip->ihl * 4);
    if ((void *)(tcp + 1) > data_end) return XDP_PASS;

    unsigned char *payload = (unsigned char *)tcp + (tcp->doff * 4);
    if ((void *)(payload + 14) > data_end) return XDP_PASS;

    if (payload[0] == 'G' && payload[1] == 'E' && payload[2] == 'T' &&
        payload[3] == ' ' && payload[4] == '/' && payload[5] == 'a' &&
        payload[6] == 't' && payload[7] == 't' && payload[8] == 'a' &&
        payload[9] == 'c' && payload[10] == 'k') {
        return XDP_DROP;
    }
    return XDP_PASS;
}
char _license[] SEC("license") = "GPL";

How to Set Up RAID on a Bare Metal Server: Hardware vs. Software RAID (2026 Guide)

olivia Millie — Fri, 21 Aug 2026 07:14:19 +0000

In the enterprise landscape, data integrity and uptime are non-negotiable. When deploying Bare Metal Servers, configuring RAID (Redundant Array of Independent Disks) is the most critical step in protecting your data against hardware failure while optimizing disk performance.

1. Hardware RAID vs. Software RAID: The Technical Verdict

The choice between Hardware and Software RAID depends on your specific workload, budget, and acceptable CPU overhead:

Hardware RAID: Superior performance utilizing a dedicated onboard processor and cache. High reliability managed independently by the RAID controller.
Software RAID: Highly cost-effective and portable. Managed directly by the OS kernel (such as Linux mdadm).

2. Selecting the Best RAID Level

RAID 0 (Striping): Maximum performance. No redundancy; if one drive fails, all data is lost.
RAID 1 (Mirroring): Ideal for OS drives. Data is cloned onto two disks.
RAID 5 (Parity): Requires at least 3 disks. Balances capacity and redundancy.
RAID 10 (1+0): The gold standard for databases running on NVMe Dedicated Servers. Combines RAID 0 speed with RAID 1 safety (minimum 4 disks).

3. Step-by-Step: Setting Up Hardware RAID (BIOS/UEFI)

Enter the RAID BIOS: Restart the server and press Ctrl+R, F2, or Del during boot.
Create a Virtual Drive: Select the physical target drives.
Configure RAID Level: Choose RAID 1, 5, or 10.
Initialize & Save: Perform a Fast Initialization and exit.

4. Step-by-Step: Setting Up Software RAID on Linux (mdadm)

Step 1: Install mdadm


bash
sudo apt update && sudo apt install mdadm -y

The SSH Security Hardening Checklist for Dedicated Servers

olivia Millie — Fri, 14 Aug 2026 06:49:36 +0000

When you rent a dedicated server, you get full root access — which also means SSH is the front door to your entire infrastructure. Unlike shared hosting, there's no provider-managed layer sitting between an attacker and your operating system. If SSH is left on default settings, it becomes the single easiest way for automated bots to get in.

This checklist walks through the practical steps for hardening SSH on Bare Metal Servers, why each step matters, and where responsibility sits.

Why SSH Security Matters More on a Dedicated Server

On a dedicated server, you are the system administrator. Every internet-facing dedicated server with SSH open on port 22 will see automated login attempts within hours of going live. The good news: fixing default ports, password-only logins, and root access closes the majority of the attack surface.

The SSH Hardening Checklist

1. Disable direct root login
Root is the most targeted username. Create a separate administrative user with sudo privileges, then set PermitRootLogin no in sshd_config.

2. Switch to key-based authentication
SSH keys are far harder to brute-force than passwords. Generate an SSH key pair and install the public key on the server.

3. Disable password authentication entirely
Once key-based login is working, set PasswordAuthentication no. This alone eliminates brute-force password guessing.

4. Change the default SSH port
Moving off port 22 won't stop a targeted attacker, but it dramatically cuts down the noise from automated scanners.

5. Restrict SSH access by IP address
Use firewall rules or AllowUsers/Match Address directives to only permit SSH from known IP ranges.

6. Use fail2ban or equivalent
Fail2ban watches your logs and automatically bans IPs after repeated failed login attempts.

7. Set an idle session timeout
Configure ClientAliveInterval and ClientAliveCountMax so idle SSH sessions disconnect automatically.

8. Limit which users can use SSH
Use AllowUsers or AllowGroups in sshd_config to explicitly list who is permitted to connect.

9. Keep OpenSSH and the OS patched
Apply OS and OpenSSH security updates promptly.

10. Monitor and log SSH access
Review /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL-based) periodically.

11. Consider two-factor authentication (2FA)
For servers handling sensitive databases on NVMe Dedicated Servers, adding 2FA via Google Authenticator PAM modules provides a second layer.

Combining SSH Hardening with Network-Level Protection

SSH hardening works best alongside a dedicated hardware firewall. Hosting your infrastructure in a secure London Data Centre with edge-level DDoS mitigation reduces the volume of malicious traffic your SSH daemon ever has to deal with.

Read the original guide here: https://www.eservers.uk/blogs/ssh-security-hardening-checklist/

IPv4 vs IPv6: A Complete Guide for UK Dedicated Servers

olivia Millie — Fri, 14 Aug 2026 06:30:04 +0000

Every server on the internet needs an address, known as an IP address. Right now there are two versions in use: IPv4 and IPv6. If you're managing Bare Metal Servers, the version you use affects hosting cost, email delivery, SEO, and customer accessibility.

What Is IPv4?

IPv4 (Internet Protocol version 4) is the original addressing system, built in the early 1980s, using a 32-bit format. There are only about 4.3 billion possible addresses, which ran out years ago. This is why IPv4 addresses now have to be bought or leased, and this scarcity is reflected in hosting prices. Almost every dedicated server still ships with at least one IPv4 address because older software and corporate networks still depend on it.

What Is IPv6?

IPv6 uses a 128-bit format, meaning the number of possible addresses is enormous and exhaustion is not a concern. However, IPv6 adoption is still uneven, meaning some networks cannot reach IPv6-only servers.

Why the IP Version Matters

Email deliverability: A dedicated IPv4 address with a clean history is the standard for sending email reliably.
SEO and geo-targeting: Search engines use IPv4 ranges to determine where a server is physically based.
Network segmentation: IPv6's huge address space makes it easier to assign internal addresses to containers or microservices without running out.

Do You Need IPv4, IPv6, or Both?

For almost every UK business running a dedicated server, the answer is dual stack — both IPv4 and IPv6 running side by side.

Website or e-commerce store: Keep IPv4 for compatibility and SEO, and add IPv6.
Email server: IPv4 is essential to protect sender reputation.

The Network Matters

An IP address is only as good as the network carrying it. Hosting your server in a premium London Data Centre with direct peering at major UK internet exchanges ensures traffic routes efficiently, reducing latency. To support high throughput, deploying NVMe Dedicated Servers alongside an optimized dual stack network guarantees maximum performance.

Read the original post: https://www.eservers.uk/blogs/ipv4-vs-ipv6-dedicated-servers-uk/