Community examples
Start with the tested first-app Caddyfile or a provider's canonical example. For additional patterns, Eric Zimmerman's community writeup covers home services and mobile clients using Basic/API-key authentication.
That writeup describes a specific older deployment, not a versioned test suite for the current release. In particular, use the released API-key guidance and Basic authentication requirements, including the realm header and trusted route boundary, rather than copying its old key length workaround or treating custom header names as an access policy.
Before adopting any community configuration, identify its module/library versions, replace hostnames and credentials, validate the grammar and test both an authorized user and a signed-in nonmember. Optional modules, TLS/DNS setup and application-specific APIs require their own verification. Keep private keys and account data outside the file-server root.
Choose the evidence before copying an example
A useful topology idea is separate from proof that its syntax and runtime behavior match your deployment.
| Starting point | Useful for | Required follow-up |
|---|---|---|
| Canonical example in this site | A complete configuration with stated version and environment | Replace demo values; adapt with your executable; test allow and deny |
| Upstream fixture or example | Inspect parser, host integration, and expected behavior | Check its source revision and actual fixture coverage |
| Community write-up | Understand another deployment’s topology and choices | Verify date, versions, grammar, keys, callbacks, and backend boundary |
| Provider console screenshot | Locate a corresponding setup concept | Follow current official field names and your exact public callback |
Agentic Prompts
Copy a prompt into your LLM to explore this topic. Each prompt prioritizes upstream repository guidance and code over this page, and asks for version-aware reasoning.
Evaluate a community example
Help me understand Community examples.
Primary authorities (take precedence over website documentation):
https://github.com/greenpau/caddy-security/blob/main/AGENTS.md
https://github.com/greenpau/caddy-security/tree/main/.codex/skills
https://github.com/greenpau/go-authcrunch/blob/main/AGENTS.md
https://github.com/greenpau/go-authcrunch/tree/main/.codex/skills
Read each repository's root AGENTS.md first, then any scoped AGENTS.md that
applies to inspected paths. Read the relevant SKILL.md files and follow their
implementation and test references.
Relevant skills to locate: configuration, configuration-http-integrations,
testing-and-ci.
Secondary reference:
https://docs.authcrunch.com/docs/examples/intro
If a source is inaccessible, ask me to paste its relevant text. Identify the
versions your answer applies to; main may be newer than my release. Resolve
disagreements using code and tests, and flag unverified claims. Use synthetic
credentials and redacted examples; explain proposed checks before any changes.
Help me review an example’s publication date, actual AuthCrunch/Caddy
versions, provider assumptions, and configuration grammar. Compare it with
current upstream examples and my installed release. Preserve useful topology
ideas while identifying statements that need runtime evidence rather than
assuming a tutorial is a maintained test.
Adapt the topology deliberately
Help me understand Community examples.
Primary authorities (take precedence over website documentation):
https://github.com/greenpau/caddy-security/blob/main/AGENTS.md
https://github.com/greenpau/caddy-security/tree/main/.codex/skills
https://github.com/greenpau/go-authcrunch/blob/main/AGENTS.md
https://github.com/greenpau/go-authcrunch/tree/main/.codex/skills
Read each repository's root AGENTS.md first, then any scoped AGENTS.md that
applies to inspected paths. Read the relevant SKILL.md files and follow their
implementation and test references.
Relevant skills to locate: configuration, configuration-http-integrations,
testing-and-ci.
Secondary reference:
https://docs.authcrunch.com/docs/examples/intro
If a source is inaccessible, ask me to paste its relevant text. Identify the
versions your answer applies to; main may be newer than my release. Resolve
disagreements using code and tests, and flag unverified claims. Use synthetic
credentials and redacted examples; explain proposed checks before any changes.
Ask about public hostnames, HTTPS termination, portal mount, callback URLs,
app paths, and backend reachability. Map these onto a synthetic example and
explain which cookie, login URL, and route-order settings must agree. Do not
merely replace a hostname throughout an older configuration.
Inspect the access boundary
Help me understand Community examples.
Primary authorities (take precedence over website documentation):
https://github.com/greenpau/caddy-security/blob/main/AGENTS.md
https://github.com/greenpau/caddy-security/tree/main/.codex/skills
https://github.com/greenpau/go-authcrunch/blob/main/AGENTS.md
https://github.com/greenpau/go-authcrunch/tree/main/.codex/skills
Read each repository's root AGENTS.md first, then any scoped AGENTS.md that
applies to inspected paths. Read the relevant SKILL.md files and follow their
implementation and test references.
Relevant skills to locate: configuration, configuration-http-integrations,
testing-and-ci.
Secondary reference:
https://docs.authcrunch.com/docs/examples/intro
If a source is inaccessible, ask me to paste its relevant text. Identify the
versions your answer applies to; main may be newer than my release. Resolve
disagreements using code and tests, and flag unverified claims. Use synthetic
credentials and redacted examples; explain proposed checks before any changes.
Review an example’s role transforms, policy rules, factor evidence, and
trusted headers. Explain what the issuer guarantees and what the application
policy must enforce. Design anonymous, allowed, nonmember, wrong-method,
sibling-path, and direct-backend cases before calling the deployment
protected.
Check claims and modules before copying fixes
Help me understand Community examples.
Primary authorities (take precedence over website documentation):
https://github.com/greenpau/caddy-security/blob/main/AGENTS.md
https://github.com/greenpau/caddy-security/tree/main/.codex/skills
https://github.com/greenpau/go-authcrunch/blob/main/AGENTS.md
https://github.com/greenpau/go-authcrunch/tree/main/.codex/skills
Read each repository's root AGENTS.md first, then any scoped AGENTS.md that
applies to inspected paths. Read the relevant SKILL.md files and follow their
implementation and test references.
Relevant skills to locate: configuration, configuration-http-integrations,
testing-and-ci.
Secondary reference:
https://docs.authcrunch.com/docs/examples/intro
If a source is inaccessible, ask me to paste its relevant text. Identify the
versions your answer applies to; main may be newer than my release. Resolve
disagreements using code and tests, and flag unverified claims. Use synthetic
credentials and redacted examples; explain proposed checks before any changes.
Analyze an example that proposes a key-length workaround, custom identity
header, obsolete authp directive, or extra Caddy module. Verify the actual
parser/runtime support and cryptographic requirement for my version. Explain
why a header rename or successful adaptation is not proof of a working access
check.
Turn a write-up into evidence
Help me understand Community examples.
Primary authorities (take precedence over website documentation):
https://github.com/greenpau/caddy-security/blob/main/AGENTS.md
https://github.com/greenpau/caddy-security/tree/main/.codex/skills
https://github.com/greenpau/go-authcrunch/blob/main/AGENTS.md
https://github.com/greenpau/go-authcrunch/tree/main/.codex/skills
Read each repository's root AGENTS.md first, then any scoped AGENTS.md that
applies to inspected paths. Read the relevant SKILL.md files and follow their
implementation and test references.
Relevant skills to locate: configuration, configuration-http-integrations,
testing-and-ci.
Secondary reference:
https://docs.authcrunch.com/docs/examples/intro
If a source is inaccessible, ask me to paste its relevant text. Identify the
versions your answer applies to; main may be newer than my release. Resolve
disagreements using code and tests, and flag unverified claims. Use synthetic
credentials and redacted examples; explain proposed checks before any changes.
Build a short validation record containing source/version references, redacted
configuration, adaptation result, trusted-HTTPS login, denied-user result,
logout, and temporary-server cleanup. Separate fixture coverage from my
environment’s behavior. Ask for unresolved provider or network assumptions
instead of inventing passing results.
Source Code References
Start with the code search, then follow the parser, runtime, and tests relevant
to this topic. These links target main; use GitHub's branch/tag selector to
compare them with your installed release.
- Search this topic in both repositories — searches topic-specific symbols and paths across both codebases.
- caddy-security: assets/config/Caddyfile — provides an upstream configuration entry point with named security components and routes.
- caddy-security: caddyfile.go — registers global security configuration and route directive adapters.
- caddy-security: caddyfile_adapt_test.go — checks complete Caddyfile fixtures against expected adapted configuration.
- caddy-security: plugin_authn.go — mounts the portal in Caddy and delegates HTTP requests.
- caddy-security: plugin_authorization.go — preserves handled responses and applies authorized identity in the Caddy handler chain.
- go-authcrunch: config.go — validates the library configuration graph and named components.