diff --git a/docs.json b/docs.json
index 5b8011e..de2c854 100644
--- a/docs.json
+++ b/docs.json
@@ -55,9 +55,10 @@
                                         "pages": [
                                             "manage/resources/public/authentication",
                                             "manage/resources/public/targets",
+                                            "manage/resources/public/wildcard-resources",
+                                            "manage/resources/public/healthchecks-failover",
                                             "manage/resources/public/raw-resources",
-                                            "manage/resources/public/maintenance",
-                                            "manage/resources/public/healthchecks-failover"
+                                            "manage/resources/public/maintenance"
                                         ]
                                     },
                                     {
diff --git a/manage/resources/public/wildcard-resources.mdx b/manage/resources/public/wildcard-resources.mdx
new file mode 100644
index 0000000..ab259aa
--- /dev/null
+++ b/manage/resources/public/wildcard-resources.mdx
@@ -0,0 +1,34 @@
+---
+title: "Wildcard Resources"
+description: "Route every hostname at a subdomain level through one public resource"
+---
+
+import PangolinCloudTocCta from "/snippets/pangolin-cloud-toc-cta.mdx";
+
+<PangolinCloudTocCta />
+
+With a wildcard public resource, one resource owns an entire subdomain level: every hostname under that level is proxied through the same Pangolin resource and tunnel so downstream systems can route further (for example another reverse proxy or Kubernetes ingress).
+
+Access rules and authentication you set on that resource apply to all hostnames matched by the wildcard. If you enable a PIN code, every hostname under the wildcard requires that PIN.
+
+## Creating a Wildcard Resource
+
+In the resource’s domain settings, set the subdomain field to `*` to match any label at that level. You can combine this with a parent subdomain, such as `*.apps`, so only hostnames under `apps` are covered, as long as TLS and DNS cover that same scope.
+
+The downstream target still receives the original `Host` header, so virtual hosts and path rules on your side keep working.
+
+## Requirements for Wildcard Resources
+
+Wildcard hostnames need TLS certificates that cover `*.your-level`, not just a single FQDN, and DNS must send all of those names to Pangolin. How you satisfy that depends on how you host Pangolin.
+
+### Self-hosted Pangolin
+
+You must issue a wildcard certificate using DNS validation (DNS-01). HTTP-01 challenges prove one exact hostname at a time; they cannot obtain a certificate for `*.example.com`. DNS-01 proves control of the DNS zone, which is what certificate authorities require for wildcard coverage, otherwise Pangolin could not terminate HTTPS for arbitrary subdomains at that label.
+
+Configure Traefik / Let’s Encrypt for DNS-01 and wildcard certs as described in [Wildcard domains](/self-host/advanced/wild-card-domains).
+
+You also need DNS records so every name at that level resolves to your Pangolin server, for example an A record for `*.subdomain`. See [Domains](/manage/domains#for-wildcard-domains) for typical wildcard DNS patterns.
+
+### Pangolin Cloud
+
+Use a [domain delegation](/manage/domains#domain-delegation-ns-records) (NS record) domain so Pangolin controls DNS at the delegated zone. That delegation lets Pangolin issue and renew wildcard certificates for that level and ensures queries for `*.your-delegated-zone` route to Pangolin. Pangolin Cloud manages the certificates for you once delegation is in place.
\ No newline at end of file