UsingMultipleDomainsIndexedLabels.md

Using Multiple Domains (Indexed Labels)

DockFlare allows you to expose multiple hostnames from a single container, each with its own unique path, service target, or access policy. This powerful feature is enabled by indexed labels.

Labeling Strategy

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

• dockflare.0.hostname
• dockflare.0.service
• dockflare.1.hostname
• dockflare.1.service
• ...and so on for every setting.

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

Important: Index numbers must be sequential starting from 0. If DockFlare finds labels for index 0 and 2 but not 1, it will stop processing after index 0.

Example docker-compose.yml

This example uses a single container to expose a public website, a secure API on the same domain but a different path, and a status page on a completely different domain.

version: '3.8'

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

  # A single container exposing multiple rules
  multi-app-gateway:
    image: traefik/whoami # A simple service that echoes request info
    container_name: multi-app-gateway
    restart: unless-stopped
    networks:
      - cloudflare-net
    labels:
      # 1. Enable DockFlare for this container (only needed once)
      - "dockflare.enable=true"

      # --- Rule 0: The main public website ---
      - "dockflare.0.hostname=www.example.com"
      - "dockflare.0.service=http://multi-app-gateway:80"
      # This rule is public by default as no access.policy is set.

      # --- Rule 1: The secure API on a specific path ---
      - "dockflare.1.hostname=www.example.com"
      - "dockflare.1.path=/api"
      - "dockflare.1.service=http://multi-app-gateway:80"
      - "dockflare.1.access.policy=authenticate" # API requires login

      # --- Rule 2: A status page on a different domain ---
      - "dockflare.2.hostname=status.other-domain.org"
      - "dockflare.2.service=http://multi-app-gateway:80"
      - "dockflare.2.zonename=other-domain.org" # Specify the correct zone
      - "dockflare.2.access.policy=bypass" # Explicitly public

Explanation

• dockflare.enable="true": Activates DockFlare for the multi-app-gateway container.
• Index 0: Configures www.example.com to be publicly accessible and handled by the backend service.
• Index 1: Configures www.example.com/api to point to the same backend service, but this endpoint is protected by a Cloudflare Access policy that requires authentication.
• Index 2: Configures status.other-domain.org to be handled by the same container but specifies that its DNS record belongs in the other-domain.org zone. It is made explicitly public with a bypass policy.

This feature is powerful for:

• Exposing a web application and its secure API from the same container.
• Managing services across multiple domains you own.
• Applying different security policies or TLS settings to different paths on the same hostname.

---

New Wiki Page: Using-Wildcard-Domains.md

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 to a specific service, which is especially useful for multi-tenant applications or as a "catch-all" router.

Labeling Strategy

You use the standard dockflare.hostname label but provide a wildcard hostname as the value.

Example docker-compose.yml

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

version: '3.8'

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

  # This service will handle all requests to *.apps.example.com
  wildcard-handler:
    image: traefik/whoami # An example service that can show what hostname it received
    container_name: wildcard-handler
    restart: unless-stopped
    networks:
      - cloudflare-net
    labels:
      # --- DockFlare Labels ---
      - "dockflare.enable=true"

      # Define the wildcard hostname. This will match anything.apps.example.com.
      - "dockflare.hostname=*.apps.example.com"

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

Explanation

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

Wildcards and Access Policies

You can apply an Access Policy to a wildcard rule just like any other rule. For example, adding dockflare.access.policy="authenticate" would protect all subdomains.

Rule Precedence

Cloudflare Tunnels prioritize more specific rules over wildcards. This allows you to override the wildcard for specific subdomains. For example, if you have two containers:

1. Container A (Wildcard): dockflare.hostname="*.example.com"
2. Container B (Specific): dockflare.hostname="specific.example.com"

• A request to specific.example.com will be routed to Container B.
• A request to another.example.com will be caught by the wildcard and routed to Container A.

This makes wildcard routing a flexible and powerful tool for managing dynamic environments.