Serverless Without the US Cloud Hangover: Implementing Sovereign FaaS Patterns in Norway

Let’s address the elephant in the server room: "Serverless" is a billing model, not just an architecture. For many Norwegian CTOs, the initial promise of AWS Lambda or Azure Functions—pay only for what you use—has curdled into a nightmare of unpredictable monthly bills and legal headaches following the Schrems II ruling.

If you are running fintech, healthtech, or public sector workloads in Oslo, sending user data to a US-owned cloud provider's "eu-central-1" region is no longer a simple checkbox. It is a compliance risk. The US CLOUD Act casts a long shadow.

But the architectural pattern of Serverless—event-driven, ephemeral compute, zero maintenance of idle processes—is brilliant. We don't want to lose that. The solution isn't to abandon the pattern, but to repatriate the platform.

In this analysis, we will deconstruct how to build a Private Serverless architecture using lightweight Kubernetes (K3s) and OpenFaaS on high-performance VDS infrastructure. This approach retains the developer experience of "git push to deploy" while keeping your data strictly on Norwegian soil and your costs flat.

The Architecture: Private FaaS on Bare-Metal VDS

The pattern we are implementing is the "Functions-as-a-Service (FaaS) Shim". Instead of renting the function runtime from a hyperscaler, we run the runtime ourselves. This requires infrastructure that behaves like bare metal to avoid the "double virtualization penalty"—where a container runs inside a VM, which runs on a hypervisor.

Pro Tip: When running Kubernetes on a VPS, standard HDD storage is a death sentence for etcd latency. We consistently see etcd timeouts on standard cloud instances. You absolutely need NVMe storage. CoolVDS NVMe instances provide the IOPS required to keep the Kubernetes control plane healthy without the "steal time" variance you get on oversold hosts.

Step 1: The Infrastructure Layer

We need a clean Linux environment. Alpine is too sparse for a K8s node; Ubuntu 20.04 or 22.04 LTS is the sweet spot. We rely on K3s because it strips out legacy cloud provider binaries, reducing the binary size to <100MB.

First, we prepare the kernel for high-density container workloads. On a standard CoolVDS instance, you should tune the following sysctl parameters to handle the rapid creation and destruction of network namespaces typical in serverless patterns:

# /etc/sysctl.d/99-k8s-networking.conf

# Increase the connection queue for high load
net.core.somaxconn = 65535

# Allow more local port range for ephemeral connections
net.ipv4.ip_local_port_range = 1024 65535

# Enable IP forwarding (mandatory for CNI plugins)
net.ipv4.ip_forward = 1

# Increase max open files for high concurrency
fs.file-max = 2097152

Apply these with sysctl -p. If you skip this, your "serverless" functions will start timing out simply because the host OS ran out of file descriptors during a traffic spike.

Step 2: The Lightweight Orchestrator

Installing K3s on a single high-performance VDS allows us to simulate a cluster environment. This is cost-efficient for development and production workloads that don't need multi-region redundancy yet.

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

We disable the default Traefik because we want granular control over our Ingress, likely using NGINX or Contour later for better handling of "Function Cold Starts".

Step 3: Deploying OpenFaaS

OpenFaaS (Function as a Service) is the standard for Kubernetes-native serverless. It provides the API gateway, the watchdog (which scales functions to zero), and the metrics engine (Prometheus).

We use arkade, a tool built by the OpenFaaS community, to simplify the helm chart management. It was a staple in 2021 and remains the fastest way to bootstrap in 2022.

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

# Install OpenFaaS on our K3s cluster
arkade install openfaas \
  --load-balancer # Uses K3s ServiceLB \
  --set=faasIdler.dryRun=false  # Actually scale to zero

The Cold Start Problem: NVMe to the Rescue

In a public cloud, a "cold start" (loading a function's code into memory) can take 200ms to 2 seconds. This is often due to network-attached storage latency fetching the container image.

By hosting on CoolVDS, where local NVMe storage is standard, image pull times are drastically reduced. We can optimize this further by tweaking the containerd configuration to use snapshotters, but the raw I/O throughput is the biggest factor.

Here is a comparison of image pull times for a standard Python 3.8 function image (50MB):

The Code: A GDPR-Compliant Data Processor

Let's write a function that sanitizes user logs. In a public cloud, you might worry about where these logs are temporarily stored. Here, we know they never leave the /var/lib/containerd on your Oslo-based server.

stack.yml (OpenFaaS configuration):

version: 1.0
provider:
  name: openfaas
  gateway: http://127.0.0.1:8080
functions:
  log-sanitizer:
    lang: python3-http
    handler: ./log-sanitizer
    image: registry.your-company.no/log-sanitizer:latest
    environment:
      write_debug: true
      read_timeout: 10s
      write_timeout: 10s
    annotations:
      com.openfaas.scale.min: 0
      com.openfaas.scale.max: 20

handler.py:

import json
import re

def handle(req):
    event = json.loads(req)
    
    # Norwegian Phone Number Regex (simple)
    # We scrub this before storing anything
    pii_regex = r"(?:\+47|0047|47)?\d{8}"
    
    sanitized_log = re.sub(pii_regex, "[REDACTED]", event.get("log_entry", ""))
    
    return {
        "status": "processed",
        "sanitized_entry": sanitized_log,
        "compliance": "Schrems-II-OK"
    }

Deploying this is a single command: faas-cli up -f stack.yml.

Why Latency Matters in the Nordics

When your users are in Oslo, Bergen, or Trondheim, routing traffic to Frankfurt (often the nearest major region for hyperscalers) adds 20-30ms of round-trip latency. That doesn't sound like much, but in a microservices chain where one request triggers five internal function calls, that latency compounds.

CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange). The latency from a user in Oslo to your serverless function is typically under 2ms. When you own the infrastructure, you own the network path.

The Economic Argument: Fixed Costs

The danger of serverless is the "success disaster." If your function goes viral or gets stuck in a loop, your bill scales infinitely. With a VDS-based approach, your cost is capped at the price of the instance. If you hit 100% CPU, your functions slow down—they don't bankrupt you. For a pragmatic CTO, that predictability is worth its weight in gold.

Summary of Benefits

• Data Sovereignty: Data never leaves Norway.
• Cost Control: Flat monthly fee vs. variable per-request billing.
• Performance: NVMe storage eliminates cold-start lag.
• No Vendor Lock-in: It's just Docker and Kubernetes. You can move it anywhere.

Building a sovereign serverless platform isn't just about compliance; it's about taking back control of your stack. Don't let your architecture be dictated by a billing department in Seattle.

Ready to build? Provision a high-performance NVMe instance on CoolVDS today and have your Kubernetes cluster running in under 5 minutes.