TLSDNSDeployment

Practical TLS and DNS Setup for Hundreds of Micro‑Apps on a Single Domain

sselfhosting

2026-02-14

10 min read

Practical blueprint to host hundreds of micro‑apps on one domain: wildcard certs, SNI, DNS‑01 automation, TTL and rate‑limit strategies for 2026.

Scaling TLS and DNS for hundreds of micro‑apps on one domain — practical, production-ready patterns

Hook: You’re running dozens or hundreds of tiny self‑hosted web apps and the DNS/TLS chaos is eating your time: rate limits, certificate churn, slow DNS propagation, and brittle path rewrites. This guide gives a pragmatic blueprint (configs, tools, and operational rules) to host many micro‑apps under a single apex domain in 2026 without hitting Let's Encrypt limits, breaking SNI, or overloading your DNS provider.

Key takeaway (read first)

Use a wildcard certificate + one apex SAN cert for most deployments to avoid per‑subdomain rate limits.
Prefer SNI-aware reverse proxies (Traefik, Caddy, NGINX, Envoy) and DNS‑01 automation for scale.
Tune DNS TTL and stagger certificate operations to stay inside ACME limits; consider an internal CA for high churn.

Why this matters in 2026 — trends and context

By 2026 the micro‑app wave (apps created rapidly by small teams or individuals) has increased the number of ephemeral services per domain. Enterprises and hobbyists alike deploy hundreds of single‑purpose apps: analytics dashboards, bots, micro‑frontends, and private dev portals. Simultaneously, TLS best practices consolidated around TLS 1.3, SNI everywhere, and automated ACME issuance. That combo makes it possible — but also easier to trip over rate limits, DNS provider quotas, and application assumptions about root paths.

Design for automation, not for manual certificates. Automation is the only way to keep hundreds of micro‑apps secure and maintainable.

High‑level architecture options

There are three practical patterns for hosting many micro‑apps under one apex domain. Choose based on complexity, app assumptions, and operational constraints.

1) Subdomains (recommended for scale)

Architecture: app1.example.com, app2.example.com, … Served via a single reverse proxy that routes by Host header. Use wildcard cert(s) and DNS with a wildcard A/AAAA pointing at your load balancer/proxy.

Pros: clean isolation, cookies scoped per subdomain, fewer rewrite issues.
Cons: requires wildcard cert (DNS‑01), and can hit CA rate limits if mismanaged.

2) Subpaths (single origin certificate)

Architecture: example.com/app1, example.com/app2. Reverse proxy rewrites and forwards. A single certificate covers the apex and paths.

Pros: no wildcard cert needed, minimal DNS churn, fewer ACME calls.
Cons: apps must be path‑aware (base href, cookie paths), websockets and CORS require careful proxying.

3) Hybrid: wildcard for subdomains + path for shared apps

Use wildcard for many independent micro‑apps and subpaths for centralized UIs (dashboard, landing pages). This balance reduces ACME calls while keeping developer ergonomics.

Wildcards, SANs and SNI — when to use what

Wildcard certificates (covers *.example.com) are the most scalable choice for hundreds of subdomains. They prevent per‑hostname issuance and avoid many ACME rate limits, but remember a wildcard does not include the apex (example.com). Create one SAN that includes the apex and your wildcard name.

SAN (Subject Alternative Name) certs are an alternative when you only have a finite known set of hostnames. But adding SANs dynamically at scale is operationally heavy: every time you add a host you must reissue the cert (watch rate limits).

SNI is how servers present per‑host certificates over a single IP. By 2026 SNI support is universal on modern clients, so per‑subdomain certs on the same IP are viable — but each distinct certificate still invokes ACME operations if you automate with Let's Encrypt.

Let's Encrypt and rate limits — practical mitigations

Let's Encrypt remains the de‑facto free CA. But the ACME API enforces limits (duplicate certificate, new‑order, failed validation) that can hurt high‑churn environments. Here’s how to avoid hitting them:

Default to a wildcard cert with DNS‑01 validation so adding new subdomains doesn’t require new orders.
Reuse ACME accounts and keys across your fleet — creating unique accounts per micro‑app multiplies the limit surface.
Stagger issuance — schedule bulk provisioning in waves instead of hundreds of simultaneous requests.
Use CA diversity if you need many SANs quickly: combine Let's Encrypt with a commercial CA or an internal CA (see below) to spread risk.
Use staging for tests (Let’s Encrypt staging) and monitor failed validation limits.
Fallback to internal CA (e.g., small PKI using step‑ca, Vault PKI, or a private ACME server) for extremely high churn or inner‑network apps.

When to run your own CA

If you auto‑create and destroy thousands of hostnames per day, a public CA is not a fit. Use an internal CA for internal apps and mTLS. For externally reachable services you’ll still want public trust; consider short‑lived public certs for externally visible endpoints and internal certs for ephemeral ones.

DNS strategies: wildcard records, delegation, and TTLs

DNS is both a performance and an operational boundary. For hundreds of micro‑apps, DNS choices reduce friction.

Wildcard records and a single A/AAAA

Set *.example.com A/AAAA records pointed at your load balancer/proxy. This lets you add a subdomain at the proxy level without creating DNS records per app. Pros: minimal DNS churn; Cons: you lose per‑app DNS control unless you also implement NS delegation.

Delegation for multi‑tenant zones

When you want different teams to manage subsets (e.g., clientA.example.com), use NS records to delegate subzones. This scales administrative control and isolates DNS rate limits between teams.

DNS TTL policy (practical defaults)

During migrations: use low TTL like 60s to 120s but only briefly.
Normal production: 300–3600s (5m–1h). 300s is a common balance for responsiveness and caching cost.
Wildcard records: 300s is reasonable. Very low TTLs on wildcards increase query load dramatically.
Monitor provider rate limits — some managed DNS providers throttle API and DNS queries; plan your TTL accordingly.

Automating certificates — tools, config examples, and best practices

Pick tooling that fits your stack: ephemeral VMs vs Kubernetes vs a single reverse proxy node. Below are battle‑tested options with config snippets you can adapt.

Caddy: simplest for wildcard + DNS providers

Caddy is a great all‑in‑one option. It handles ACME with DNS‑01 using provider plugins and requires minimal config.

# Caddyfile example (DNS provider plugin required)
example.com, *.example.com {
  reverse_proxy /* localhost:8080
}

Set environment variables for your DNS provider API keys (Cloudflare, AWS Route53, Hetzner, etc.) and Caddy will request the wildcard cert and manage renewals automatically.

Traefik: dynamic routing at scale (K8s or Docker)

Traefik integrates ACME, can store certs in a shared storage (volume, Kubernetes secret), and supports dynamic routers.

# Static config (yaml) excerpt for ACME DNS
certificatesResolvers.le.acme.dnsChallenge.provider: cloudflare
certificatesResolvers.le.acme.email: admin@example.com
certificatesResolvers.le.acme.storage: /acme/acme.json

Give Traefik a wildcard certificate via DNS‑01 and point all subdomains at Traefik. Use routers by Host(`{subdomain}.example.com`).

NGINX + certbot + DNS API

NGINX is reliable for path rewrites and performance. Use certbot with DNS API plugins (certbot‑dns‑cloudflare, certbot‑dns‑route53, etc.) to automate DNS‑01 wildcard issuance.

# Certbot example (Cloudflare plugin)
certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/cloudflare.ini -d "example.com" -d "*.example.com"

Kubernetes: cert-manager with ClusterIssuer

# ClusterIssuer for Let's Encrypt (DNS01 via Cloudflare)
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: le-account-key
    solvers:
      - dns01:
          cloudflare:
            email: admin@example.com
            apiTokenSecretRef:
              name: cloudflare-api-token
              key: token

Then create a Certificate resource for example.com + *.example.com. cert-manager will handle renewals and store certs in Secrets that your Ingress controller (Traefik/NGINX Ingress) can consume.

Operational checklist — day‑to‑day rules

Use a wildcard + apex SAN where possible to minimize ACME orders.
Reuse ACME account keys across systems; store them securely (KMS or HSM).
Batch certificate operations and stagger onboarding of new services.
Monitor certificate expiry and ACME errors (certbot/Traefik/cert‑manager logs and metrics).
Set DNS TTLs to moderate values and only lower them during planned migrations.
Implement a fallback path: if public CAs fail due to rate limits, have an internal CA to issue temporary certs and a process to swap to public certs later.
Enable OCSP stapling and TLS 1.3 on your edge to reduce latency and improve security.

Security hardening

Hosting many apps on one domain concentrates risk. Protect the edge:

Enforce strong TLS (TLS 1.3, modern ciphers). Use policy templates available in NGINX/Caddy/Traefik.
Enable HSTS and include subdomains only if every subdomain is ready (HSTS preloading is risky for large fleets).
Use per‑app authentication and network segmentation. Don’t rely on hostname isolation alone.
Guard your ACME account keys: store in KMS and restrict access.
Rotate wildcard keys on a schedule and after team changes.

Real‑world example: 300 micro‑apps on example.com

Below is a condensed case study of a production deployment pattern used by a small SaaS team in late 2025.

DNS: Cloudflare with a single wildcard A record (*.example.com) pointing to an autoscaling load balancer pool. TTL 300s.
Certificates: One wildcard + apex SAN requested via DNS‑01 with cert‑manager in Kubernetes. ACME account shared across clusters and stored in Vault; issuance is batched.
Reverse proxy: Traefik as Ingress, dynamic routing by host. Traefik consumes the certs from cert‑manager secrets. HTTP/3 and TLS 1.3 enabled at the edge.
Operational: New micro‑apps registered via an internal provisioning service that creates route entries in Traefik but doesn't touch DNS. Certificate churn reduced since wildcard covers the hostnames.
Fallback: step‑ca used for internal CI/testing to avoid hitting public CA limits during tests.

Common pitfalls and how to avoid them

Hitting duplicate certificate limits: Create fewer unique cert orders by using wildcards and reusing ACME accounts.
Apps breaking on subpaths: Use subdomains for apps that need root context, or adapt proxies to rewrite paths and adjust base hrefs in the app build.
DNS provider rate limits: Check provider API quotas and use wildcard records or delegation to reduce calls.
Stale DNS due to low TTLs: Avoid leaving very low TTLs in place; they increase query load and cost.

Advanced strategies (2026)

Newer patterns that matured in 2025–2026 worth evaluating:

ACME farms / internal ACME proxies: Run an internal ACME server that proxies to public CAs to centralize rate limiting and caching.
Edge TLS offload + origin mTLS: Use CDN/edge (Cloudflare, Fastly) with public TLS, and require mTLS between edge and origin for stronger authentication.
Short‑lived certs + automated rotation: Short cert lifetimes reduce blast radius. Automation tools now support cert lifetimes under the CA minimum for internal PKIs.
Policy‑driven certificate distribution: Declarative config (GitOps) that defines which apps get subdomains vs paths, with automated linting to prevent policy violations.

Actionable checklist — launch your scaled TLS/DNS setup

Decide: subdomain vs path vs hybrid for your app fleet.
Reserve a wildcard + apex SAN certificate using DNS‑01 with your DNS provider’s API.
Deploy a SNI‑capable reverse proxy (Caddy/Traefik/NGINX) and point *.example.com to it.
Automate issuance with cert‑manager / certbot / Caddy; store ACME keys securely.
Set DNS TTL to 300s for production; lower only during controlled migration windows.
Monitor ACME errors and certificate expiry; implement alerts.
Plan for fallback: internal CA or alternative public CA for spikes.

Closing thoughts

In 2026 the technical capability to host hundreds of micro‑apps under a single domain is mature, but the operational practices matter more than tooling. Favor wildcard certificates + DNS‑01 automation for scale, use SNI and modern TLS at the edge, and tune DNS TTLs and issuance schedules to respect provider and CA rate limits. Where public CAs don’t fit, supplement with an internal CA for nonpublic workloads.

These are practical, production‑tested patterns — try them in a staging environment, automate aggressively, and design your provisioning flows to minimize ACME calls.

Action — deploy a safe pattern today

Use the checklist above to stage a rollout: request a wildcard cert in a test account, point a wildcard DNS record at a test proxy, and onboard 5–10 micro‑apps using automation. Validate renewals, SNI behavior, and app compatibility with paths vs subdomains.

Call to action: Want a tailored plan for your environment? Share your stack (Kubernetes/Docker/VM), DNS provider, and expected churn and I’ll outline a hardened TLS/DNS blueprint you can deploy this week.

selfhosting

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.