Introduction: The Evolution of Service Mesh Beyond Kubernetes

For years, microservices architectures and service meshes have been almost exclusively synonymous with Kubernetes. High-performance networking, mutual TLS (mTLS), transparent encryption, and granular observability are traditionally achieved by deploying complex control planes like Istio or Linkerd inside a managed container orchestration system. However, for many enterprise workloads, mid-sized business applications, or legacy systems, a full-scale Kubernetes cluster introduces unnecessary operational overhead, resource consumption, and maintenance complexity.

Enter Cilium. Originally renowned as an eBPF-based networking and security plugin for Kubernetes, Cilium has evolved. By leveraging the power of Extended Berkeley Packet Filters (eBPF) directly within the Linux kernel, it is now entirely feasible to build a robust, secure, and highly observable Cilium Service Mesh across an independent, multi-VPS (Virtual Private Server) environment—completely decoupled from Kubernetes. This guide provides a comprehensive technical blueprint for implementing this cutting-edge architecture.

Why Choose Cilium for Standalone Multi-VPS Deployments?

Operating a service mesh natively on Linux instances without an orchestration layer offers several distinct advantages for specific business use cases:

Resource Efficiency: Kubernetes control planes (etcd, API server, controller managers) consume significant memory and CPU. Running Cilium standalone ensures your infrastructure resources are dedicated almost entirely to your business logic.
Reduced Operational Complexity: You eliminate the need to manage Kubernetes upgrades, certificate rotations for the API server, and complex ingress controllers, while still retaining advanced networking capabilities.
Legacy and Hybrid Cloud Integration: Many enterprise applications run on traditional bare-metal or standalone virtual machines. Cilium bridges the gap, allowing legacy VPS workloads to communicate securely with modern microservices.

By shifting the intelligence from user-space sidecar proxies (like traditional Envoy configurations) into the Linux kernel via eBPF, Cilium processes networking data packets at unparalleled speeds, bypassing the standard netfilter/iptables overhead completely.

Architectural Blueprint: Connecting Independent VPS Nodes

In a standalone multi-VPS setup, we bypass the Kubernetes CNI (Container Network Interface) layer. Instead, we install the Cilium agent (cilium-agent) directly as a systemd service on each independent host. These hosts communicate over a secure mesh network, using a distributed key-value store to synchronize state, endpoint identities, and security policies.

The Core Components

Independent VPS Nodes: Standard Linux distributions (such as Ubuntu 22.04 LTS or Debian 12) running a modern Linux kernel (v5.15 or higher is highly recommended for optimal eBPF feature support).
State Synchronization (KV Store): A lightweight, highly available External etcd or Consul cluster accessible by all VPS nodes to synchronize IPAM (IP Address Management) and security identities.
Cilium Agent & Operator: Deployed as native binaries or standalone Docker containers in host-networking mode to manage the local eBPF programs.

Key Architectural Insight: Because there is no Kubernetes API server to watch for pod creations, Cilium relies on container runtimes (like Docker or containerd) or local systemd services on the VPS, assigning distinct security identities based on local runtime labels or IP blocks.

Step-by-Step Implementation Guide

1. Kernel and System Prerequisites

Before installing Cilium, ensure your VPS instances run a compatible kernel. Run the following command on each node to verify your configuration:

uname -r

Additionally, the eBPF filesystem must be mounted on all participating virtual servers:

sudo mount bpffs /sys/fs/bpf -t bpf

To make this persistent across reboots, add the following entry to your /etc/fstab file:

bpffs /sys/fs/bpf bpf defaults 0 0

2. Deploying the Shared Key-Value Store

Cilium requires a unified registry to map IP addresses to security identities across your disparate VPS instances. For this demonstration, we utilize a standalone etcd cluster. Once your etcd cluster is running securely with TLS enabled, create a Cilium configuration file (/etc/cilium/cilium.yaml) on each VPS pointing to this store:

kvstore: etcd
kvstore-opt:
  etcd.config: /etc/cilium/etcd-config.json

3. Installing the Cilium Agent Natively

Download the standalone Cilium binaries and extract them to your system path. Configure the agent to run via systemd by creating a service file at /etc/systemd/system/cilium.service:

[Unit]
Description=Cilium Agent
After=network.target

[Service]
ExecStart=/usr/bin/cilium-agent --kvstore etcd --kvstore-opt etcd.config=/etc/cilium/etcd-config.json --enable-l7-proxy=true
Restart=always

[Install]
WantedBy=multi-user.target

Enable and start the service across all nodes:

sudo systemctl daemon-reload
sudo systemctl enable --now cilium

Enabling Service Mesh Features: mTLS and L7 Traffic Management

Once the underlying eBPF network fabric connects your standalone nodes, you can tap into the Cilium Service Mesh features without editing a single line of application code.

Transparent Encryption and mTLS

Traditionally, establishing mutual TLS between independent virtual servers required configuring complex certificates inside your application or running heavy reverse proxies. Cilium achieves transparent encryption at the network layer using either WireGuard or IPsec natively built into the Linux kernel.

By enabling WireGuard in your Cilium configuration, all cross-VPS traffic is automatically encrypted, authenticated, and encapsulated via eBPF routing rules, satisfying strict compliance frameworks like SOC2 or ISO 27001 instantly.

Layer 7 Traffic Control and Observability

With Cilium's embedded Envoy support, you can enforce HTTP-level routing policies, implement canary deployments, and track golden signals (Latency, Error Rates, Saturation) across your VPS network. Since Cilium operates at the kernel level, it intercepts socket layer operations, reducing latency overhead compared to traditional user-space sidecar architectures.

Best Practices for Production Management

To successfully operate an independent, non-Kubernetes Cilium Service Mesh long-term, adhere to these operational standards:

Automate Configuration Management: Use infrastructure-as-code tools like Ansible or OpenTofu/Terraform to provision VPS instances, apply kernel configurations, and distribute Cilium systemd profiles uniformly.
Implement Robust Monitoring: Deploy Hubble (Cilium's observability engine) alongside Prometheus and Grafana. Even without Kubernetes, Hubble provides deep graphical insights into network flows, dependencies, and policy violations across your VPS architecture.
Secure the KV Store: Your etcd or Consul cluster is the single point of truth for your service mesh network. Enforce strict firewall rules allowing access only from your trusted VPS node IPs, and ensure automated backup routines are active.

Conclusion

Tearing down the assumption that service meshes require Kubernetes opens up massive architectural flexibility. By deploying Cilium Service Mesh directly onto a multi-VPS infrastructure, you unlock the bleeding-edge performance of eBPF, transparent kernel-level mTLS, and granular L7 observability—all while maintaining a lightweight, simple, and highly cost-efficient footprint. For businesses looking to optimize their cloud spend and operational complexity without sacrificing modern cloud-native security, this standalone approach represents the future of pragmatic enterprise infrastructure design.

Architecting a Cilium Service Mesh Across Independent Multi-VPS Environments Without Kubernetes