Edge Computing with Customized Bare Metal Servers

Updated on Apr 16, 2026
Kimberly N
13 MINS READ
Table of Contents
deploy Edge Computing on bare metal servers

Edge computing means running applications or processing data close to where it’s generated, for example, on a local server, instead of sending everything to a faraway cloud data center. This reduces latency, saves bandwidth, and can improve security and reliability. This guide intends to teach you how to set up Edge computing on bare metal servers.

If you are looking for reliable dedicated servers to power your edge computing infrastructure, you can check PerLod Hosting, which provides high-performance bare metal servers with global data center locations, perfect for building low-latency edge networks.

Overview: Edge Computing on Bare Metal Servers

In this guide, we want to build a high-performance, low-latency edge computing network. This setup puts small, fast servers near your users and links them securely to a main data center, so users connect to the nearest edge server for quick responses while important data stays safe in the core, which makes the app faster, more reliable, and easier to scale.

We’re building an edge computing system using a few tools, including:

  • Ubuntu 24.04 Bare Metal Server: We’re running everything directly on real computers, not virtual machines, using Ubuntu Linux version 24.04.
  • WireGuard VPN: It securely connects your edge servers and the main server so they can talk safely over the internet.
  • K3s Lightweight Kubernetes: Helps run and manage small apps, which is a smaller and faster Kubernetes version for edge devices.
  • Traefik with Nginx: These are used to control web traffic. Traefik decides where requests go, and Nginx can store small copies of responses to make websites faster.
  • Redis Edge Cache: A fast temporary database that stores data close to the edge so apps can get it quickly.
  • PostgreSQL core DB: he main database at your central data center. You can make read replicas at the edge to speed up data reading.
  • Prometheus Node Exporter with Grafana Agent: These tools help you monitor your systems.

In this guide, we use EDGE_A and EDGE_B as the edge servers. For example, one in Germany and one in the Netherlands. And the CORE is the main data center server.

Planning and Prerequisites to Deploy Edge Computing on Dedicated Servers

A successful edge computing setup requires careful planning and execution. Here are the key planning decisions:

Latency Budget (Speed Targets): Reads must be very fast from the edge, but writes can take a bit longer to the core.

Data Strategy: If data is already stored at the edge, serve it locally for speed. When users save or update data, send it to the central system by choosing:

  • Synchronous: Wait until the core confirms the write, which is more consistent.
  • Asynchronous: Send it later, which is faster, but may show old data briefly.

DNS Routing: Use latency-based or geo DNS so users automatically connect to the nearest edge server. If you host DNS yourself, start simple:

  • Use region-based subdomains.
  • Add smart routing based on geography or speed later.

Hardware Recommendation:

  • NICs with offloads: Network cards that can handle some tasks by themselves, reducing CPU work.
  • NVMe drives: Super-fast storage for caching frequently used data.
  • RAM: At least 16–32 GB for smooth caching and processing.
  • BIOS settings: Set the system to Performance mode, and if you need ultra-low latency, disable deep C-states.

You must measure current latency from user-representative locations to your current origin server. To measure the required metrics, you can use the commands below:

Bash
# ICMP Latency: Measures round-trip time and packet loss to the origin.ping -c 20 origin.example.com # Path Quality: A powerful tool to diagnose latency, jitter, and packet loss on each hop of the route.sudo apt update && sudo apt install mtr -ymtr -rwzbc 200 origin.example.com # TCP Throughput: Tests the maximum network throughput and how it is affected by latency.sudo apt install iperf3 -yiperf3 -c origin.example.com -t 30 # HTTP Load Testing: Simulates multiple users to measure your web server's latency and performance under load.sudo snap install hey --classic || truehey -z 30s -c 50 https://origin.example.com/health

Save these metrics as your before numbers.

Prepare OS and Optimize Network on EDGE and CORE Servers

You must prepare your servers (Edge and Core) by running the system update, installing required tools, and optimizing the network. Run the system update and install the required tools with the commands below:

Bash
sudo apt update && sudo apt upgrade -ysudo apt install jq curl git unzip ethtool net-tools htop vim tmux ufw

Set the correct timezone on your servers:

Bash
sudo timedatectl set-timezone UTCsudo timedatectl set-ntp true

Also, set the CPU Governor, which forces the CPU to run at its maximum frequency at all times, with the commands below:

Bash
sudo apt install linux-tools-common linux-tools-generic -yfor c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance | sudo tee $c; done

Now you must configure the sysctl parameters to optimize TCP buffer sizes, enable modern congestion control (BBR), and reduce TCP timeout delays with the following command:

Bash
sudo tee /etc/sysctl.d/99-edge-tuning.conf >/dev/null <<'EOF'net.core.netdev_max_backlog = 250000net.core.rmem_max = 536870912net.core.wmem_max = 536870912net.ipv4.tcp_rmem = 4096 87380 536870912net.ipv4.tcp_wmem = 4096 65536 536870912net.ipv4.tcp_congestion_control = bbrnet.ipv4.tcp_mtu_probing = 1net.ipv4.tcp_fastopen = 3net.ipv4.tcp_slow_start_after_idle = 0net.ipv4.ip_local_port_range = 10000 65000net.core.somaxconn = 65535net.ipv4.tcp_fin_timeout = 15net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_syncookies = 1net.ipv4.conf.all.rp_filter = 1net.ipv4.conf.default.rp_filter = 1EOF

Apply the changes with the following command:

Bash
sudo sysctl --system

You can check and optionally disable generic receive offload, which can sometimes introduce latency in favor of throughput. Check current offloads with the command below:

Bash
sudo ethtool -k $(ip -o link show | awk -F': ' '$2!="lo"{print $2; exit}')

Enable or disable specific offloads if needed. For example, this will ensure GRO and LRO off:

Bash
sudo ethtool -K eno1 gro off lro off

Set up WireGuard for Secure and Fast Edge Overlay

We want to use WireGuard to create an encrypted, peer-to-peer overlay network. This mesh gives your services a private, routable IP space to communicate securely between the core and edges, as if they were on the same physical local network, regardless of their global location.

Install WireGuard on all Edge and Core servers with the command below:

Bash
sudo apt install wireguard qrencode -y

Generate the key pairs on all servers with the following commands:

Bash
wg genkey | tee ~/wg.key | wg pubkey | tee ~/wg.pubchmod 600 ~/wg.key

Assign overlay IPs in this guide include:

  • CORE: 10.88.0.1/24
  • EDGE_A: 10.88.0.11/24
  • EDGE_B: 10.88.0.12/24

Now you must configure the Core server, which defines the core node's IP and lists all edge servers that are allowed to connect with the following command:

Bash
sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'[Interface]Address = 10.88.0.1/24ListenPort = 51820PrivateKey = <CORE_PRIVATE_KEY> # Edge A[Peer]PublicKey = <EDGE_A_PUB>AllowedIPs = 10.88.0.11/32 # Edge B (optional)[Peer]PublicKey = <EDGE_B_PUB>AllowedIPs = 10.88.0.12/32EOF

Then, configure the Edge_A server, which defines the edge server's IP and points it to the core server's public IP as its endpoint:

Bash
sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'[Interface]Address = 10.88.0.11/24ListenPort = 51820PrivateKey = <EDGE_A_PRIVATE_KEY> [Peer]PublicKey = <CORE_PUB>AllowedIPs = 10.88.0.0/24Endpoint = <CORE_PUBLIC_IP>:51820PersistentKeepalive = 15EOF

You can do this for the Edge_B server similarly.

Start and enable WireGuard on all servers and check the status with the commands below:

Bash
sudo systemctl enable --now wg-quick@wg0wg show

Test the connectivity across the overlay network:

Bash
ping -c 4 10.88.0.1    # from EDGE Serversping -c 4 10.88.0.11   # from CORE to EDGE_A

Deploy k3s Clusters at the Autonomous Edge

In this step, we want to deploy K3s in an Autonomous Edge pattern, where each edge location runs its own independent single-node cluster. This provides maximum flexibility; if the core data center fails, the edges continue to operate using their local cached data and compute.

Install K3s on Edge servers with the following commands:

Bash
curl -sfL https://get.k3s.io | sudo sh -s - server \  --disable traefik \  --write-kubeconfig-mode 644 \  --tls-san $(curl -s ifconfig.me) \  --flannel-backend=wireguard-native

This will disable the built-in Traefik and use WireGuard for the internal Pod network.

Check that Edge servers are ready and list all system pods with the commands below:

Bash
sudo kubectl get nodes -o widesudo kubectl get pods -A

You can optionally install K3s on your Core server for server-side workloads:

Bash
curl -sfL https://get.k3s.io | sudo sh -s - server --disable traefik

Routing and Accelerating Traffic at the Edge

We want to deploy a two-layer system, including Traefik as the intelligent ingress router that understands Kubernetes and handles TLS termination, and a high-performance Nginx micro-cache placed directly in front of the application.

Install Traefik via Helm, which is a package manager for Kubernetes used to deploy complex applications:

Bash
sudo snap install helm --classic || curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash kubectl create ns ingresshelm repo add traefik https://traefik.github.io/chartshelm repo update helm upgrade --install traefik traefik/traefik -n ingress \  --set service.type=NodePort \  --set ports.web.nodePort=30080 \  --set ports.websecure.nodePort=30443 \  --set logs.general.level=INFO

Then, deploy Nginx Micro-Cache as a DaemonSet by creating the YAML file:

Bash
sudo nano edge-cache.yaml

Add the following configuration to the file:

YAML
apiVersion: apps/v1kind: DaemonSetmetadata:  name: edge-cache  namespace: ingressspec:  selector:    matchLabels:      app: edge-cache  template:    metadata:      labels:        app: edge-cache    spec:      hostNetwork: true      containers:      - name: nginx        image: nginx:1.25        ports:        - containerPort: 8081          hostPort: 8081        volumeMounts:        - name: cfg          mountPath: /etc/nginx/conf.d      volumes:      - name: cfg        configMap:          name: edge-cache-cm---apiVersion: v1kind: ConfigMapmetadata:  name: edge-cache-cm  namespace: ingressdata:  cache.conf: |    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=EDGE:100m max_size=2g inactive=10m use_temp_path=off;     server {      listen 8081;      resolver 1.1.1.1 1.0.0.1;      proxy_connect_timeout 2s;      proxy_read_timeout 5s;       location / {        proxy_cache EDGE;        proxy_cache_valid 200 1m;        proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504 updating;        proxy_ignore_headers Set-Cookie;        add_header X-Cache $upstream_cache_status;         # upstream = local k8s service (app), fallback to core if needed        set $upstream http://app.default.svc.cluster.local:8080;        proxy_pass $upstream;        proxy_set_header Host $host;        proxy_set_header X-Forwarded-For $remote_addr;      }    }

Apply the configuration with the command below:

Bash
kubectl apply -f edge-cache.yaml

This runs Nginx on each edge server at port 8081 as a micro-cache in front of your app service.

Next, configure Traefik IngressRoute to Nginx cache with:

Bash
sudo nano ingressroute.yaml

Add the following configuration to the file:

YAML
apiVersion: traefik.containo.us/v1alpha1kind: IngressRoutemetadata:  name: app-route  namespace: defaultspec:  entryPoints:  - web  - websecure  routes:  - match: Host(`edge.example.com`)    kind: Rule    services:    - name: edge-cache-svc      port: 8081---apiVersion: v1kind: Servicemetadata:  name: edge-cache-svc  namespace: defaultspec:  type: ClusterIP  ports:  - port: 8081    targetPort: 8081  selector:    app: edge-cache   # matches DaemonSet labels

Apply the configuration with the command below:

Bash
kubectl apply -f ingressroute.yaml

Create a Sample Application for Latency Testing

To verify the setup, we want to create a sample application that acts as a real service, allowing us to test the complete data path from user to cache to app and back.

Create a simple Python HTTP server deployment and a Kubernetes Service to expose it within the cluster with the command below:

Bash
sudo nano app.yaml

Add the following configuration to the file:

YAML
apiVersion: apps/v1kind: Deploymentmetadata:  name: app  namespace: defaultspec:  replicas: 2  selector:    matchLabels:      app: app  template:    metadata:      labels:        app: app    spec:      containers:      - name: app        image: python:3.12-slim        command: ["python", "-m", "http.server", "8080"]        ports:        - containerPort: 8080---apiVersion: v1kind: Servicemetadata:  name: app  namespace: defaultspec:  selector:    app: app  ports:  - port: 8080    targetPort: 8080

Apply the configuration and verify the application pods are running and the service is correctly targeting them:

Bash
kubectl apply -f app.yamlkubectl get svc,pods -n default -o wide

Deploy Redis Cache At the Edge

You can now deploy a Redis cache at the edge for fast read operations and define clear paths for write operations that must persist to the core database.

Use the commands below to launch a Redis deployment and service in the 'data' namespace for the application to use as a local, hot cache:

Bash
kubectl create ns datakubectl -n data create deployment redis --image=redis:7 --port=6379kubectl -n data expose deployment redis --type=ClusterIP --port=6379kubectl -n data get svc redis

Your app can read from Redis first; cache misses go to the core API. You can periodically warm the cache or fill on demand.

Writes: Send to CORE

  • For strong consistency, POST or PUT to api.core.example.com over WireGuard.
  • For eventual consistency, enqueue at the edge like Redis Stream or Kafka at the edge and replicate to the core asynchronously.

Note: Keep important systems and data in the main core server. Send mostly read-only data like feature flags, product lists, or user profiles to edge caches for faster access, with a TTL so they stay fresh.

Smart DNS Routing for Edge Computing Setup

The final step is to put the user on the right edge. You can start with a simple and effective strategy using regional subdomains like eu.example.com. This manually directs users in Europe to your German edge, and users in the US to your American edge.

This can later be upgraded to a managed DNS service with latency-based routing, which continuously measures and directs users to the absolute closest healthy endpoint.

Configure Firewall Rules for Edge Computing Setup

You must only allow what you need, including:

  • Public: 80/443 (Traefik).
  • WireGuard: 51820/udp between edges and core.
  • SSH: locked to your IPs.
  • NodePorts (30080/30443) only if you’re directly exposing NodePorts; otherwise, use a proper LB/NAT mapping.
Bash
sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow 22/tcpsudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw allow 51820/udp

Enable the firewall and check the status:

Bash
sudo ufw enablesudo ufw status

Monitor Metrics on Edge and Core Servers

We want to use the Prometheus Node Exporter to collect bare-metal server metrics and the Grafana Agent to securely ship those metrics to a central observability platform.

Install and configure the Node exporter on your dedicated server with the commands below:

Bash
cd /tmpcurl -LO https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gztar xzf node_exporter-*.tar.gzsudo mv node_exporter-*/node_exporter /usr/local/bin/sudo useradd -rs /bin/false nodeexp || true

Create a systemd unit file for it with the command below:

Bash
sudo tee /etc/systemd/system/node_exporter.service >/dev/null <<'EOF'[Unit]Description=Prometheus Node ExporterAfter=network.target [Service]User=nodeexpGroup=nodeexpType=simpleExecStart=/usr/local/bin/node_exporter [Install]WantedBy=multi-user.targetEOF

Apply the changes and enable the Node exporter service:

Bash
sudo systemctl daemon-reloadsudo systemctl enable --now node_exporter

Verify the Node Exporter is listening on its default port:

Bash
ss -tlnp | grep 9100

Follow the Grafana Agent setup Docs and connect it to your Prometheus remote_write endpoint. At the very least, make sure it collects metrics from Node Exporter and Traefik.

Benchmark Metrics After Edge Computing Setup

At this point, you must re-run the measurements and compare the "before" and "after" results to display he latency reduction, throughput improvement, and overall stability in your new edge computing architecture.

From a client near the EDGE_A server, run the commands below:

Bash
# Edge DNS in place (eu.example.com -> EDGE_A)ping -c 20 eu.example.commtr -rwzbc 200 eu.example.com # HTTP through Traefik->Nginx cache->apphey -z 30s -c 100 http://eu.example.com/

You must look for faster average and slowest response times compared to the main server, more requests served from the Nginx cache (X-Cache: HIT), and steady performance with few or no errors.

Conclusion

Implementing edge computing on dedicated servers is one of the most effective strategies for reducing network latency and improving service reliability. By bringing compute resources closer to end-users, organizations can achieve faster response times, lower bandwidth usage, and enhanced scalability.

Do not forget to check the PerLod's global dedicated server plans for setting up a powerful edge computing platform, which reduces network latency for users worldwide.

We hope you enjoy this guide on setting up Edge computing on bare metal servers. Subscribe to our X and Facebook channels to get the latest updates and articles on Edge computing.

For further reading:

Setting Up a Game Server on a VPS

How to Set Up a Video Streaming Server

Case study in Fintech Startup Dedicated Server

Dedicated servers offer consistent performance, hardware-level control, and predictable network behavior, which are essential for low-latency edge workloads.

Yes. Containers via Kubernetes or K3s are ideal for edge workloads due to their lightweight nature. However, if you need maximum performance and hardware-level optimizations, bare-metal deployment is better.

WireGuard creates a secure, high-speed VPN overlay connecting your edge nodes and core data center. It ensures encrypted traffic between all locations with minimal CPU overload.

Prev PostSecuring API Access Using API Gateways on VPS
Next PostBlockchain Node Hosting on VPS
Category:Buyer's Guides & Strategy
Tag:

We use cookies to run PerLod and to understand how the site is used. You can accept everything, or open Manage to turn individual categories off. Cookie policy.