DEV Community: olivia Millie

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

Prometheus & Grafana Monitoring Stack on Bare Metal: Complete Setup

olivia Millie — Fri, 04 Sep 2026 09:42:59 +0000

A server can be "up" and still be quietly failing you. Disk filling up over weeks, memory creeping toward a swap death spiral, a backup job that's been silently erroring for days — none of that shows up in a basic uptime check. The only way to catch it is to actually watch the numbers over time.

This guide sets up a self-hosted observability stack on a Bare Metal Server running Ubuntu 24.04 LTS.

How the Pieces Fit Together


text
[Node Exporter :9100] ──scraped by──► [Prometheus :9090] ──queried by──► [Grafana :3000]

Node Exporter: Reads hardware statistics straight from the kernel.

Prometheus: Pulls (scrapes) metrics from exporters and stores them as time-series data.

Grafana: The visualization layer that queries Prometheus using PromQL.

Step 1: Create Dedicated System Users

sudo useradd --no-create-home --shell /bin/false prometheus
sudo useradd --no-create-home --shell /bin/false node_exporter
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo chown prometheus:prometheus /etc/prometheus /var/lib/prometheus

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/

How to Install Pterodactyl Panel on Ubuntu 24.04 LTS

olivia Millie — Thu, 03 Sep 2026 06:19:32 +0000

Pterodactyl is a free, open-source, Docker-based game server management panel. This guide walks you through a complete, production-ready installation on Ubuntu 24.04 LTS — covering PHP 8.3, MariaDB, Redis, Nginx, Let's Encrypt SSL, and the Wings daemon.

Requirements

Running Pterodactyl on shared hosting or a low-resource VPS will result in instability under load.

OS: Ubuntu 24.04 LTS
CPU: 4+ cores recommended
RAM: 8 GB+ recommended
Storage: 100 GB+ NVMe SSD recommended
PHP: PHP 8.3 (PHP 8.1 is not supported by Panel 1.11+)

Step 1 — Update the System

Run all commands as root.


bash
apt update && apt upgrade -y
apt install -y curl wget git unzip tar software-properties-common apt-transport-https ca-certificates gnupg lsb-release

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";

Scaling DeepSeek-V3 Across Multi-GPU Nodes: The Bare Metal Blueprint

olivia Millie — Tue, 01 Sep 2026 05:12:47 +0000

The release of DeepSeek-V3 has shifted the enterprise AI landscape. With its 671 billion parameters and highly efficient Mixture-of-Experts (MoE) architecture, it rivals the most expensive proprietary models. However, running a model of this magnitude locally requires immense VRAM and computational power.

Attempting to run DeepSeek-V3 on public cloud instances will quickly drain your budget due to inflated GPU hourly rates and hidden egress fees. The most cost-effective and performant solution is deploying on Bare Metal Servers.

In this blueprint, we will show you how to configure a multi-GPU environment, set up Tensor Parallelism, and deploy DeepSeek-V3 using vLLM on dedicated hardware.

Step 1 — The Hardware & Software Prerequisites

For DeepSeek-V3 (FP8 or BF16 precision), utilizing GPU Dedicated Servers with an 8x NVIDIA GPU configuration (80GB VRAM per card) is highly recommended.

OS: Ubuntu 24.04 LTS
Storage: PCIe Gen 4/5 NVMe SSDs
Software: Docker, NVIDIA Container Toolkit, CUDA 12.x

Step 2 — Optimizing Inter-GPU Communication (NCCL)

To prevent GPU Starvation, we must ensure NVIDIA NCCL is optimized. Verify your topology by running:

nvidia-smi topo -m

Look for "NV" or "PIX" in the matrix output. This confirms your GPUs can communicate directly.

Step 3 — Choosing the Inference Engine: Enter vLLM
To serve DeepSeek-V3 efficiently, we will use vLLM, which perfectly handles Tensor Parallelism (TP) to divide the heavy matrix math across all your GPUs.

Step 3.1: Deploying via Docker Compose
Create a docker-compose.yml file:

YAML
version: '3.8'
services:
  vllm-deepseek:
    image: vllm/vllm-openai:latest
    container_name: deepseek-v3-server
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ports:
      - "8000:8000"
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
    command: >
      --model deepseek-ai/DeepSeek-V3 
      --tensor-parallel-size 8
      --max-model-len 8192
      --trust-remote-code
      --enforce-eager
Step 3.2: Launching the Model
Start your inference server by executing:

Bash
docker-compose up -d
Step 5 — The Bare Metal Advantage
Running enterprise-scale AI models requires uncompromising infrastructure. Hosting your cluster in a London Data Centre ensures zero "Cloud Tax" (no egress fees), 100% unshared single-tenant resources, and maximum PCIe lane bandwidth.

Read the original tutorial here: https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/


---

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

markdown

Engineering AI: Scaling DeepSeek-V3 Across Multi-GPU Nodes

The release of DeepSeek-V3 has shifted the open-weights AI landscape. With its 671 billion parameters and highly efficient Mixture-of-Experts (MoE) architecture, running a model of this magnitude requires immense VRAM and computational power.

In this blueprint, we will explore how to configure a multi-GPU environment, optimize inter-GPU communication, and deploy DeepSeek-V3 using vLLM and Tensor Parallelism.

Step 1: Hardware & Software Prerequisites

For DeepSeek-V3 (FP8 or BF16 precision), an 8x NVIDIA GPU configuration (with high VRAM, such as 80GB per card) is recommended.

OS: Ubuntu 24.04 LTS
Storage: PCIe Gen 4/5 NVMe SSDs (Crucial for fast model loading)
Software: Docker, NVIDIA Container Toolkit, and CUDA 12.x

Step 2: Optimizing Inter-GPU Communication (NCCL)

When a model is split across multiple GPUs, the cards must communicate constantly. If this is slow, you encounter GPU Starvation. Ensure NVIDIA NCCL (NVIDIA Collective Communications Library) is optimized by verifying your topology:

nvidia-smi topo -m
Look for "NV" or "PIX" in the matrix output. This confirms your GPUs can communicate directly via NVLink or high-speed PCIe bridges, bypassing the CPU.

Step 3: The Inference Engine (vLLM)
To serve DeepSeek-V3, we will use vLLM. It handles Tensor Parallelism (TP), dividing the heavy matrix math across all GPUs simultaneously.

Deploying via Docker Compose
Create a docker-compose.yml file on your server:

YAML
version: '3.8'
services:
  vllm-deepseek:
    image: vllm/vllm-openai:latest
    container_name: deepseek-v3-server
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ports:
      - "8000:8000"
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
    command: >
      --model deepseek-ai/DeepSeek-V3 
      --tensor-parallel-size 8
      --max-model-len 8192
      --trust-remote-code
      --enforce-eager
Key Parameters Explained:
--tensor-parallel-size 8: Tells vLLM to split the DeepSeek-V3 model equally across 8 GPUs.

--max-model-len 8192: Defines the maximum context window based on available VRAM.

Launching the Model
Execute the following to pull the weights and start the API server:

Bash
docker-compose up -d
Step 4: Monitoring GPU Health in Production
High-throughput inference generates massive heat and power draw. It is strongly recommended to set up a Prometheus and Grafana stack alongside DCGM-Exporter to track VRAM usage, power consumption, and thermal limits across your multi-GPU array continuously.


---

### 13. bsky.app (Bluesky)
Want to run DeepSeek-V3 locally but avoid massive cloud egress fees? 🤖💸
Deploying on Multi-GPU Bare Metal is the smartest way to scale. Learn how to set up vLLM, Docker Compose, and Tensor Parallelism across 8 GPUs in our new blueprint: [https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/](https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/)

### 14. Reddit (For r/LocalLLaMA, r/MachineLearning, or r/SelfHosted)
**Title: Tutorial: Scaling DeepSeek-V3 on Multi-GPU Bare Metal (vLLM & Docker Compose)**
If you're trying to serve DeepSeek-V3 (671B parameters) on public clouds, the egress fees and hourly rates are probably destroying your budget. 
Moving to a dedicated Multi-GPU Bare Metal server is the most cost-effective way to run this in production. We put together a technical blueprint covering:
1. **NCCL Optimization:** Checking your PCIe/NVLink topology (`nvidia-smi topo -m`).
2. **Inference Engine:** Using `vLLM` for high-throughput serving.
3. **Deployment:** The exact `docker-compose.yml` needed to enforce Tensor Parallelism (`--tensor-parallel-size 8`) and manage VRAM.
If you are looking to escape the cloud tax and self-host massive MoE models, check out the full step-by-step code here: [https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/](https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/)

### 15. Mastodon
DeepSeek-V3 is powerful, but serving a 671B parameter model requires serious hardware. 🧠⚙️ 

Instead of paying massive cloud egress fees, deploy it on Multi-GPU Bare Metal. Our latest tutorial covers #vLLM configuration, Tensor Parallelism, and #DockerCompose setups for 8x GPU nodes. 

Read the blueprint: [https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/](https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/)
#AI #MachineLearning #DeepSeek #SelfHosted #DevOps #LLM

### 16. Instagram
*(Image Idea: A glowing multi-GPU server rack or a sleek terminal screen showing Docker loading DeepSeek-V3)*
Stop paying the "Cloud Tax" for your AI models! 🛑💸
DeepSeek-V3 is changing the game, but running a 671B parameter model on public clouds will drain your budget with hidden egress fees. 

The Solution? Multi-GPU Bare Metal Servers. ⚡️
Learn how to:
✅ Optimize GPU Communication (NCCL)
✅ Set up Tensor Parallelism across 8 GPUs
✅ Deploy the model easily using Docker Compose & vLLM

Take control of your AI infrastructure today. 
🔗 **Click the link in our bio for the full technical blueprint!** *(Bio link: [https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/](https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/))*
#DeepSeek #ArtificialIntelligence #MachineLearning #DevOps #NVIDIA #TechTutorial #eServers

### 17. Threads
Serving DeepSeek-V3 on AWS or Azure? The egress fees and hourly GPU rates will burn through your budget fast. 💸 Deploying on Multi-GPU bare metal gives you a flat rate and zero noisy neighbors. We just published a technical blueprint on how to configure vLLM and Tensor Parallelism using Docker Compose to run DeepSeek efficiently. Check out the code here: [https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/](https://www.eservers.uk/tutorials/howto/scaling-deepseek-v3-multi-gpu-nodes/)

### 18. WHTop (Press Release Format - Minimum 1500 chars)

html
FOR IMMEDIATE RELEASE

LONDON, UK – eServers, a leading provider of high-performance bare metal infrastructure and GPU-accelerated hosting, has released a comprehensive technical blueprint titled "Scaling DeepSeek-V3 Across Multi-GPU Nodes." The newly published guide provides AI agencies, researchers, and enterprise developers with a clear roadmap for deploying massive open-weights models without incurring exorbitant public cloud fees.

The release of DeepSeek-V3, featuring an astonishing 671 billion parameters and a highly efficient Mixture-of-Experts (MoE) architecture, has disrupted the AI industry. However, serving a model of this magnitude requires immense computational power and VRAM.

"Attempting to run DeepSeek-V3 on hyperscaler cloud instances quickly drains IT budgets due to inflated hourly GPU rates and hidden egress fees," the eServers advisory notes. "The most cost-effective and performant solution for scaling AI endpoints in 2026 is deploying on Multi-GPU Bare Metal Dedicated Servers, effectively eliminating the 'Cloud Tax'."

Technical Blueprint: vLLM and Tensor Parallelism

The comprehensive tutorial walks systems administrators through the exact steps required to provision an 8x NVIDIA GPU bare-metal environment. The guide emphasizes the importance of optimizing Inter-GPU communication via NVIDIA's Collective Communications Library (NCCL) to prevent GPU starvation during inference operations.

Furthermore, the blueprint provides the exact docker-compose.yml configurations necessary to deploy the vLLM inference engine. By utilizing Tensor Parallelism (via the --tensor-parallel-size 8 flag), the heavy matrix mathematics of DeepSeek-V3 are distributed evenly across all physical GPUs, maximizing throughput and reducing latency.

The Bare Metal Advantage for AI

eServers highlights that running enterprise-scale AI models requires uncompromising, single-tenant infrastructure. By utilizing UK-based GPU dedicated hardware equipped with 10Gbps unmetered bandwidth, businesses can download massive model weights and process millions of API requests for a predictable, flat monthly rate. Additionally, eServers backs its infrastructure with an industry-leading 15-30 Minute Hardware Response time to ensure mission-critical AI APIs remain online.

To view the complete deployment code, Docker configurations, and multi-GPU scaling strategies, IT leaders and developers are encouraged to read the full tutorial on the official eServers website.