DPTCloud
Back to articles
Technology Insight

Enterprise Networking Beyond Orchestration: Implementing Cilium Service Mesh Across Independent Multi-VPS Environments Without Kubernetes

May 30, 2026

Introduction: The Case for Service Mesh Without Kubernetes

For years, the concepts of a Service Mesh and Kubernetes have been treated as an inseparable pair. Organizations seeking advanced traffic management, mutual TLS (mTLS), and granular observability have naturally gravitated toward deploying robust Kubernetes clusters. However, this architectural coupling introduces significant operational complexity and resource overhead that may not align with every enterprise strategy.

Many modern enterprises maintain highly stable, distributed application workloads running across independent, multi-VPS (Virtual Private Server) environments. Migrating these systems to a fully managed or bare-metal Kubernetes cluster solely to gain service mesh capabilities represents an unnecessary expenditure of engineering resources. This is where Cilium enters as a paradigm-shifting solution.

By leveraging the power of eBPF (Extended Berkeley Packet Filter), Cilium can operate directly at the Linux kernel level, completely decoupled from Kubernetes orchestrators. This comprehensive technical guide explores how to integrate Cilium Service Mesh across a decentralized multi-VPS infrastructure, providing your standalone applications with enterprise-grade security, observability, and traffic control.

The Architecture of a Standalone Cilium Deployment

In a standard cloud-native environment, Cilium relies on the Kubernetes API server for configuration distribution and state management. In a multi-VPS standalone environment, we replace this dependency by utilizing Cilium in standalone agent mode, backed by a highly available distributed key-value store like Consul or etcd. This external datastore acts as the single source of truth for security policies, service discovery, and endpoint routing across all independent VPS nodes.

Core Architectural Components:

  • Cilium Agent (cilium-agent): Runs as a systemd service on each individual VPS, interacting directly with the local Linux kernel to load eBPF programs.
  • Distributed KV Store (etcd): A clustered etcd deployment accessible by all VPS nodes to synchronize network state, identity allocations, and security policies.
  • Mesh Interconnect (WireGuard or IPsec): A secure, encrypted overlay network or mesh VPN linking the independent VPS providers to facilitate private node-to-node communication.

Key Architectural Insight: Because Cilium operates inside the Linux kernel via eBPF, network packets bypass standard IPTables routing tables. This results in a massive reduction in latency and CPU utilization compared to traditional sidecar-based service meshes like Istio.

Step-by-Step Implementation Blueprint

Deploying Cilium across independent hosts requires careful preparation of the underlying operating systems and networking layers. Follow this structured blueprint to establish your decentralized service mesh.

Step 1: Preparing the VPS Nodes and Linux Kernel

Cilium requires modern Linux kernel features to execute eBPF bytecode efficiently. Ensure all your independent VPS nodes are running Ubuntu 22.04 LTS or a similar distribution with a kernel version of 5.15 or higher.

First, execute the following commands on all nodes to mount the BPF filesystem and verify kernel compatibility:

sudo mount bpffs /sys/fs/bpf -t bpf
echo "bpffs /sys/fs/bpf bpf defaults 0 0" | sudo tee -a /etc/fstab

Step 2: Establishing the Secure Cross-Node Network Mesh

Because your nodes reside on independent VPS networks (potentially across different cloud providers like AWS, DigitalOcean, and Linode), they must be securely interconnected. We recommend establishing a WireGuard mesh network to act as the underlying L3 transit layer.

  1. Assign a unique private IP subnet to each VPS node (e.g., Node 1: 10.0.1.0/24, Node 2: 10.0.2.0/24).
  2. Configure WireGuard tunnels between all nodes to allow direct routing of these subnets across the public internet via encrypted endpoints.

Step 3: Deploying the External Key-Value Store

Cilium needs a shared datastore to coordinate global identities. For this architecture, deploy a 3-node etcd cluster on dedicated, secured instances or colocate them securely within your existing VPS pool. Ensure that TLS encryption is strictly enforced for all etcd client-to-server communications.

Once etcd is operational, note the access endpoints and distribute the client certificates (ca.crt, client.crt, client.key) securely to the /etc/cilium/certs/ directory on every target host.

Step 4: Installing and Configuring the Standalone Cilium Agent

Without Kubernetes, the Cilium agent must be installed via binary packages or compiled from source, and managed via systemd. Create the primary configuration file at /etc/cilium/ciliumd.yaml:

kvstore: "etcd"
kvstore-opt:
  etcd.config: "/etc/cilium/etcd-config.yaml"
cluster-name: "standalone-enterprise-mesh"
cluster-id: "1"
enable-l7-proxy: "true"
enable-ipv4: "true"
identity-allocation-mode: "kvstore"

Next, configure the corresponding /etc/cilium/etcd-config.yaml to point to your secure etcd cluster:

endpoints:
  - "[https://etcd-node-1.internal:2379](https://etcd-node-1.internal:2379)"
  - "[https://etcd-node-2.internal:2379](https://etcd-node-2.internal:2379)"
  - "[https://etcd-node-3.internal:2379](https://etcd-node-3.internal:2379)"
ca-file: "/etc/cilium/certs/ca.crt"
cert-file: "/etc/cilium/certs/client.crt"
key-file: "/etc/cilium/certs/client.key"

Enable and start the Cilium systemd service to initialize the eBPF datapath across your host interfaces.

Unlocking Enterprise Service Mesh Capabilities

With the eBPF networking layer successfully active across your multi-VPS environment, you can now enforce core service mesh features directly on your application workloads without the complexity of traditional sidecar proxies.

1. Sidecarless Mutual TLS (mTLS)

Traditional meshes inject an Envoy proxy sidecar container alongside every single application instance to intercept and encrypt traffic. Cilium completely eliminates this resource tax by handling mTLS natively at the kernel level. When Node A communicates with Node B, the Cilium kernel module intercepts the socket connection, validates cryptographic identities via SPIFFE/SPIRE, and wraps the transit payload inside an optimized WireGuard/IPsec session automatically.

2. Layer 7 Traffic Management and Policy Enforcement

Cilium allows you to define granular L7 traffic steering rules, including HTTP header matching, URL prefix routing, and rate limiting. Cilium achieves this by selectively redirecting specific application traffic to an internal, highly optimized local Envoy instance embedded directly inside the Cilium agent, rather than spinning up dozens of independent application sidecars.

You can enforce strict security policies across your VPS instances using simple YAML definitions distributed via your KV store:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "secure-api-access"
spec:
  endpointSelector:
    matchLabels:
      app: "backend-api"
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: "frontend-web"
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/v1/public/.*"

Operational Advantages: Performance and Efficiency

Transitioning from a traditional cloud-native architecture to a standalone Cilium multi-VPS mesh yields substantial operational dividends:

Metric / Dimension Traditional Sidecar Mesh (e.g., Istio on K8s) Standalone Cilium Mesh (e.g., eBPF on VPS)
Memory Overhead High (30MB - 100MB+ per application container) Extremely Low (Fixed allocation per host system)
Network Latency Added microsecond penalties due to user-space context switches Near-line-rate execution within the Linux Kernel space
Infrastructure Cost High (Requires dedicated master and worker nodes) Zero extra node overhead (Runs on existing VPS compute)

Conclusion: A Lean Path to Modern Infrastructure

Decoupling Cilium Service Mesh from Kubernetes enables businesses to achieve elite-tier network security, robust encryption, and advanced observability without forcing a massive, risky architectural migration. By running Cilium natively on a multi-VPS infrastructure, you retain the simplicity of standalone host management while reaping the structural rewards of modern, eBPF-driven connectivity. This lean approach represents the next evolutionary step for performance-critical, cost-conscious enterprise application architecture.

Enterprise Networking Beyond Orchestration: Implementing Cilium Service Mesh Across Independent Multi-VPS Environments Without Kubernetes | DPTCloud