DockFlare v2.0.0 - The Policy Management Update

This is a landmark release for DockFlare, and I'm thrilled to finally share it. Version 2.0 introduces a completely new way to handle access policies, born directly from user feedback.

First, a huge thank you to GitHub user @selimovd for opening Issue #137. His suggestion highlighted a major pain point in the old label system and was the direct inspiration for this entire feature.

Announcing the Official Project Website: dockflare.app!

With this major release, I'm excited to officially launch the project's website: https://dockflare.app

This is now the central place to find everything you need to know about DockFlare, including feature overviews, quick-start guides, and links to the official documentation. It's the best place to start for new users and a great reference for everyone.

New Feature: Access Groups

I think we can all agree that managing access rules by copying and pasting a dozen labels across every container was clumsy and a pain to maintain. The core of v2.0, Access Groups, is my solution to this problem.

• Define Policies Once: There's a new "Settings" page in the web UI where you can create reusable policy templates called Access Groups. You can create a group like nas-family or dev-team, define its rules once (allowed emails, domains, session duration), and you're done.
• Apply with a Single Label: Instead of all the old dockflare.access.* labels, you now only need one: dockflare.access.group=nas-family.
• Update Everywhere, Instantly: If you need to add someone to a group, you just edit it in the UI and hit save. DockFlare will automatically find every service using that group and update its Cloudflare Access policy. No more hunting through docker-compose.yml files.

UI Overhaul

To make room for this new feature and improve the general workflow, I've reorganized the UI.

• New Navigation: A simple navigation bar at the top now lets you switch between pages.
• A Focused Dashboard: The main page is now just a dashboard. It's focused on what DockFlare is actively managing: your Managed Ingress Rules and the Real-time Logs.
• New "Settings" Page: This is where the configuration and infrastructure details now live. It contains:
  • The new Access Groups manager.
  • The list of All Cloudflare Tunnels on Account.
  • The Tunnel & Agent Status card.
• Integrated Modals: The "Add" and "Edit Manual Rule" forms have been updated. You can now assign an Access Group directly from a dropdown, fully integrating the new system into the manual workflow.

Other Improvements

• Centralized Versioning: I've centralized the version number so I don't forget to update it in all three places on the UI anymore.
• UI Polish:
  • The logo in the header moved to the left similar to web site https://dockflare.app
  • Modals with a lot of content will now scroll properly.
• Backend Refinements: The logic for handling labels and access policies has been significantly refactored to support the new Access Groups feature.

Putting It All Together: A Workflow Example

To show how powerful and simple this new system is, let's walk through a common scenario: running a private file-sharing service for your family. We'll use PicoShare, a great lightweight container for this.

Step 1: Create the "nas-family" Access Group

First, instead of touching any YAML files, you'll configure the policy in the DockFlare UI.

1. Navigate to the new Settings page in your DockFlare instance.
2. Click the "Create New Group" button.
3. Fill out the form:
   • Display Name: NAS Family Access (This is just for the UI)
   • Group ID: nas-family (This is what you'll use in the label)
   • Allowed Emails or Domains: dad@family.com, mom@family.com
4. Click "Save Group".

That's it. Your reusable policy is now created and ready to be used by any service.

Step 2: Apply the Group in Your docker-compose.yml

Now, in your docker-compose.yml, you can set up PicoShare with a single, clean label to handle the entire access policy.

services:
  picoshare:
    image: mtlynch/picoshare
    restart: unless-stopped
    volumes:
      - ./picoshare-data:/app/data
    labels:
      # --- Basic DockFlare config ---
      - "dockflare.enable=true"
      - "dockflare.hostname=files.my-nas.com"
      - "dockflare.service=http://picoshare:8080"

      # --- Apply the Access Group ---
      # This single label applies the entire policy we just created.
      # No other access.* labels are needed.
      - "dockflare.access.group=nas-family"

Step 3: Deploy

When you run docker-compose up -d, DockFlare will automatically:

1. Detect the new container.
2. Read the access.group=nas-family label.
3. Look up the policy you created in the UI.
4. Create a dedicated Cloudflare Access Application for files.my-nas.com with the rules to only allow dad@family.com and mom@family.com.

Bonus: Applying the Same Group to a Manual Rule

And of course, this isn't limited to Docker containers. If you have another service running on a Raspberry Pi (e.g., at IP 192.168.1.50), you can protect it with the exact same policy:

1. Go to the DockFlare Dashboard and click "Add Manual Rule".
2. Fill in the details (hostname, service as http://192.168.1.50, etc.).
3. In the "Access Policy" section, simply select "NAS Family Access" from the new "Assign an Access Group" dropdown.
4. Click "Add Rule".

Now, the exact same centrally managed policy protects both your Docker container and your non-Docker service. If you need to add a new family member later, you only have to edit the group in one place, and access to both services will be updated automatically.

---

This was a big undertaking, and I believe it makes DockFlare significantly more powerful and easier to use. I hope you find it as useful as I do. As always, thank you for your support and feedback.

DockFlare v1.9.5: Agent Startup Reliability Fix

DockFlare v1.9.5: Agent Startup Reliability Fix

This is a hotfix release that addresses a key stability issue to improve the reliability of the managed cloudflared agent container.

What's Fixed?

• Agent Startup Resilience: The startup logic is now smarter. DockFlare will automatically detect and recover if the cloudflared agent container fails to start due to a stale or missing Docker network. It will now remove the broken container and create a new, healthy one in its place.

A huge thank you to @MattW for the excellent bug report and detailed logs in issue #148 which made this fix possible!

For a detailed list of all changes, please see the CHANGELOG.md.

DockFlare v1.9.4: Bug Fixes and Stability Improvements

DockFlare v1.9.4: Bug Fixes and Stability Improvements

This release is a roll-up of several important bug fixes that improve the stability and usability of DockFlare. A big thank you to the community for the detailed bug reports!

What's Fixed?

UI and Manual Rule Fixes

• Critical Fix for Email Authentication: I've resolved a critical bug that caused an "Internal Server Error" when creating or editing rules to use the "Authenticate by Email" policy from the web UI. This was a regression from recent API updates and is now fully functional again.

Label and Service Validation Fixes

• Auto-Redirect for Identity Providers Restored: The access.auto_redirect_to_identity=true label functionality has been fixed. A regression was preventing the correct API payload from being sent to Cloudflare, and this now works as expected.
• Improved Support for Docker Service Names: The validation for service URLs now correctly accepts underscores (_) in hostnames (e.g., http://my_docker_service:8080), making it much easier to use with standard Docker Compose naming conventions.
• Optional Ports for HTTP/S: The port is now optional for http:// and https:// services in your labels. If omitted, Cloudflare's default ports (80/443) will be used.

Example: Using `auto_redirect_to_identity` with Labels

Here is a practical example of how to use the auto_redirect_to_identity feature with a single Identity Provider (IdP), such as Google or Azure AD.

docker-compose.yml Example

version: '3.8'
services:
  my-app:
    image: nginx:alpine # Replace with your actual application image
    restart: unless-stopped
    networks:
      - cloudflare-net
    labels:
      # --- Core DockFlare Labels ---
      - "dockflare.enable=true"
      - "dockflare.hostname=app.YOUR_DOMAIN.com"
      - "dockflare.service=http://my-app:80"

      # --- Access Policy Labels for Auto-Redirect ---
      # 1. Set the policy to 'authenticate'
      - "dockflare.access.policy=authenticate"
      
      # 2. Enable the auto-redirect feature
      - "dockflare.access.auto_redirect_to_identity=true"

      # 3. Provide the single IdP you want to redirect to
      #    See instructions below on how to find this UUID.
      - "dockflare.access.allowed_idps=YOUR_SINGLE_IDP_UUID_HERE"

networks:
  cloudflare-net:
    # Assumes you have an external network for DockFlare
    name: cloudflare-net
    external: true

How to Find Your IdP UUID

You can find the UUID for your configured login methods (like Google, Azure AD, etc.) in the Cloudflare Zero Trust dashboard:

1. Navigate to your Cloudflare Zero Trust Dashboard.

2. On the left-hand menu, go to Settings -> Authentication.

3. Under the Login methods card, find the provider you want to use and click its Edit button.

4. Look at the URL in your browser's address bar. The UUID is the long string at the very end.

   Example URL:
   https://one.dash.cloudflare.com/ACCOUNT_ID/access/identity-providers/edit/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

This update is recommended for all users to ensure the best stability and access to all features.

For a detailed list of all changes, please see the CHANGELOG.md.

DockFlare v1.9.1 - Prometheus Metrics & Major Stability Enhancements

DockFlare v1.9.1 - Prometheus Metrics & Major Stability Enhancements

I'm thrilled to release DockFlare v1.9.1! This version introduces a highly requested feature for monitoring and observability: Prometheus Metrics.

This release is also packed with critical bug fixes and stability improvements that significantly enhance the reliability of core features like automatic rule cleanup and Access Policy management.

✨ New Feature: Prometheus Metrics Endpoint

You can now enable the built-in Prometheus metrics endpoint on the managed cloudflared agent to export a wide range of valuable data for use in tools like Grafana.

How to Use It:
Simply add the new CLOUDFLARED_METRICS_PORT variable to your .env file:

# .env file
# Enables the metrics endpoint on port 2000.
# The port will be exposed to the Docker host.
CLOUDFLARED_METRICS_PORT=2000

🤖 Agent & Rule Management Improvements

• Automatic Reconciliation: DockFlare will now automatically detect any changes to your metrics configuration (CLOUDFLARED_METRICS_PORT) and recreate the agent container with the correct settings on restart.
• Rewritten Rule Cleanup Logic: The background cleanup task has been completely rewritten to be resource-aware. It now intelligently handles multi-path services, ensuring that shared resources (like a DNS record) are only deleted when no other active rules depend on them.
• Improved Cleanup Responsiveness: The default interval for the cleanup task (CLEANUP_INTERVAL_SECONDS) has been reduced from 300 to 60 seconds, making the automatic deletion of expired rules much more responsive.

🛠️ Bug Fixes

• allowed_idps Label Fixed: Resolved a critical bug that caused API errors when using the access.allowed_idps label. DockFlare now correctly constructs Access Policy rules using the modern login_method keyword, making the feature fully functional.
• Multi-Path UI Policy Management: Fixed an issue where managing Access Policies from the web UI would fail for rules that included a path.
• Manual Rule Creation: Corrected a bug that prevented manually created ingress rules from being properly configured in the Cloudflare Tunnel.

📊 Example Grafana Dashboard Included

To help you get started immediately, a pre-configured and detailed Grafana dashboard is now included in the repository.

• Location: You can find dashboard.json in the examples/ directory of the repository.
• How to Use: Simply import this JSON file into your Grafana instance.

How to Upgrade

To upgrade your Docker Compose deployment, run the following commands:

# Pull the latest stable image
docker compose pull

# Recreate the DockFlare container to apply the new code
docker compose up -d

After upgrading, you can add the CLOUDFLARED_METRICS_PORT variable to your .env file, and DockFlare will handle the rest.

Quick Guide: How to Set Up a Local Prometheus & Grafana Stack

If you don't already have a monitoring stack, here is a minimal docker-compose setup to get you started quickly.

1. Directory Structure

Create the following folders and files alongside your main docker-compose.yml:

.
├── docker-compose.yml   # Your main compose file
├── prometheus.yml         # New file for Prometheus configuration
└── grafana-provisioning/  # New folder
    └── datasources/       # New sub-folder
        └── datasource.yml # New file for Grafana configuration

2. File Contents

A) docker-compose.yml

Add the following services to your existing docker-compose.yml file:

services:
  # ... your existing dockflare service ...

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus_data:/prometheus # Persistent data for Prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    networks:
      - your-dockflare-network # <-- IMPORTANT: Use the same network as DockFlare
    labels:
      - "dockflare.enable=true"
      - "dockflare.hostname=prometheus.your-domain.com"
      - "dockflare.service=http://prometheus:9090"

  grafana:
    image: grafana/grafana-oss:latest
    container_name: grafana
    restart: unless-stopped
    volumes:
      - ./grafana_data:/var/lib/grafana # Persistent data for Grafana
      - ./grafana-provisioning:/etc/grafana/provisioning
    networks:
      - your-dockflare-network # <-- IMPORTANT: Use the same network as DockFlare
    labels:
      - "dockflare.enable=true"
      - "dockflare.hostname=metrics.your-domain.com" # Exposes Grafana
      - "dockflare.service=http://grafana:3000"

Permissions Tip: If Grafana or Prometheus fail to start with a "Permission denied" error, you may need to set the ownership of the host directories. Run sudo chown -R 472:472 ./grafana_data for Grafana and sudo chown -R 65534:65534 ./prometheus_data for Prometheus.

B) prometheus.yml

This file tells Prometheus where to find your cloudflared agent.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'cloudflared'
    static_configs:
      - targets: ['your-cloudflared-agent-name:2000']
        # --- IMPORTANT ---
        # 1. Replace 'your-cloudflared-agent-name' with the actual name of your agent container (e.g., 'cloudflared-agent-green-bern').
        # 2. Replace '2000' with the port you set for CLOUDFLARED_METRICS_PORT.

C) grafana-provisioning/datasources/datasource.yml

This automatically adds Prometheus as a data source in Grafana.

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

3. How to Use

1. Start the Stack: Run docker-compose up -d.
2. Check Prometheus: Navigate to your Prometheus URL (e.g., http://prometheus.your-domain.com). Go to Status -> Targets. The cloudflared endpoint should be UP.
3. Import Dashboard: Navigate to your Grafana URL (e.g., http://metrics.your-domain.com), log in (default: admin/admin), and import the dashboard.json file provided in the examples/ directory of the DockFlare repository.
4. View Your Metrics!

DockFlare v1.8.9 - A New Look and More Power!

DockFlare v1.8.9 - A New Look and More Power!

I'm thrilled to announce the release of DockFlare v1.8.9! This is a significant update, focused on improving the user experience with a more intuitive, project-aligned configuration and providing much greater routing flexibility.

✨ New Feature: It's Official! Say Hello to the dockflare. Label Prefix

To better align with the project's identity, the default label prefix has been changed from cloudflare.tunnel. to dockflare.. This makes configuration more intuitive and clearly ties your labels to the DockFlare project. I believe this will make setting up new services much cleaner and easier to understand.

Your Old Compose Files Are Safe!

This is not a breaking change. I've designed it so that your existing docker-compose.yml files using the cloudflare.tunnel. prefix will continue to work without any changes.

DockFlare now intelligently checks for labels in a specific order:

1. A custom prefix you've set via the LABEL_PREFIX environment variable.
2. The new dockflare. prefix.
3. The legacy cloudflare.tunnel. prefix.

New Recommended Label Style:

version: '3.8'
services:
  my-service:
    image: some-image
    labels:
      # The new, cleaner way!
      - "dockflare.enable=true"
      - "dockflare.hostname=service.mydomain.com"
      - "dockflare.service=http://my-service:8080"
      - "dockflare.access.policy=bypass"

✨ New Feature: Multi-Path Routing per Hostname

You are no longer limited to a single path per hostname! I've completely refactored the internal state management so that DockFlare can now intelligently handle multiple ingress rules for the same hostname, each pointing to a different path. This is perfect for routing traffic to different services in a microservice architecture or for exposing different parts of an application under a single domain.

How it Works:
By using indexed labels (e.g., .0., .1., etc.), you can now define multiple rules for the same hostname. DockFlare uses a combination of hostname and path as the unique identifier for a rule, preventing the "last one wins" problem and overwrite behavior of previous versions.

Example: A single Nginx container serving multiple paths (using the new labels!)

version: '3.8'
services:
  my-api-gateway:
    image: nginx:alpine
    container_name: my-api-gateway
    labels:
      - "dockflare.enable=true"

      # --- Rule 0: The root path ---
      - "dockflare.0.hostname=api.mydomain.com"
      - "dockflare.0.service=http://my-api-gateway:80"

      # --- Rule 1: The /users path ---
      - "dockflare.1.hostname=api.mydomain.com"
      - "dockflare.1.path=/users"
      - "dockflare.1.service=http://my-api-gateway:80"

      # --- Rule 2: The /products path ---
      - "dockflare.2.hostname=api.mydomain.com"
      - "dockflare.2.path=/products"
      - "dockflare.2.service=http://my-api-gateway:80"

In this example, DockFlare will correctly create and manage three separate ingress rules for api.mydomain.com.

🛠️ Improvements & Fixes

This release also includes important stability enhancements and bug fixes, particularly related to the new multi-path routing feature and UI interactions.

• Robust UI Policy Management: The logic for managing Cloudflare Access policies via the web UI has been completely overhauled. It now correctly handles rules with paths, ensuring that creating, updating, or reverting policies for multi-path hostnames is reliable and error-free.
• Manual Rule Creation Fixed: An issue where manually created rules were not being correctly added to the Cloudflare Tunnel's ingress configuration has been resolved. The internal state for manual rules now perfectly mirrors the structure of Docker-generated rules, ensuring they are always processed correctly.
• Efficient API Usage: Policy updates from the UI are now more intelligent. DockFlare will first check if the requested configuration already matches what's on Cloudflare, preventing unnecessary API calls and making the interface feel more responsive.

🚀 What's Next?

I will be updating the official documentation and all examples in the repository shortly to reflect the new dockflare. prefix as the recommended standard.

Thank you for your continued support and for contributing to the project with your excellent feedback and feature requests! I hope you enjoy the new flexibility.

Hotfix v1.8.7

Hotfix v1.8.7: Critical Agent Startup Fix

I've just released a critical hotfix that resolves a bug preventing the managed cloudflared agent from starting correctly.

The Issue:
Some of you may have seen the Provided Tunnel token is not valid error from the cloudflared container.

The Fix:
I've updated the code to be more robust. It now correctly handles both the new JSON format and the original raw text format, ensuring the agent will start reliably for everyone.

A huge thank you to the community for reporting and diagnosing this in GitHub Issue #101.

How to Upgrade:
To apply the fix, just pull the latest image:

docker-compose pull
docker-compose up -d

DockFlare v1.8.6 - Support for edit manual ingress rule

DockFlare v1.8.6

This release introduces a usability improvement: the ability to edit manual ingress rules directly from the web UI. You no longer need to delete and recreate a manual rule to make changes.

✨ New Features

• Edit Manual Rule Functionality:
  • A new "Edit" button now appears next to each manual rule in the "Managed Ingress Rules" table.
  • Clicking "Edit" opens a modal pre-populated with the rule's current settings (hostname, path, service, access policy, etc.).
  • The backend logic intelligently handles updates by cleanly removing old, unused Cloudflare resources (DNS records, Access Applications) and creating/updating the new ones, preventing orphaned configurations on your Cloudflare account.

Improvements

• Improved Code Reusability: A shared helper function was created in main.js to handle path input logic for both the "Add" and "Edit" modals, reducing code duplication.
• Enhanced Code Quality: This refactoring improves overall code organization, maintainability, and adherence to web development best practices.

Changed Files

• dockflare/app/web/routes.py: Added the new /ui/manual-rules/edit route and its handler function to process rule updates.
• dockflare/app/templates/status_page.html: Added the "Edit" button and the "Edit Rule" modal structure.
• dockflare/app/static/js/main.js: Added functions to manage the edit modal's behavior and refactored shared logic.

How to Upgrade

To upgrade your Docker Compose deployment, run the following commands in the directory containing your docker-compose.yml file:

# Pull the latest Docker image for the backend
docker-compose pull dockflare

# Recreate the container with the new image
docker-compose up -d --force-recreate dockflare

DockFlare v1.8.5: Enhanced TLS Control with Origin Server Name (SNI) Support

DockFlare v1.8.5: Enhanced TLS Control with Origin Server Name (SNI) Support

This release introduces a key enhancement for configuring Cloudflare Tunnel ingress rules: support for Origin Server Name (SNI). This provides users with more granular control over TLS connections to their origin services.

✨ New Features

• Origin Server Name (SNI) Support for Ingress Rules:
  • Users can now specify the originServerName for an ingress rule. This allows DockFlare to instruct Cloudflare to use a specific Server Name Indication (SNI) during the TLS handshake with the origin service. This is particularly useful when the origin service is behind a reverse proxy, hosts multiple sites on one IP, or expects a specific hostname for its TLS certificate.
  • Docker Label: Added support for the cloudflare.tunnel.<index>.originsrvname=<value> (or cloudflare.tunnel.originsrvname=<value> for non-indexed default) label.
    • Example: labels: ["cloudflare.tunnel.0.originsrvname=internal.service.local"]
  • Web UI (Manual Rules): The "Add New Manual Ingress Rule" modal now includes a dedicated "Origin Server Name (SNI for TLS)" input field. This field is dynamically shown only when the selected service type is HTTP or HTTPS, as SNI is primarily relevant for these protocols.

🔧 Improvements & Internal Changes

• State Management: The internal state (managed_rules) now stores the origin_server_name for each rule configuration.
• Cloudflare API Interaction: The originRequest object in the Cloudflare tunnel configuration payload is now correctly constructed to include noTLSVerify and originServerName as needed. Comparison logic for detecting changes has also been updated.
• Docker Label Parsing: Both docker_handler.py (for new containers) and reconciler.py (for existing containers during reconciliation) have been updated to parse and process the new originsrvname label.
• Web UI:
  • The "Add Manual Rule" backend route (ui_add_manual_rule_route) now processes and stores the origin_server_name from the UI form.
  • (Optional - if you implemented it) The main "Managed Ingress Rules" table can now display the configured SNI for relevant rules.
  • JavaScript in main.js has been enhanced to dynamically show/hide the "Origin Server Name" input field in the manual rule modal based on the selected service type (HTTP/HTTPS).
• Code Quality: Addressed a minor issue in docker_handler.py by removing a duplicate, simpler definition of the is_valid_service function, ensuring the more robust regex-based validation is used.

📝 Notes

• The originServerName setting is most effective for http and https service types. While it can be set for other types, Cloudflare may ignore it if a TLS handshake to the origin is not part of its standard proxying behavior for that protocol.
• Remember to update your Docker image to dockflare:1.8.5 or dockflare:latest to use these new features.

DockFlare v1.8.4 - Path Routing, Service Types, Access Policies & UI Polish!

DockFlare v1.8.1 - Path Routing, Service Types, Access Policies & UI Polish!

DockFlare v1.8.1 is here, bringing highly requested Path-Based Routing, versatile Extended Service Type Support, more powerful Manual Rule creation with Access Policy support, and several UI and backend improvements for a smoother and more robust experience!

New Features & Major Enhancements:

1. Path-Based Routing for Ingress Rules:

   • Define specific URL paths on your hostnames to route to different backend services or parts of an application.
   • Docker Labels: Specify URL paths using your-label-prefix.path=/your-service-path or your-label-prefix.{index}.path=/your-service-path.
     • Example: Expose myapp.example.com/api by setting cloudflare.tunnel.hostname=myapp.example.com and cloudflare.tunnel.path=/api.
     • You can define multiple distinct hostnames, each with its own optional path, from a single Docker container using indexed labels (e.g., cloudflare.tunnel.0.hostname, cloudflare.tunnel.0.path, cloudflare.tunnel.1.hostname, cloudflare.tunnel.1.path).
     • Note on Docker Label Path Routing: Currently, if a single Docker container attempts to define multiple different paths for the exact same hostname via its labels, only the last processed path definition for that hostname will be active. Subsequent path definitions for the same hostname from the same container will overwrite previous ones.
       • Example: Labels for app.example.com/api and app.example.com/ui on the same container would result in only one of these path rules being applied (the one with the highest index or processed last).
       • To route multiple paths on the same hostname to different services using Docker labels, consider using separate containers for each service/path combination.
   • Manual Rules UI: The "Add New Manual Ingress Rule" dialog now includes an optional "Path" field.
     • The displayed "/" in the UI is automatically prepended; users just type the path segment (e.g., "app").
     • You can create multiple manual rules for the same hostname with different paths, each pointing to different services.
   • Functionality: Cloudflare Tunnel ingress rules are configured with these paths. Requests matching hostname + path are forwarded, appending the matched path and subsequent segments to the origin service URL.
     • Example: Public myapp.com/api/users with service http://backend:3000 and path /api in DockFlare routes to http://backend:3000/api/users.
   • UI Display: The "Managed Ingress Rules" table now includes a "Path" column, showing "(root)" if no path is set. Clickable hostname links correctly include the path.

2. Extended Service Type Support:

   • DockFlare now robustly supports a wider range of service types beyond just HTTP/S, aligning with Cloudflare Tunnel capabilities. Supported types include: http, https, tcp, ssh, rdp, and http_status (for returning a specific HTTP status code).
   • Docker Labels: Specify the service type directly in your existing service label. DockFlare will parse the prefix to determine the type.
     • cloudflare.tunnel.service=http://localservice:80
     • cloudflare.tunnel.service=https://securelocal:443
     • cloudflare.tunnel.service=tcp://gameserver:25565
     • cloudflare.tunnel.service=ssh://internalhost:22
     • cloudflare.tunnel.service=rdp://desktop:3389
     • cloudflare.tunnel.service=http_status:404
   • Manual Rules UI: The "Add New Manual Ingress Rule" dialog features a clear "Service Type" dropdown. The "Service Address" input field dynamically guides the user based on the selected type (e.g., showing tcp:// prefix, expecting host:port or just a status code).

3. Enhanced Manual Rule Creation with Access Policy Support:

   • Direct Access Policy Assignment: When adding a new manual ingress rule via the UI, you can now directly assign a Cloudflare Access Policy:
     • None (Public - No App)
     • Bypass (Public App - creates a Cloudflare Access App with a bypass policy)
     • Authenticate by Email (creates a Cloudflare Access App requiring email authentication)
     • Use Default *.tld Policy (relies on an existing TLD wildcard policy, no app created by DockFlare for this rule)
   • A conditional "Allowed Email(s) or Domain(s)" field appears when "Authenticate by Email" is selected.
   • This provides upfront security configuration for manually exposed services.

4. UI Improvements for Manual Rule Modal:

   • The "Add New Manual Ingress Rule" dialog has been restructured for better clarity, grouping "Public Hostname," "Service," and "Access Policy" fields, inspired by the Cloudflare dashboard layout.
   • Increased modal width for better readability and field layout on larger screens.

Fixes & Other Enhancements:

• State Management & Backend Logic:
  • state.json correctly stores/loads path, hostname_for_dns (for manual rules), and new access policy attributes for manual rules.
  • update_cloudflare_config in tunnel_manager.py now correctly uses the base FQDN hostname and path when constructing ingress rules for the Cloudflare API.
  • Logic for identifying DockFlare-managed rules in the Cloudflare API config now correctly considers paths for uniqueness.
  • Enhanced sorting of ingress rules for Cloudflare API updates to ensure consistent ordering.
  • Improved conditional deletion of DNS records and Access Applications when manual rules are removed, preventing premature deletion if resources are shared by other path-based rules on the same base hostname.
• UI Display & Links:
  • Corrected display of hostnames for Docker-originated rules in the UI after path-handling changes.
  • Links in the "Managed Ingress Rules" table now consistently use https:// (or the current scheme of the DockFlare UI) for external links.
  • Fixed a Jinja2 template syntax error related to quote escaping in onsubmit confirm dialogs.
  • Resolved an issue where SVG icons (e.g., link icon in DNS records list) could render overly large by ensuring Tailwind CSS classes for sizing are correctly applied.
• Service URL Validation:
  • Stricter validation for HTTP/S service URLs (from labels and UI) now disallows paths within the service definition itself (e.g., http://host:port/api is invalid; path should be specified separately). For other types like TCP/SSH/RDP, the host:port format is enforced. http_status expects a status code.

Impact for Users:

• Increased Flexibility & Granularity: Path-based routing, extended service types, and direct access policy assignment offer significantly more control.
• Improved User Experience: Clearer UI for adding rules, more accurate displays, and corrected link behaviors.
• Enhanced Stability: Backend fixes ensure more reliable interaction with the Cloudflare API and state management.
• No Change to Existing Root Rules: Rules without a specified path continue to function as before.

To Use New Features:

• Path-Based Routing (Docker): Add {prefix}.path label. Remember the note above regarding multiple paths for the same hostname from a single container.
• Extended Service Types (Docker): Prefix your service URL in the {prefix}.service label (e.g., tcp://host:port, http_status:503).
• Manual Rules (Path, Service Type, Access Policy): Use the updated "Add New Manual Ingress Rule" modal in the Web UI.

DockFlare v1.8.0 - Major Codebase Refactor!

DockFlare v1.8.0 - Major Codebase Refactor!

This release marks a significant internal overhaul of DockFlare's codebase, focused on enhancing modularity, maintainability, and future development. While the core functionality remains the same, the underlying structure has been substantially improved.

Key Changes & Improvements:

• Major Codebase Refactoring:

  • The main app.py has been deconstructed into a more organized, package-based structure:
    • app/core/: Contains distinct modules for core business logic:
      • access_manager.py: Manages Cloudflare Access Application interactions.
      • cloudflare_api.py: Centralizes all direct Cloudflare API calls.
      • docker_handler.py: Handles Docker event listening and container label processing.
      • reconciler.py: Implements state reconciliation and cleanup of expired rules.
      • state_manager.py: Manages application state (managed_rules) and persistence to state.json.
      • tunnel_manager.py: Handles Cloudflare Tunnel initialization, configuration updates, and cloudflared agent management.
    • app/web/: Contains Flask-specific components:
      • routes.py: Defines all web UI routes using Flask Blueprints.
    • app/config.py: Centralizes all environment variable loading and application constants.
    • app/__init__.py: Initializes the Flask application, logging, and global components.
    • app/main.py: Serves as the main entry point for running the application.
  • This modular structure improves separation of concerns, making the code easier to understand, debug, and extend.

• Frontend JavaScript Externalized:

  • All inline JavaScript from status_page.html has been moved to app/static/js/main.js.
  • status_page.html is now cleaner and primarily focused on HTML structure.

• Build Process Refinements:

  • Dockerfile updated to correctly build the application with the new directory structure, including the multi-stage frontend asset build.
  • Paths in package.json (for build:css script) and tailwind.config.js (for content scanning) updated to align with the new app/ subdirectory structure.
  • GitHub Actions workflow (docker-image.yml) adjusted for the new Dockerfile location and build context.

• Bug Fixes & Stability Improvements (discovered and addressed during refactoring):

  • Resolved potential circular import issues related to the Flask app instance.
  • Addressed issues with state.json not saving correctly due to Python's handling of module-level global variables during imports and re-initialization. The load_state function now correctly mutates the shared managed_rules dictionary.
  • Fixed a deadlock scenario where save_state could hang if called by a thread that already held the state_lock, by changing state_lock to a threading.RLock() (Re-entrant Lock).
  • Corrected NameError exceptions in UI route handlers by ensuring proper function calls (e.g., using module prefixes or correct imports).
  • Resolved a TypeError in UI policy updates by ensuring all required arguments were passed to generate_access_app_config_hash.
  • Fixed an AttributeError in update_cloudflared_container_status related to None.startswith().
  • Corrected an issue with oversized SVG icons in the UI by fixing a class name typo.
  • Improved robustness of save_state by avoiding copy.deepcopy() on entire rule objects and instead explicitly selecting fields for serialization.

• Enhanced Logging:

  • Added more detailed logging, including object ID tracking during critical state operations, to aid in debugging shared state and threading issues.