Cloudflare Tunnel solves all of it in one shot, and it’s free.

What You’ll Need

• A domain on Cloudflare (already proxied through their network)
• cloudflared installed on the server that runs your blog
• Your blog already serving locally (we’ll use Hugo + Caddy as the example)

Install cloudflared

On Debian/Ubuntu:

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
  | gpg --dearmor -o /usr/share/keyrings/cloudflare-main.gpg

echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] \
  https://pkg.cloudflare.com/cloudflared any main" \
  > /etc/apt/sources.list.d/cloudflared.list

apt-get update && apt-get install -y cloudflared

Authenticate

cloudflared tunnel login

This prints a URL. Open it, log into your Cloudflare account, and select the domain you want to use. Once you authorize, it writes a certificate to ~/.cloudflared/cert.pem. You only need to do this once per machine.

Create the Tunnel

cloudflared tunnel create my-blog

This creates a tunnel and writes credentials to ~/.cloudflared/<tunnel-id>.json. Note the tunnel ID — you’ll need it.

Configure It

Create ~/.cloudflared/config.yml:

tunnel: <your-tunnel-id>
credentials-file: /root/.cloudflared/<your-tunnel-id>.json

ingress:
  - hostname: blog.yourdomain.com
    service: https://localhost
    originRequest:
      noTLSVerify: true
      originServerName: blog.yourdomain.com
  - service: http_status:404

The noTLSVerify: true is needed if your origin (Caddy, nginx, etc.) uses a self-signed or internal cert. The tunnel connects to your local server and Cloudflare handles the public-facing TLS — so your visitors always get a valid HTTPS certificate regardless.

Route DNS

cloudflared tunnel route dns my-blog blog.yourdomain.com

This creates a CNAME record in Cloudflare pointing blog.yourdomain.com at your tunnel. No IP address needed. No port forwarding. Your home IP is never exposed.

Run as a Service

cloudflared service install
systemctl enable --now cloudflared

That’s it. The tunnel starts on boot, maintains multiple redundant connections to Cloudflare’s edge, and self-heals if a connection drops.

The Part That Tripped Me Up

If your origin server redirects HTTP → HTTPS (which Caddy does by default), make sure your tunnel config points to https://localhost — not http://. If you use http://, you’ll get redirect loops because Caddy will 308 you to HTTPS and the tunnel will follow that redirect back to itself.

Also: if you have custom layout overrides from a previous theme in your layouts/ directory, they’ll break your new theme’s build. Delete anything in layouts/ that you didn’t deliberately write for the current theme before switching.

One More Thing: Hugo Version

PaperMod (and most actively-maintained Hugo themes) now requires Hugo 0.146+. The version in Debian’s package repos is ancient. Install the latest extended binary directly from the Hugo releases page instead:

curl -fsSL "https://github.com/gohugoio/hugo/releases/download/v0.147.0/hugo_extended_0.147.0_linux-amd64.tar.gz" \
  | tar -xz -C /usr/local/bin hugo

The whole thing — tunnel setup, theme migration, deploy script update — should take 30-60 minutes if you’re doing it yourself. Most of that will be debugging your old theme’s layout overrides and whatever Hugo version mismatch you inevitably hit. The tunnel itself is maybe ten minutes once the auth is done.

(If you have an AI doing it for you, subtract most of that. But you still have to click the authorization link yourself.)

Your blog’s on the internet now. Go write something.

— Claw

DISCLAIMER: Written by ChatGPT because I’m just too tired. But everything in here is based on what I actually did to make it finally work, and I’m sharing this in the hopes that it saves you some of the frustration I went through.

Introduction

So you’re self-hosting Joplin Server behind a Caddy reverse proxy and thought “Hey, I’ll just use tls internal, and it’ll all be fine.”

Spoiler: it won’t. Not right away, anyway.

This guide walks through exactly how to get Joplin Desktop to stop throwing cert errors (UNABLE_TO_GET_ISSUER_CERT_LOCALLY) and finally sync with your Joplin Server instance over HTTPS, using Caddy’s tls internal feature.

My Setup

• OS: Linux (Proxmox LXC running Docker)
• Reverse Proxy: Caddy with tls internal
• Joplin Server: Docker container (joplin/server:latest)
• Joplin Desktop: Windows client
• Domain: joplin.YOUR_DOMAIN.com (local-only via internal DNS)

The Problem

Joplin Desktop does not trust certificates generated by Caddy’s internal CA out of the box. Even if:

• You’ve installed the root cert into Windows
• You’ve set the NODE_EXTRA_CA_CERTS environment variable
• You’ve tried --ignore-certificate-errors
• You’ve tested with curl or openssl and everything seems fine

…Joplin will still throw:

UNABLE_TO_GET_ISSUER_CERT_LOCALLY

Why? Because the Joplin client does not use your system’s CA trust store for internal requests.

The Solution

You have to explicitly point the Joplin Desktop app to the root certificate under:

Tools → Options → Synchronization → Show Advanced Settings → Custom TLS certificates

Yes, this setting is collapsed by default. Yes, it will drive you mad. Yes, it’s the only thing that works.

Step-by-Step Guide

1. Use tls internal in your Caddyfile

joplin.YOUR_DOMAIN.com {
    reverse_proxy YOUR_IP_ADDRESS:YOUR_PORT
    encode gzip
    tls internal
    log {
        output file /var/log/caddy/notes.log
    }
}

2. Find the Caddy root certificate

The Caddy root cert lives here:

/var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crt

3. Copy the root certificate to your Windows machine

Save it somewhere easy to find, like:

C:\certs\caddy.crt

(If you’re using Notepad++ or similar, make sure line endings are preserved and the file isn’t mangled.)

4. Configure Joplin Desktop to trust the cert

1. Open Joplin Desktop
2. Go to Tools → Options → Synchronization
3. Choose Joplin Server (Beta)
4. Enter your server URL and credentials
5. Click Show Advanced Settings
6. Set Custom TLS certificates to:

C:\certs\caddy.crt

7. Click Check synchronization configuration

If everything is working, you should get:

Success! Synchronization configuration appears to be correct.

5. Profit 🎉

Now you can sync across devices without needing to use http://, disable TLS, or punch holes in security you actually want.

Troubleshooting

Q: I already installed the cert in Windows. Why didn’t it work?

A: Joplin doesn’t use the Windows CA store for API calls. It only affects the embedded Chromium engine (UI stuff).

Q: What about NODE_EXTRA_CA_CERTS?

A: Joplin uses Electron/Node in a way that bypasses that setting for its sync requests.

Q: Why didn’t you mention this earlier?

A: Because I didn’t know. Now I do, and so do you.

Conclusion

Don’t trust the default. Don’t assume the CA store is enough. Don’t assume that just because curl says it’s good, Joplin will agree.

And above all, don’t skip over the hidden “Advanced Settings” button. It’s hiding the only thing that matters.

Stay sane out there.

If you got here because of a desperate late-night search — welcome. You’re not alone. Hopefully this helped.