DEV Community: the bomber

Connecting a Netlify Function to a Home Server via a Cloudflare Tunnel

the bomber — Sun, 11 Oct 2026 12:21:54 +0000

Why I needed a tunnel

I run a small home automation server on my personal network. It hosts a few Node.js services that expose a JSON API for my smart lights, a webhook endpoint for a contact form, and a simple status page. I wanted to call those endpoints from a Netlify site without exposing my home IP directly. Cloudflare's quick tunnel (formerly Argo Tunnel) gives me a public HTTPS URL that forwards traffic to a local port, but the URL changes each time the tunnel restarts. The article walks through the exact steps I used to keep a Netlify function in sync with that changing address.

1. Install and configure `cloudflared`

On my home machine (Ubuntu 22.04) I installed the Cloudflare daemon:

# Download the latest binary
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb

Next I logged into Cloudflare and created a tunnel token that only allows me to start a tunnel for a specific hostname:

cloudflared tunnel login   # opens a browser, stores a cert in ~/.cloudflared
cloudflared tunnel create home-tunnel
# The command prints a tunnel ID, e.g. 12345678-90ab-cdef-1234-567890abcdef

I then wrote a small config.yml that points the tunnel at the local service running on port 3000:

# ~/.cloudflared/config.yml
url: http://localhost:3000
tunnel: 12345678-90ab-cdef-1234-567890abcdef
credentials-file: /home/kaleb/.cloudflared/12345678-90ab-cdef-1234-567890abcdef.json

Running the tunnel is as simple as:

cloudflared tunnel run home-tunnel &

When it starts, Cloudflare prints a public URL, for example https://my-home-tunnel-abcdef.cloudflareteam.com. That URL is what the Netlify function will call.

2. Capture the public URL automatically

Because the tunnel URL changes whenever the daemon restarts (e.g., after a reboot), I needed a reliable way to surface the current address to Netlify. Cloudflare provides a metrics endpoint that returns the tunnel information in JSON:

curl -s http://localhost:8787/api/tunnels | jq -r '.tunnels[0].public_url'

cloudflared exposes this metrics endpoint on port 8787 by default. I wrapped the call in a tiny script that writes the URL to a file:

#!/usr/bin/env bash
# fetch-tunnel-url.sh
URL=$(curl -s http://localhost:8787/api/tunnels | jq -r '.tunnels[0].public_url')
if [ -n "$URL" ]; then
  echo "$URL" > /home/kaleb/.cloudflared/current-url.txt
fi

I set up a systemd timer to run this script every minute, ensuring the file always contains the latest URL.

3. Push the URL to Netlify as an environment variable

Netlify lets you store environment variables per site. I created a variable called HOME_TUNNEL_URL and marked it as secret. To keep it up‑to‑date I used Netlify's Deploy Hook API. The script reads the URL from the file and sends a PATCH request:

#!/usr/bin/env bash
# update-netlify.sh
TOKEN="${NETLIFY_PERSONAL_TOKEN}"   # stored as a secret on the home machine
SITE_ID="${NETLIFY_SITE_ID}"        # also a secret
URL=$(cat /home/kaleb/.cloudflared/current-url.txt)
if [ -z "$URL" ]; then exit 1; fi
curl -X PATCH "https://api.netlify.com/api/v1/sites/$SITE_ID" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"build_settings\":{\"environment\":{\"HOME_TUNNEL_URL\":\"$URL\"}}}"

I added another systemd timer that runs this script shortly after the fetch script. The two timers together make sure Netlify always sees the current tunnel address.

4. Netlify function that talks to the home server

With the URL available as an environment variable, the function code is straightforward. I used a Node.js function placed in netlify/functions/proxy.js:

// netlify/functions/proxy.js
const fetch = require('node-fetch');

exports.handler = async (event, context) => {
  const base = process.env.HOME_TUNNEL_URL; // injected by Netlify at build time
  if (!base) {
    return { statusCode: 500, body: 'Tunnel URL not configured' };
  }

  // Forward the request path and query string to the home server
  const target = `${base}${event.path}${event.rawQuery ? `?${event.rawQuery}` : ''}`;
  try {
    const resp = await fetch(target, {
      method: event.httpMethod,
      headers: event.headers,
      body: event.body,
    });
    const data = await resp.text();
    return {
      statusCode: resp.status,
      headers: Object.fromEntries(resp.headers.entries()),
      body: data,
    };
  } catch (err) {
    console.error('Proxy error:', err);
    return { statusCode: 502, body: 'Bad gateway' };
  }
};

The function simply proxies whatever path it receives to the home server. Because Netlify injects HOME_TUNNEL_URL at build time, the function always uses the most recent address.

5. Keeping the build up‑to‑date

Netlify only re‑reads environment variables when a new build is triggered. To avoid manual redeploys, I added a build hook that Netlify calls after the environment variable is updated. The update-netlify.sh script ends with a second request that triggers a deploy:

# Trigger a new deploy so the function sees the new URL
curl -X POST "https://api.netlify.com/api/v1/sites/$SITE_ID/builds" \
  -H "Authorization: Bearer $TOKEN"

The extra request costs a few seconds but guarantees the function runs with the correct URL.

6. What went wrong and how I fixed it

Tunnel URL not ready – The metrics endpoint sometimes returns an empty array right after a restart. I added a small retry loop (max 5 attempts, 2 s delay) before writing the file.
Rate limits on Netlify API – The API allows a few calls per minute. My timers run every minute, which stays safely under the limit.
SSL verification – Cloudflare issues a valid certificate for the tunnel hostname, so the function can call it over HTTPS without extra configuration.

7. Summary of the workflow

Install cloudflared and create a tunnel that points at the local service.
Run a script that reads the public URL from the metrics endpoint and stores it locally.
Push that URL to Netlify as an environment variable using the Netlify API.
Trigger a new Netlify build so the function picks up the updated variable.
In the Netlify function, read process.env.HOME_TUNNEL_URL and proxy the request.

All of this runs on my home machine, requires no external hosting, and works even when the tunnel address changes.

I build sites and automations for small businesses at dreamfuturestech.com.

Securing Netlify to Home Server Webhooks with HMAC and Timestamps

the bomber — Sun, 11 Oct 2026 04:55:28 +0000

Hi, I'm Kaleb. I build sites and automations for small businesses out of Pompano Beach, Florida, through Dream Futures Tech. Recently, I wired my own Netlify-hosted site so its chat widget can reach the server that runs my business automations at home. To route traffic safely without opening up random inbound ports, I used a Cloudflare Tunnel. But exposing an HTTP endpoint—even securely tunneled—means anyone on the internet can spam your server if they guess the URL.

To lock this down, I implemented request signing using HMAC-SHA256 and a strict timestamp check. If you are pushing webhooks from a static host or serverless environment like Netlify to an on-premise or home server, here is how I set it up without overcomplicating it.

The Problem with Unsigned Webhooks

When a Netlify function triggers an external webhook, it is just an HTTP POST request. Without verification, two bad things can happen:

Spoofing: Anyone who finds your webhook URL can send fake payloads.
Replay Attacks: An attacker can capture a legitimate payload in transit and replay it a hundred times to mess with your database or trigger duplicate automations.

To fix this, the sender (Netlify) needs to sign the payload using a shared secret key, and the receiver (your home server) needs to verify that signature. Adding a timestamp prevents old requests from being processed.

Signing the Payload on Netlify

Inside my Netlify serverless function (Node.js), I generate a current timestamp, build a message string combining the body and the timestamp, and hash it with a shared secret stored in Netlify's environment variables.

const crypto = require('crypto');

exports.handler = async function(event) {
  if (event.httpMethod !== 'POST') {
    return { statusCode: 405, body: 'Method Not Allowed' };
  }

  const secret = process.env.WEBHOOK_SECRET;
  const timestamp = Math.floor(Date.now() / 1000);
  const body = event.body;

  // Construct the payload message to sign
  const message = `${timestamp}.${body}`;
  const signature = crypto
    .createHmac('sha256', secret)
    .update(message)
    .digest('hex');

  try {
    const response = await fetch('https://your-home-server.duckdns.org/webhook', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'X-Signature': signature,
        'X-Timestamp': timestamp.toString()
      },
      body: body
    });

    if (!response.ok) {
      throw new Error(`Server responded with ${response.status}`);
    }

    return { statusCode: 200, body: JSON.stringify({ success: true }) };
  } catch (error) {
    return { statusCode: 500, body: JSON.stringify({ error: error.message }) };
  }
};

I prefer prepending the timestamp directly to the body string inside the hash. That way, an attacker cannot swap out the timestamp header while keeping an old body, because the signature won't match.

Verifying the Signature on the Home Server

On the receiving end—in my case, a small Express service on my home machine—I intercept the request, check the timestamp window, and re-compute the HMAC to compare against the incoming signature.

I set a strict tolerance window of 300 seconds (5 minutes). If the timestamp is older than that, the request gets dropped.

const express = require('express');
const crypto = require('crypto');
const app = express();

// We need raw body to accurately verify the HMAC signature
app.use(express.json({
  verify: (req, res, buf) => {
    req.rawBody = buf;
  }
}));

const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;
const TOLERANCE_SECONDS = 300;

app.post('/webhook', (req, res) => {
  const signature = req.headers['x-signature'];
  const timestamp = req.headers['x-timestamp'];

  if (!signature || !timestamp) {
    return res.status(401).send('Missing security headers');
  }

  // Check timestamp to prevent replay attacks
  const now = Math.floor(Date.now() / 1000);
  if (Math.abs(now - parseInt(timestamp, 10)) > TOLERANCE_SECONDS) {
    return res.status(401).send('Timestamp outside acceptable window');
  }

  // Re-create the signature using the raw body
  const message = `${timestamp}.${req.rawBody.toString('utf8')}`;
  const expectedSignature = crypto
    .createHmac('sha256', WEBHOOK_SECRET)
    .update(message)
    .digest('hex');

  // Use timing-safe comparison to prevent timing attacks
  const signatureBuffer = Buffer.from(signature, 'hex');
  const expectedBuffer = Buffer.from(expectedSignature, 'hex');

  if (
    signatureBuffer.length !== expectedBuffer.length ||
    !crypto.timingSafeEqual(signatureBuffer, expectedBuffer)
  )
  {
    return res.status(403).send('Invalid signature');
  }

  // Process your webhook payload safely here
  console.log('Valid webhook received:', req.body);
  res.status(200).send('Received');
});

app.listen(3000, () => console.log('Webhook listener up on port 3000'));

A quick gotcha: make sure you use express.json with a verify function to capture the raw buffer. If Express parses and re-serializes the JSON body, whitespace changes can break the HMAC calculation, resulting in signature mismatches.

Edge Cases and Local Testing

When testing this locally before pushing to production, use netlify dev to run your serverless functions locally, and point your home server or a local script at it. If your home server is behind a dynamic IP, using a tunnel provider eliminates DNS propagation delays during testing.

In my experience, this setup strikes a great balance. It requires zero expensive third-party queue services, keeps your home network hidden behind a secure tunnel, and takes less than an hour to write.