Serverless without the Cloud: Architecting High-Performance FaaS on NVMe VPS

Let’s clear the air: "Serverless" is a marketing term, not a magic trick. There are always servers. The only question is whether you control them, or if you're renting them by the millisecond at a 400% markup while praying your cold starts don't kill your conversion rates. For many DevOps teams in the Nordics, the allure of AWS Lambda or Azure Functions fades rapidly when the first bill arrives—or when Datatilsynet starts asking exactly where that customer data is physically processed.

I have spent the last decade debugging distributed systems, from the early days of chaotic bare-metal clusters to modern Kubernetes meshes. The trend in 2025 is clear: we are moving back to the edge. We are moving back to owned infrastructure. But we aren't giving up the developer experience of Serverless.

This article details how to architect a robust, self-hosted Serverless platform on high-performance Virtual Dedicated Servers (VDS). We will focus on the Norwegian context—latency to NIX (Norwegian Internet Exchange), GDPR compliance, and raw I/O performance.

The Latency Lie and the "Cold Start" Problem

When you deploy to a public cloud FaaS (Function as a Service) provider, your code lives in a bucket. When a request hits, the provider spins up a container, loads your runtime, injects your code, and executes it. This is the "Cold Start." In Frankfurt or Dublin, this might add 200ms to 2 seconds.

But for a user in Oslo or Trondheim, you are also battling network latency. Round-trip time (RTT) from Oslo to Central Europe is decent, but it's not instant. When you stack network latency on top of cold start latency, your "snappy" microservice feels sluggish.

Pro Tip: Latency is additive. A 50ms network RTT + 300ms Cold Start + 100ms Execution = 450ms total. Running on a CoolVDS instance in Oslo cuts that network RTT to <5ms for local traffic, and persistent workers eliminate the cold start entirely.

Architecture Pattern: The "K3s + OpenFaaS" Stack

We don't need the complexity of full-blown Kubernetes (k8s) to run functions. By 2025, K3s has cemented itself as the standard for lightweight orchestration. Combined with OpenFaaS, you get the exact same developer workflow as AWS Lambda (faas-cli up), but running on your own iron.

1. The Foundation: Kernel Tuning for High Concurrency

Before installing orchestration layers, you must prep the OS. Standard Linux distributions are tuned for general-purpose computing, not for handling thousands of ephemeral function containers. On a CoolVDS NVMe instance, you have the I/O throughput to handle this, but the kernel will bottleneck on network sockets if you don't intervene.

Here is the /etc/sysctl.conf configuration I use for high-throughput FaaS nodes:

# Increase the range of ephemeral ports
net.ipv4.ip_local_port_range = 1024 65535

# Allow reusing sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1

# Increase max open files (critical for high container density)
fs.file-max = 2097152

# Increase the maximum number of memory map areas a process may have
vm.max_map_count = 262144

# Optimize for low latency over throughput
net.ipv4.tcp_low_latency = 1

Apply these with sysctl -p. If you skip this, your serverless gateway will start dropping connections under load, not because of CPU limits, but because it ran out of file descriptors.

2. The Orchestrator: Deploying K3s

We use K3s because it strips out the bloat of cloud providers (no need for AWS cloud-controller-manager). It starts in seconds.

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -

Note: We disable the default Traefik because we want granular control over our Ingress, likely using Nginx or a dedicated API Gateway later.

3. The Serverless Framework: OpenFaaS

Once K3s is running, install OpenFaaS using arkade (the preferred installer in 2025). This installs the gateway, the queue worker (NATS JetStream), and the Prometheus metrics server.

curl -sLS https://get.arkade.dev | sudo sh

arkade install openfaas \
  --load-balancer 
  --set=faasIdler.dryRun=false

The Storage Bottleneck: Why NVMe Matters

Public cloud FaaS is usually stateless. If you need to process a file, you have to download it from S3, process it, and upload it back. This incurs massive I/O penalties and bandwidth costs.

With a self-hosted architecture on CoolVDS, you can use hostPath persistence or local NVMe storage directly attached to your functions. This is a massive advantage for data-heavy workloads like image processing or log analysis.

Here is an example stack.yml for a function that relies on high-speed disk I/O, something that would bankrupt you on Lambda:

version: 1.0
provider:
  name: openfaas
  gateway: http://127.0.0.1:8080
functions:
  image-resizer:
    lang: python3-http
    handler: ./image-resizer
    image: registry.coolvds-client.no/image-resizer:latest
    environment:
      write_debug: true
    # Mount the NVMe directly for blistering speed
    mounts:
      - kind: hostPath
        source: /mnt/nvme_data/uploads
        target: /tmp/uploads

By mounting /mnt/nvme_data directly, your function processes files at disk speed (3000+ MB/s on CoolVDS NVMe) rather than network speed.

Security & Compliance: The "Schrems II" Reality

Even in 2025, the legal landscape regarding data transfer between Europe and the US remains complex. For Norwegian businesses, specifically those in health (Helse) or finance, keeping data within the EEA is not just a preference; it is a requirement.

When you use AWS Lambda, you are trusting the "Region" selection. When you use CoolVDS, you know exactly which rack in Oslo your data sits on. We offer:

• Data Sovereignty: Your bits never leave Norwegian soil unless you route them out.
• DDoS Protection: Our infrastructure includes enterprise-grade scrubbing, protecting your API gateway from volumetric attacks.
• Private Networking: Connect your FaaS nodes to your database nodes via a private VLAN, keeping backend traffic completely off the public internet.

Monitoring the Beast

You cannot improve what you do not measure. In a serverless environment, you need to monitor queue depth (lag) and execution time. Since OpenFaaS bundles Prometheus, we just need to scrape it.

Add this scrape config to your Prometheus setup to monitor function scaling:

scrape_configs:
  - job_name: 'openfaas-endpoints'
    kubernetes_sd_configs:
    - role: endpoints
      namespaces:
        names:
          - openfaas-fn
    relabel_configs:
    - source_labels: [__meta_kubernetes_service_name]
      action: keep
      regex: .+
    - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
      action: keep
      regex: true

Conclusion: Take Back Control

The "Serverless" revolution was never about getting rid of servers. It was about abstraction. But abstractions leak, and they cost money. By bringing the serverless pattern in-house on high-performance infrastructure, you gain the best of both worlds: the agility of FaaS and the raw power and cost-efficiency of bare metal.

Don't let your architecture be dictated by a cloud provider's billing model. Build a platform that serves your code, your users, and your budget.

Ready to build? Deploy a high-frequency NVMe instance in our Oslo data center today. With CoolVDS, your infrastructure is as robust as your code.