wmantly
426fa111ec
- New docs/concepts-{hosts,dns,access,api-tokens}.md -- plain-language
guides aimed at less technical readers, each linking onward to the
existing system-design-level doc for anyone who wants that detail.
Card help links (Proxy List, Add/Edit host, DNS Provider cards,
Users/Permissions/Groups cards) now point here instead of straight at
Installation/Architecture.
- The "New API Token" card had no help link at all -- added, pointing to
the new API Tokens doc.
- Fixed the in-app docs viewer rendering every docs/*.md page with a
garbled heading + stray <hr> at the top: Jekyll front matter (meant
only for the GitHub Pages build) was never stripped before being
handed to the markdown renderer.
- Fixed cross-doc links never resolving in-app, since this viewer serves
docs at /docs/<slug> with no .html suffix: rewritten to the correct
in-app URL, first by registered slug, falling back to the doc's real
filename (the correct, working link form on the Jekyll/GitHub Pages
build) -- same idea as the existing image-path fix, and lets one link
written in a doc work on both targets.
Bumps to v1.1.13.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KDEx8ghuZR61pqPXc6da9C
2.0 KiB
layout, title, description
| layout | title | description |
|---|---|---|
| default | DNS Providers | A plain-language guide to why theta42/proxy needs a DNS provider, and only for wildcard certificates. |
DNS Providers
This page explains, in plain language, what a "DNS provider" is for in this app and when you actually need one. For setup steps, see Installation.
Do you need this at all?
Only if you want a wildcard host (something like
*.example.com covering every subdomain with one certificate). A normal,
single-name host doesn't need a DNS provider configured at all — skip this
page entirely if that's all you're setting up.
Why a wildcard cert needs this extra step
To prove you actually own example.com before issuing a certificate that
covers every possible subdomain of it, Let's Encrypt needs to see a
specific, temporary DNS record appear on that domain — something only the
real owner of the domain could add. A normal single-host certificate
doesn't need this because it can prove ownership a simpler way (by
responding to a web request instead).
So: to get a wildcard certificate, this app needs to be able to add (and later remove) that one temporary DNS record on your domain automatically, which means it needs your domain registrar or DNS host's API credentials — that's what registering a DNS provider here does.
What you're actually giving it access to
A DNS provider entry only needs enough access to add/remove TXT records — it's not given your registrar account's full login, and it can't do anything to your domain besides that one narrow task (and, for some providers, keeping a dynamic A record updated if you use that feature separately). Check your specific provider's page in the Installation guide for exactly what kind of credential to generate and how narrowly you can scope it.
Want more detail?
For exact setup steps per provider (Cloudflare, DigitalOcean, Porkbun, DuckDNS, etc.), see Installation.