UsingMultipleDomainsIndexedLabels.md

Using Multiple Domains (Indexed Labels)

DockFlare allows you to expose multiple hostnames, potentially with different configurations (like target services or zones), from a single container. This is achieved using indexed labels.

Labeling Strategy

Instead of using simple labels like cloudflare.tunnel.hostname, you append an index number (starting from 0) before the key:

• cloudflare.tunnel.0.hostname
• cloudflare.tunnel.0.service
• cloudflare.tunnel.1.hostname
• cloudflare.tunnel.1.service
• etc.

Each index (0, 1, 2, ...) represents a distinct ingress rule configuration. You still need a single cloudflare.tunnel.enable="true" label to activate DockFlare for the container.

Important: Index numbers must be sequential starting from 0 (e.g., 0, 1, 2). If DockFlare encounters a gap in the sequence (e.g., 0 and 2 but no 1), it will stop processing indices for that container after the last sequential one found.

Example docker-compose.yml

This example exposes multiple hostnames from a single multi-service container.

version: '3.8'

services:
  # Your DockFlare service definition...
  dockflare:
    # ... (Configuration from Quick Start) ...
    networks:
      - cloudflare-net

  # A single container exposing multiple services/hostnames
  multi-service:
    image: traefik/whoami # Simple service that shows request info
    container_name: multi-service-app
    restart: unless-stopped
    networks:
      - cloudflare-net
    labels:
      # --- DockFlare Labels ---
      # 1. Enable DockFlare management for this container (only needed once)
      - "cloudflare.tunnel.enable=true"

      # --- Configuration for Index 0 ---
      # Public hostname 1 (in default zone)
      - "cloudflare.tunnel.0.hostname=app1.example.com"
      # Target service for hostname 1 (assuming the service listens on port 80)
      - "cloudflare.tunnel.0.service=http://multi-service:80"
      # Optional: Disable TLS verification for this specific rule
      - "cloudflare.tunnel.0.no_tls_verify=true"

      # --- Configuration for Index 1 ---
      # Public hostname 2 (in default zone)
      - "cloudflare.tunnel.1.hostname=status.example.com"
      # Target service for hostname 2 (could be the same or different port/protocol)
      - "cloudflare.tunnel.1.service=http://multi-service:80"

      # --- Configuration for Index 2 ---
      # Public hostname 3 (in a *different* zone)
      - "cloudflare.tunnel.2.hostname=api.otherdomain.org"
      # Target service for hostname 3
      - "cloudflare.tunnel.2.service=http://multi-service:80"
      # Specify the zone for this hostname explicitly
      - "cloudflare.tunnel.2.zonename=otherdomain.org"

volumes:
  dockflare_data:

networks:
  cloudflare-net:

Explanation

• cloudflare.tunnel.enable="true": Activates DockFlare for the multi-service container.
• Index 0: Configures app1.example.com to point to http://multi-service:80 within the default zone (specified by CF_ZONE_ID). It also disables TLS verification for the backend connection for this rule only.
• Index 1: Configures status.example.com to point to the same http://multi-service:80, also within the default zone.
• Index 2: Configures api.otherdomain.org to point to http://multi-service:80, but explicitly specifies that this hostname belongs to the otherdomain.org zone using cloudflare.tunnel.2.zonename. DockFlare will look up the Zone ID for otherdomain.org and create the DNS record there.

This feature is powerful for:

• Exposing different API versions or frontends from the same application container under different subdomains.
• Managing services across multiple domains you own within Cloudflare.
• Applying different settings (like no_tls_verify) per hostname.

---

**13. Create file `Using-Wildcard-Domains.md`**

```markdown
# Using Wildcard Domains

DockFlare supports the use of wildcard hostnames (e.g., `*.example.com`) in your container labels. This allows you to route all traffic for any subdomain of a given domain through the Cloudflare Tunnel to a specific service, unless a more specific subdomain rule exists.

### Labeling Strategy

You use the standard `cloudflare.tunnel.hostname` label (or indexed versions like `cloudflare.tunnel.0.hostname`) but provide a wildcard hostname.

### Example `docker-compose.yml`

This example configures a wildcard route for `*.apps.example.com` pointing to a single backend service.

```yaml
version: '3.8'

services:
  # Your DockFlare service definition...
  dockflare:
    # ... (Configuration from Quick Start) ...
    networks:
      - cloudflare-net

  # A service that will handle all requests to *.apps.example.com
  wildcard-handler:
    image: traefik/whoami # Example service
    container_name: wildcard-service
    restart: unless-stopped
    networks:
      - cloudflare-net
    labels:
      # --- DockFlare Labels ---
      - "cloudflare.tunnel.enable=true"

      # Define the wildcard hostname
      # This will match anything.apps.example.com, test.apps.example.com, etc.
      - "cloudflare.tunnel.hostname=*.apps.example.com"

      # Define the target service for all matching subdomains
      - "cloudflare.tunnel.service=http://wildcard-handler:80"

      # Optional: Specify the zone if 'apps.example.com' or 'example.com' isn't the default
      # - "cloudflare.tunnel.zonename=example.com"

      # Optional: Disable TLS verification if needed
      # - "cloudflare.tunnel.no_tls_verify=true"

volumes:
  dockflare_data:

networks:
  cloudflare-net:

Explanation

• cloudflare.tunnel.hostname="*.apps.example.com": This tells DockFlare to configure the Cloudflare Tunnel to route requests for any subdomain directly under apps.example.com (e.g., test.apps.example.com, user1.apps.example.com, but not www.test.apps.example.com) to the specified service.
• cloudflare.tunnel.service="http://wildcard-handler:80": All traffic matching the wildcard hostname will be forwarded to port 80 of the wildcard-handler container.

Use Cases

• Multi-tenant Applications: Where each tenant might get a unique subdomain (tenant1.apps.example.com, tenant2.apps.example.com), all potentially handled by the same backend application instance (which then internally routes based on the hostname).
• Development Environments: Quickly expose dynamically generated preview environments under different subdomains.
• Catch-all Routing: Provide a default backend for any subdomain under a specific domain that doesn't have a more specific rule defined.

Precedence

Cloudflare Tunnel rules follow specificity. If you have both a wildcard rule and a specific subdomain rule defined (either via DockFlare labels on the same or different containers, or manually in Cloudflare):

• Rule for *.example.com -> service A
• Rule for specific.example.com -> service B

Requests to specific.example.com will be routed to service B. Requests to another.example.com (or any other subdomain) will be routed to service A.

DockFlare will manage the DNS record creation (CNAME for *.apps.example.com) and the tunnel ingress configuration accordingly.