LifeBytes Journal

If you build or demo web apps, you have probably fought with port forwarding, firewalls, or complicated reverse proxies. Tailscale’s Serve and Funnel features make this painless: Serve exposes your local service to your tailnet (only authenticated users in your Tailscale network), and Funnel optionally publishes it to the public internet with automatic HTTPS. This guide shows a step-by-step setup in minutes on Linux, with tips for macOS and Windows.

What you will set up

You will run a local app (for example, on http://localhost:3000) and expose it securely via Tailscale in two modes:

Tailnet-only (Serve): Only people signed into your tailnet can access it (ideal for internal testing).
Public (Funnel): Anyone on the internet can access a public HTTPS URL that Tailscale provisions for you (great for demos, webhooks, or sharing temporary previews).

Prerequisites

- A Tailscale account (free is fine for personal use).
- Tailscale installed and logged in on the computer that runs your app (Linux/macOS/Windows).
- Ability to turn on the “Funnel” feature in the Tailscale admin console (if you plan to go public).
- A local service running (e.g., a dev server on port 3000).

1) Install and log in to Tailscale

On Ubuntu/Debian, the quickest way is:

curl -fsSL https://tailscale.com/install.sh | sh

Then bring the node online and sign in:

sudo tailscale up

Verify you are connected:

tailscale status

On macOS and Windows, install the client from the Tailscale website, sign in, and ensure the device appears in your admin console.

2) Expose a local service to your tailnet (Serve)

Let’s assume your app runs at http://localhost:3000. Use Tailscale Serve to proxy HTTPS traffic from your device’s Tailscale HTTPS endpoint to your local port:

tailscale serve https / proxy http://localhost:3000

That command maps path / to your local app. Check the status of your Serve configuration:

tailscale serve status

Now open the tailnet URL printed by the command (usually something like https://<device-name>.<tailnet>.ts.net/). Only users/authenticated devices in your tailnet can access it. This is perfect for internal reviews without exposing anything publicly.

3) Make it public with HTTPS (Funnel)

To publish your service to the public internet, first enable the Funnel feature in the Tailscale admin console (Settings → Feature preview/Settings → Funnel, depending on your account). You can restrict which devices and ports are allowed to use Funnel.

Once enabled, turn on Funnel for HTTPS (port 443) on the device:

tailscale funnel 443 on

That’s it. Tailscale will automatically provision a valid TLS certificate and a public URL (again, typically https://<device-name>.<tailnet>.ts.net/). Share this link with anyone; they do not need Tailscale to view your app.

To turn Funnel off again:

tailscale funnel 443 off

4) Useful variations

- Serve a different path: tailscale serve https /app proxy http://localhost:5173
- Serve a TCP port to your tailnet (e.g., Postgres): tailscale serve tcp 5432 127.0.0.1:5432
- Reset all Serve mappings on this device: tailscale serve reset

5) Testing and verification checklist

- Local works: Browse http://localhost:3000.
- Tailnet works: From another device on your tailnet, open https://<device-name>.<tailnet>.ts.net/. You should see a valid HTTPS certificate and your app.
- Public works: After turning on Funnel, test from a device not logged into Tailscale (cellphone on LTE, for example). The same URL should load over HTTPS.

6) Security tips

- Prefer tailnet-only Serve during development. Switch on Funnel only when you actually need a public demo or webhook endpoint.
- If your app needs authentication, keep it enabled. Funnel does not add login by default; it only provides HTTPS and routing.
- Avoid exposing admin panels, databases, or file shares via Funnel. Keep those tailnet-only or behind application-level authentication.

7) Troubleshooting

“403: Funnel not allowed” — Ensure the Funnel feature is enabled for your tailnet in the admin console and that your device/port is permitted.
Port conflicts — If something else is bound to 443 on your device, stop it or remap your Serve path (e.g., Serve at /app) and still use Funnel on 443.
Blank page or mixed content — If your app hardcodes http:// asset URLs, fix them to be relative or https://.
Service not reachable — Confirm your local app responds at the target URL (e.g., curl http://localhost:3000). Then run tailscale serve status to confirm the mapping exists.

8) Keeping it tidy

- List current mappings: tailscale serve status
- Remove a specific route: change your mapping command or reset and re-apply.
- Keep Tailscale updated: use your OS package manager or reinstall via the install script periodically. Check your version with tailscale version.

Why this approach is great

You get automatic TLS, end-to-end encrypted transport, and a clean URL without touching DNS, firewalls, or port forwards. For internal stakeholders, Serve keeps traffic private to your tailnet. For public demos, Funnel gives you one command to go live, then one command to go dark. It’s a powerful quality-of-life upgrade for anyone who ships or supports web apps.

Overview

If you want to publish a self‑hosted service on the internet without opening ports on your router, Cloudflare Tunnel is a modern, zero‑trust solution. In this tutorial, you will deploy Cloudflare Tunnel with Docker, route a subdomain to a local container, and add single‑sign‑on (SSO) protection. This setup works well for homelabs and small businesses, is fast to roll out, and uses Cloudflare’s free plan.

Prerequisites

1) A domain added to Cloudflare (DNS managed by Cloudflare). 2) A Linux server or VM with internet access. 3) Docker and the Docker Compose plugin installed. 4) Basic command‑line access via SSH.

Step 1 — Install Docker and Compose

On Debian/Ubuntu, you can install from the OS repo for a quick start. For production, prefer Docker’s official repositories. Quick start example:

sudo apt update && sudo apt install -y docker.io docker-compose-plugin

Verify installation:

docker --version
docker compose version

Step 2 — Prepare a working directory

Create a project folder to keep tunnel files and your Compose file organized:

mkdir -p ~/cf-tunnel/cloudflared && cd ~/cf-tunnel

Step 3 — Create the Tunnel in Cloudflare

Open Cloudflare Dashboard > Zero Trust > Networks > Tunnels > Add a tunnel. Choose “Cloudflared” and give it a friendly name (for example, homelab-tunnel). After creation, click the tunnel and add a “Public Hostname.” Set Hostname to a subdomain like app.yourdomain.com, and Type to HTTP. For the service URL, use a local address you will run (for example, http://app:3000). Saving this will also create the DNS CNAME for you automatically.

In the same page, download the credentials file (a JSON file with your tunnel ID) and, if offered, the suggested config.yml. Save the JSON to ~/cf-tunnel/cloudflared/ and note the filename; it looks like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json.

Step 4 — Create cloudflared config.yml

If you did not download a config from the dashboard, create one now at ~/cf-tunnel/cloudflared/config.yml with the following content (replace placeholders):

tunnel: YOUR-TUNNEL-UUID
credentials-file: /etc/cloudflared/YOUR-TUNNEL-UUID.json

ingress:
  - hostname: app.yourdomain.com
    service: http://app:3000
  - service: http_status:404

This tells cloudflared to forward traffic for your subdomain to the local container named app on port 3000, and return a 404 for everything else.

Step 5 — Create a Docker Compose file

We will run a sample application and cloudflared in the same Docker network. Create ~/cf-tunnel/compose.yml with:

services:
  app:
    image: traefik/whoami:latest
    container_name: whoami
    expose:
     - "80"
    restart: unless-stopped

  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    command: tunnel --config /etc/cloudflared/config.yml run
    volumes:
     - ./cloudflared:/etc/cloudflared:ro
    depends_on:
     - app
    restart: unless-stopped

The app service is a tiny HTTP server used as a demo. Cloudflared reads your config and credentials from the mounted folder.

Step 6 — Start the stack and test

Run the following from ~/cf-tunnel:

docker compose up -d
docker logs -f cloudflared

When logs show “Connected to Cloudflare,” visit https://app.yourdomain.com. You should see a response from “whoami.” Use curl -I https://app.yourdomain.com to verify status 200 over HTTPS.

Optional — Add Zero Trust access

To protect your app with SSO, open Cloudflare Dashboard > Zero Trust > Access > Applications > Add an application > Self‑hosted. Set the application domain to app.yourdomain.com. Add a policy to “Allow” specific emails, domains, or identity providers (Google, GitHub, Azure AD). Save. Your app now prompts users to authenticate before reaching your origin.

Maintenance and updates

Update images periodically to receive security patches and performance improvements. Use:

docker compose pull && docker compose up -d

Because the tunnel runs outbound over HTTPS, you do not need to open inbound ports on your router. Keep your server’s system packages current and restrict SSH access with keys and a firewall.

Troubleshooting

502 Bad Gateway: Usually means cloudflared cannot reach your container. Confirm the service name and port in config.yml, ensure both containers share the same Docker network (Compose sets this by default), and that the app is listening on the correct port.

404 Not Found: If you have multiple hostnames, make sure the correct hostname entry exists in the ingress block and that it points to the right service. The last rule should be a 404 fallback.

DNS not resolving: In the Tunnel page, verify the “Public Hostname” exists and the DNS CNAME was created. If needed, create a CNAME for app.yourdomain.com pointing to YOUR-TUNNEL-UUID.cfargotunnel.com.

Authentication loop with Access: Clear cookies or add your domain to “Allowed Cookie Domains” in the Access app settings. Also confirm your policy “Allow” rules match your user identity.

Connectivity drops: Check server time (NTP), ensure no outbound firewall is blocking HTTPS to Cloudflare, and consider running two cloudflared replicas for high availability.

What you achieved

You deployed a secure reverse tunnel with Docker that exposes a local container to the internet under your own domain, without port forwarding or a public IP. You also learned how to enable Cloudflare Access as a zero‑trust layer for SSO and policy control. This pattern scales to multiple services by adding more ingress rules or additional public hostnames in the dashboard, making it a clean, maintainable approach to self‑hosting.