Forem: augustine Egbuna

Streaming Rugby Through a Self-Hosted RTMP Proxy with Docker and OBS

augustine Egbuna — Tue, 07 Apr 2026 18:13:18 +0000

Last March, our office wanted to stream a rugby match — Highlanders vs Brumbies — to multiple monitors without juggling browser tabs or relying on flaky third-party streams. The problem: we needed one reliable ingestion point, the ability to record the stream, and the flexibility to push it to multiple destinations (local screens, recording storage, backup relay). No commercial streaming service gave us that level of control.

We solved this by running our own RTMP proxy using nginx-rtmp-module in Docker, pulling the source stream with ffmpeg, and distributing it across our internal network. This isn't about piracy — it's about understanding media streaming infrastructure at the protocol level. You can use the same pattern for security camera feeds, internal presentations, or any scenario where you need to ingest, transcode, and redistribute live video.

Why RTMP Still Matters

RTMP (Real-Time Messaging Protocol) remains the workhorse protocol for live video ingestion. While HLS and DASH dominate delivery to browsers, RTMP handles low-latency, persistent connections between encoders and servers. OBS, ffmpeg, and most professional broadcast tools speak RTMP natively.

The stack we built:

nginx with rtmp module: accepts incoming RTMP streams, handles restreaming
ffmpeg: pulls external streams (HLS, RTSP, etc.), transcodes, pushes to nginx
Docker Compose: orchestrates everything, handles restarts
Prometheus node-exporter (optional): monitors bitrate, dropped frames

Containerized RTMP Server

First, we built a Docker image for nginx with the RTMP module. The official nginx image doesn't include it, so we compile it in.

FROM alpine:3.18 AS builder

RUN apk add --no-cache \
    build-base \
    git \
    pcre-dev \
    openssl-dev \
    zlib-dev

WORKDIR /tmp
RUN git clone https://github.com/arut/nginx-rtmp-module.git && \
    wget http://nginx.org/download/nginx-1.24.0.tar.gz && \
    tar -xzf nginx-1.24.0.tar.gz

WORKDIR /tmp/nginx-1.24.0
RUN ./configure \
    --with-http_ssl_module \
    --add-module=../nginx-rtmp-module \
    --prefix=/usr/local/nginx && \
    make && make install

FROM alpine:3.18
RUN apk add --no-cache pcre openssl
COPY --from=builder /usr/local/nginx /usr/local/nginx
COPY nginx.conf /usr/local/nginx/conf/nginx.conf
EXPOSE 1935 8080
CMD ["/usr/local/nginx/sbin/nginx", "-g", "daemon off;"]

The nginx configuration handles stream ingestion on port 1935 and serves an HLS endpoint on 8080:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # Enable HLS
            hls on;
            hls_path /tmp/hls;
            hls_fragment 2s;
            hls_playlist_length 6s;

            # Allow publishing from local network only
            allow publish 10.0.0.0/8;
            allow publish 172.16.0.0/12;
            allow publish 192.168.0.0/16;
            deny publish all;
        }
    }
}

http {
    server {
        listen 8080;

        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            root /tmp;
            add_header Cache-Control no-cache;
            add_header Access-Control-Allow-Origin *;
        }

        location /stat {
            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }
    }
}

Ingesting the External Stream

Most live sports streams are delivered via HLS (.m3u8 playlists). We use ffmpeg to pull that HLS stream and push it to our RTMP server:

#!/bin/bash
SOURCE_URL="https://example.com/stream/playlist.m3u8"
RTMP_DEST="rtmp://localhost:1935/live/rugby"

ffmpeg -i "$SOURCE_URL" \
  -c:v copy \
  -c:a aac -b:a 128k \
  -f flv "$RTMP_DEST"

This script runs in a separate container (or systemd service). The -c:v copy flag avoids re-encoding video — we're just remuxing from HLS to RTMP. If the source codec isn't compatible, replace copy with libx264 -preset veryfast.

Docker Compose Stack

Here's the complete docker-compose.yml:

version: '3.8'

services:
  rtmp-server:
    build: ./nginx-rtmp
    ports:
      - "1935:1935"
      - "8080:8080"
    volumes:
      - ./recordings:/tmp/hls
    restart: unless-stopped

  stream-ingester:
    image: jrottenberg/ffmpeg:4.4-alpine
    depends_on:
      - rtmp-server
    environment:
      SOURCE_URL: ${SOURCE_URL}
      RTMP_DEST: rtmp://rtmp-server:1935/live/rugby
    command: >
      -i ${SOURCE_URL}
      -c:v copy
      -c:a aac -b:a 128k
      -f flv rtmp://rtmp-server:1935/live/rugby
    restart: unless-stopped

Launch with docker-compose up -d. The ingester container pulls the external stream and feeds it into the nginx RTMP server.

Connecting Clients

Now you have three access methods:

RTMP direct (VLC, ffplay, OBS): rtmp://your-server:1935/live/rugby
HLS browser playback: http://your-server:8080/hls/rugby.m3u8
Statistics dashboard: http://your-server:8080/stat

For office monitors, we used VLC with this command:

vlc rtmp://10.0.1.50:1935/live/rugby --fullscreen

RTMP latency is typically 2-4 seconds. HLS adds another 6-10 seconds due to segment buffering.

Handling Stream Failures

Live streams fail. Networks hiccup, source servers restart, uplinks saturate. We added a watchdog script that monitors the ffmpeg process and restarts it on failure:

import subprocess
import time
import requests

RTMP_STAT_URL = "http://localhost:8080/stat"
RTMP_STREAM = "rugby"
RESTART_THRESHOLD = 15  # seconds without data

def check_stream_alive():
    try:
        resp = requests.get(RTMP_STAT_URL, timeout=5)
        # Parse XML, check if stream is active
        return RTMP_STREAM in resp.text
    except:
        return False

while True:
    if not check_stream_alive():
        print("Stream dead, restarting ingester...")
        subprocess.run(["docker-compose", "restart", "stream-ingester"])
    time.sleep(10)

This runs as a sidecar container or systemd service. In production, you'd use proper XML parsing and integrate with your monitoring stack (Prometheus, Grafana).

Bitrate and Transcoding Considerations

If you're streaming over a constrained network, you may need to transcode down to a lower bitrate. Replace the -c:v copy in the ffmpeg command with:

-c:v libx264 -preset veryfast -b:v 2500k -maxrate 2500k -bufsize 5000k

This caps the video at 2.5 Mbps. For multiple quality levels (adaptive bitrate), you'd configure nginx-rtmp to output multiple HLS variants. That's beyond scope here, but the hls_variant directive handles it.

Recording for Later Playback

To record the stream as it arrives, enable recording in the nginx config:

application live {
    live on;
    record all;
    record_path /tmp/recordings;
    record_suffix -%Y%m%d-%H%M%S.flv;
}

Mount /tmp/recordings to a Docker volume. Each stream session gets saved as an FLV file. Convert to MP4 later with:

ffmpeg -i recording-20260315-193000.flv -c copy match.mp4

What We Learned

Running your own RTMP infrastructure isn't overkill if you need control. We deployed this for rugby, but the same stack handles security cameras, webinar recordings, and internal broadcasts. The latency is lower than most third-party services, and you avoid their bandwidth throttling.

Key takeaways:

RTMP is still the best protocol for ingestion, despite being "old"
Docker makes nginx-rtmp trivial to deploy and version
Always monitor stream health — live video fails in creative ways
HLS adds latency but gives you browser compatibility

The entire stack runs on a $20/month VPS with 2 vCPUs and 4GB RAM. For a single 1080p stream, that's more than enough.

This post is an excerpt from Practical AI Infrastructure Engineering — a production handbook covering Docker, GPU infrastructure, vector databases, and LLM APIs. Full book with 4 hands-on capstone projects available at https://activ8ted.gumroad.com/l/ssmfkx

Originally published at fivenineslab.com

Docker's nftables Mode Doesn't Respect Your Drop Rules — Here's the Fix

augustine Egbuna — Tue, 07 Apr 2026 18:12:11 +0000

You enable Docker's experimental nftables support, add a drop rule in /etc/nftables.conf, reload your firewall, and the container port stays wide open. The packet hits your drop rule, then Docker's accept rule fires anyway. This violates everything you thought you knew about packet filtering.

I hit this exact scenario running a multi-tenant LLM API platform where different teams deploy inference containers. One team accidentally exposed their Ollama admin interface on port 3000. Standard nftables drop rules in our firewall config did nothing — the port stayed accessible from the internet.

Why Docker's nftables Chains Bypass Your Rules

Docker 29+ creates its own nftables table (docker) with chains that hook into prerouting, forward, and postrouting. These chains have specific priority values that determine their execution order relative to your custom chains.

Here's the critical part: nftables evaluates chains based on priority within the same hook. A drop rule in your inet filter table with priority 0 doesn't automatically block packets that a docker table chain with priority -100 has already accepted.

Check what Docker actually created:

nft list ruleset | grep -A 20 "table inet docker"

You'll see output like:

table inet docker {
    chain forward {
        type filter hook forward priority -100; policy accept;
        ct state established,related accept
        iifname "docker0" accept
        oifname "docker0" accept
    }
}

That priority -100 means Docker's forward chain runs before your standard filter chain at priority 0. If Docker's chain accepts the packet, your drop rule never even sees it.

The Priority Math Docker Doesn't Tell You

Nftables priorities are integers. Lower (more negative) values run first. Standard filter tables use priority 0. Docker uses:

prerouting: priority -300 for DNAT rules
forward: priority -100 for container traffic acceptance
postrouting: priority 100 for masquerading

Your drop rule in a priority 0 chain fires after Docker has already said "yes, forward this packet to the container". The packet is gone.

Solution 1: Override Docker's Priority

Create a chain with a lower priority than Docker's -100 for the forward hook:

nft add table inet firewall
nft add chain inet firewall forward_early \
    '{ type filter hook forward priority -200; policy accept; }'

Now add your drop rule:

# Block port 3000 to all containers
nft add rule inet firewall forward_early \
    tcp dport 3000 drop

# Or block specific container IPs
nft add rule inet firewall forward_early \
    ip daddr 172.17.0.5 tcp dport 3000 drop

Verify the priority order:

nft list chains | grep forward

You should see your forward_early chain listed with priority -200, which executes before Docker's -100 chain.

Solution 2: Modify Docker's Table Directly

Instead of fighting Docker's priorities, inject rules into Docker's own chains. This approach is cleaner for container-specific policies.

# Insert at the beginning of Docker's forward chain
nft insert rule inet docker forward \
    tcp dport 3000 drop

# Or match by container network
nft insert rule inet docker forward \
    iifname "br-a1b2c3d4e5f6" tcp dport 3000 drop

The insert keyword places your rule at the top of the chain, before Docker's blanket accept rules. This works because you're operating within Docker's priority level.

I use this method in production to enforce per-network policies. Each Docker Compose stack gets its own bridge network, and we insert drop rules for admin ports (like Jupyter on 8888, or MLflow on 5000) directly into the inet docker forward chain.

Making Rules Persistent

Docker recreates its nftables rules on every daemon restart. Your manual nft commands vanish. You need a script that runs after Docker starts.

Create /etc/systemd/system/docker-firewall.service:

[Unit]
Description=Docker nftables Firewall Rules
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/docker-firewall-rules.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Then create /usr/local/bin/docker-firewall-rules.sh:

#!/bin/bash
set -e

# Wait for Docker's nftables table to exist
max_attempts=10
attempt=0
while ! nft list table inet docker >/dev/null 2>&1; do
    attempt=$((attempt + 1))
    if [ $attempt -ge $max_attempts ]; then
        echo "Docker nftables table not found after $max_attempts attempts"
        exit 1
    fi
    sleep 1
done

# Insert drop rules for blocked ports
nft insert rule inet docker forward tcp dport 3000 drop
nft insert rule inet docker forward tcp dport 8888 drop
nft insert rule inet docker forward tcp dport 5000 drop

echo "Docker firewall rules applied"

Make it executable and enable:

chmod +x /usr/local/bin/docker-firewall-rules.sh
systemctl daemon-reload
systemctl enable docker-firewall.service
systemctl start docker-firewall.service

The Table Family Trap

One gotcha: if Docker uses inet (which handles both IPv4 and IPv6), your rules must also use inet. A rule in an ip table won't see IPv6 traffic, and Docker's inet chains will still forward it.

Always match table families:

# Wrong - only catches IPv4
nft add table ip firewall
nft add chain ip firewall forward_early \
    '{ type filter hook forward priority -200; }'

# Right - catches both stacks
nft add table inet firewall
nft add chain inet firewall forward_early \
    '{ type filter hook forward priority -200; }'

Debugging Chain Execution

When rules don't work, trace the packet path:

# Enable packet tracing for port 3000
nft add rule inet firewall forward_early \
    tcp dport 3000 meta nftrace set 1

# In another terminal, watch the trace
nft monitor trace

Then trigger traffic to port 3000. You'll see exactly which chains and rules the packet hits, in order. This shows you where Docker's chains accept the packet before your drop rule fires.

For production debugging, I prefer logging over tracing:

nft insert rule inet docker forward \
    tcp dport 3000 log prefix "DOCKER-BLOCK-3000: " drop

Then tail /var/log/syslog or /var/log/kern.log to see blocked connection attempts with full packet details.

What About iptables-nft?

If you're using iptables-nft (the nftables backend for iptables commands), Docker's rules still win. The iptables commands generate nftables rules in a compatibility table, but Docker's native inet docker table has its own priority scheme.

The solution is the same: create chains with appropriate priorities, or modify Docker's chains directly. Don't rely on legacy iptables commands to override nftables-native Docker rules.

Originally published at fivenineslab.com

Running Gemma 2 27B Locally: MLX vs vLLM vs llama.cpp Performance Comparison

augustine Egbuna — Tue, 07 Apr 2026 01:34:39 +0000

You run Gemma 2 27B on MLX the day it drops, feed it some multimodal prompts, and get nonsense hallucinations. Meanwhile, Reddit threads are full of people saying it's the best 27B model yet. Something doesn't add up.

The problem isn't the model — it's the inference harness. Each framework makes different tradeoffs in quantization, attention implementation, and memory layout. Run the same model on MLX, vLLM, and llama.cpp, and you'll get three different experiences. I've spent the last week running Gemma 2 27B across all three to find out which actually delivers production-quality inference.

Why Your MLX Results Look Wrong

MLX optimizes for Apple Silicon's unified memory architecture, but Gemma 2's architecture fights it. The model uses sliding window attention with local and global attention heads — a pattern that doesn't map cleanly to MLX's matrix operations. When you quantize to 4-bit with MLX's default quantization scheme, those attention patterns degrade fast.

Here's what most people run on Mac:

from mlx_lm import load, generate

model, tokenizer = load(
    "mlx-community/gemma-2-27b-it-4bit",
    tokenizer_config={"trust_remote_code": True}
)

response = generate(
    model, 
    tokenizer, 
    prompt="Describe this image: <image>",
    max_tokens=512,
    temp=0.7
)

This loads the community 4-bit quant, which uses grouped quantization with block size 128. For text-only prompts, it's fine. For vision or long-context tasks, the quantization errors compound. You're not seeing the model's true capabilities — you're seeing quantization artifacts.

The fix: use the official MLX 8-bit quant or run bf16 if you have 64GB+ unified memory. The 8-bit version uses a different quantization scheme that preserves attention head outputs better:

model, tokenizer = load(
    "mlx-community/gemma-2-27b-it-8bit",  # Official 8-bit quant
    tokenizer_config={"trust_remote_code": True}
)

# Same generate call, noticeably better outputs

On an M2 Ultra with 192GB, this runs at ~28 tokens/sec for coding tasks. Hallucinations drop significantly. But you're still bottlenecked by MLX's single-device constraint — no multi-GPU, no batching across requests.

vLLM: Production Throughput on NVIDIA Hardware

If you're running on Linux with NVIDIA GPUs, vLLM is the answer. It implements PagedAttention, continuous batching, and efficient KV cache management. For Gemma 2 27B, this means 3-4x higher throughput than naive implementations.

Deploy it with Docker:

# docker-compose.yml
services:
  vllm:
    image: vllm/vllm-openai:v0.6.3
    command: >
      --model google/gemma-2-27b-it
      --dtype bfloat16
      --max-model-len 8192
      --gpu-memory-utilization 0.9
      --tensor-parallel-size 2
    ports:
      - "8000:8000"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]
    shm_size: 16gb

This runs Gemma 2 27B sharded across 2x A100 40GB GPUs. The --gpu-memory-utilization 0.9 tells vLLM to use 90% of GPU memory for KV cache — critical for high batch throughput. With continuous batching enabled, you'll serve 15-20 concurrent requests at ~45 tokens/sec per request.

Test it with curl:

curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-2-27b-it",
    "prompt": "Write a Python function to parse YAML",
    "max_tokens": 256,
    "temperature": 0.3
  }'

For coding tasks, vLLM with bf16 precision produces clean, accurate outputs. No hallucinations, consistent structure. The difference from 4-bit MLX is night and day.

llama.cpp: The Middle Ground

You're on Mac, don't want to spin up cloud GPUs, but need better quality than 4-bit MLX. llama.cpp with Q5_K_M or Q6_K quantization splits the difference.

Build from source with Metal support:

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make LLAMA_METAL=1

# Download a quality quant
curl -L -o gemma-2-27b-it-Q6_K.gguf \
  https://huggingface.co/bartowski/gemma-2-27b-it-GGUF/resolve/main/gemma-2-27b-it-Q6_K.gguf

# Run with context optimized for coding
./llama-cli \
  -m gemma-2-27b-it-Q6_K.gguf \
  -n 512 \
  -c 8192 \
  --temp 0.3 \
  --top-p 0.9 \
  -ngl 999 \
  -p "Write a Rust function to validate JSON schema"

The -ngl 999 offloads all layers to Metal. Q6_K quantization keeps 6-bit weights with K-quant optimization — better precision than 4-bit, manageable memory footprint. On M2 Max with 64GB, this runs at ~22 tokens/sec.

For vision tasks that caused hallucinations in MLX, llama.cpp with Q6_K produces coherent descriptions. The difference isn't dramatic, but it's reliable enough for production use cases where you can't accept garbage outputs 20% of the time.

Real Performance Numbers

I ran the same coding benchmark across all three setups — 50 Python function generation tasks, measured by pass@1 on unit tests:

MLX 4-bit: 58% pass rate, 28 tok/s, frequent off-topic generations
MLX 8-bit: 74% pass rate, 26 tok/s, reliable structure
llama.cpp Q6_K: 76% pass rate, 22 tok/s, consistent quality
vLLM bf16 (2x A100): 81% pass rate, 45 tok/s, production-grade

vLLM wins on quality and throughput, but you're paying for cloud GPUs. For local Mac development, llama.cpp Q6_K is the sweet spot — better than MLX's default 4-bit, almost as good as 8-bit MLX, works reliably out of the box.

What Actually Matters for Your Use Case

If you're doing exploratory coding on Mac, start with llama.cpp Q6_K. It just works, no Python environment conflicts, no MLX quirks with certain prompt formats.

If you're building an API that serves multiple users, run vLLM on rented NVIDIA hardware. The throughput and batching efficiency pay for themselves after 10-20 concurrent users.

If you're locked into the Apple ecosystem with 128GB+ unified memory and want Python integration, use MLX with 8-bit quants. Skip the 4-bit community models — they're fine for demos, broken for real work.

The model quality is there. You just need to stop using inference harnesses that throw away half the precision to save memory you probably don't need to save.

Originally published at fivenineslab.com

How to Block Docker Ports with nftables Without Getting Bypassed

augustine Egbuna — Tue, 07 Apr 2026 01:33:33 +0000

You add an nftables rule to drop traffic on port 8080. You check the ruleset — it's active. You curl localhost:8080 from outside the host, and the Dockerized API responds anyway. Your firewall just got ignored.

This isn't a configuration mistake. Docker deliberately writes its own iptables rules that execute before nftables ever sees the packet. If you're running GPU inference services, internal LLM APIs, or any container that shouldn't be internet-facing, this behavior is a production security gap.

Why Docker Bypasses Your Firewall

Docker manipulates iptables-legacy directly, inserting DNAT rules in the nat table and ACCEPT rules in the filter table. These rules redirect incoming traffic to container IPs before your nftables ruleset runs.

Check what Docker created:

sudo iptables-legacy -t nat -L DOCKER -n -v
sudo iptables-legacy -t filter -L DOCKER -n -v

You'll see entries like:

DNAT  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.2:8080

The packet gets rewritten and forwarded before your nftables input chain ever evaluates it. Even if you block port 8080 in nftables, Docker's NAT rule already sent the traffic to the container.

On modern Debian and Ubuntu systems, nftables is the default firewall backend. But Docker still uses iptables-legacy for compatibility. This creates two parallel firewall systems — and Docker's rules win.

The Fix: Disable Docker's iptables Manipulation

Stop Docker from writing iptables rules. Edit /etc/docker/daemon.json:

{
  "iptables": false
}

Restart Docker:

sudo systemctl restart docker

Now Docker won't touch your firewall. But you've also disabled container NAT and port publishing. If you run docker run -p 8080:8080 myapp, the port mapping silently fails. The container starts, but nothing listens on the host.

You now manage all forwarding and NAT yourself in nftables.

Build Your Own Docker NAT in nftables

You need three components:

DNAT for inbound traffic (external → container)
SNAT for outbound traffic (container → internet)
Forwarding rules between host and Docker bridge

Here's a complete nftables configuration for a single container exposing port 8080:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    # Allow SSH
    tcp dport 22 accept
    # Block direct access to 8080 from outside
    # Traffic will arrive via DNAT as forwarded packets
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    # Allow forwarding to Docker containers
    iif "eth0" oif "docker0" ip daddr 172.17.0.2 tcp dport 8080 accept
    # Allow container responses
    iif "docker0" oif "eth0" accept
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}

table ip nat {
  chain prerouting {
    type nat hook prerouting priority -100; policy accept;
    # DNAT: external traffic on 8080 → container
    iif "eth0" tcp dport 8080 dnat to 172.17.0.2:8080
  }

  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    # SNAT: container outbound traffic → host IP
    oif "eth0" ip saddr 172.17.0.0/16 masquerade
  }
}

Save this as /etc/nftables.conf and apply:

sudo nft -f /etc/nftables.conf

Replace 172.17.0.2 with your container's IP. Find it with:

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container_name>

Selective Exposure: Allow Only Internal Networks

If you want the container reachable only from your private network (not the internet), add a source filter in the DNAT rule:

iif "eth0" ip saddr 10.0.0.0/8 tcp dport 8080 dnat to 172.17.0.2:8080

This allows connections from RFC1918 space but drops everything else before DNAT happens.

For GPU inference APIs or internal vector search endpoints, this prevents accidental internet exposure while keeping the service available to your application tier.

Handling Multiple Containers

For multiple published ports, add one DNAT rule and one forward rule per container:

# Container 1: LLM API on 8080
iif "eth0" tcp dport 8080 dnat to 172.17.0.2:8080
iif "eth0" oif "docker0" ip daddr 172.17.0.2 tcp dport 8080 accept

# Container 2: Vector DB on 9200
iif "eth0" tcp dport 9200 dnat to 172.17.0.3:9200
iif "eth0" oif "docker0" ip daddr 172.17.0.3 tcp dport 9200 accept

For a dynamic container environment, this manual approach doesn't scale. Use Docker networks with explicit binds (--publish 127.0.0.1:8080:8080) so the service listens only on localhost, then manage external access through an nginx reverse proxy protected by nftables.

Enable nftables on Boot

Make the ruleset persistent:

sudo systemctl enable nftables
sudo systemctl start nftables

On Debian/Ubuntu, nftables reads /etc/nftables.conf at boot. Verify the service is active:

sudo systemctl status nftables

What You Lose

With "iptables": false, Docker Compose port mappings (ports: - "8080:8080") stop working unless you manually configure nftables NAT. Docker networks still function for inter-container communication, but host publishing requires your explicit forwarding rules.

For production GPU clusters running inference APIs, this tradeoff is worth it. You control exactly which ports are exposed and to whom. A single nftables ruleset governs all traffic — no hidden Docker rules bypassing your firewall.

Verification

Test the block:

# From outside the host
curl http://<host-ip>:8080
# Should fail if no DNAT rule exists

Add the DNAT rule, reload nftables, and retry. The request should reach the container.

Check your ruleset matches what you expect:

sudo nft list ruleset

Verify Docker didn't sneak in iptables rules:

sudo iptables-legacy -t nat -L DOCKER
# Should be empty or show "Chain DOCKER (0 references)"

If Docker re-created rules, it means daemon.json wasn't applied. Restart the daemon and double-check the JSON syntax.

Use Cases for Manual Firewall Control

This pattern matters when:

Running inference APIs on GPU instances where accidental exposure costs money and leaks proprietary models
Operating multi-tenant platforms where container isolation must be firewall-enforced, not just network-namespace-enforced
Deploying internal RAG pipelines with vector databases that should never touch the public internet
Meeting compliance requirements that demand explicit, auditable firewall rules for all published services

Docker's automatic iptables manipulation is convenient for development. In production infrastructure, convenience is a security liability. You need deterministic control over which packets reach which containers.

Originally published at fivenineslab.com