## DockFlare v1.7 Release Notes - Unified Ingress & Manual Rules!

[ChrispyBacon-dev]

DockFlare v1.7 Release Notes - Unified Ingress & Manual Rules!

I'm excited to announce the release of DockFlare v1.7, a significant update focused on expanding management capabilities and refining the user experience! This version introduces the highly requested Manual Ingress Rule Management, allowing you to bring non-Dockerized internal services under the umbrella of your Cloudflare Tunnel with the same ease as your containerized applications.

✨ New Features

• Manual Ingress Rule Management via UI:
  • Unified View: All managed public hostnames (both Docker-derived and manually added) are now displayed in a single, streamlined "Managed Ingress Rules" table in the Web UI.
  • Add Non-Docker Services: A new "Add Manual Rule" button and modal allow you to easily define public hostnames for services not running in Docker (e.g., your router admin page, Proxmox, NAS UI, internal wikis).
    • Specify hostname, target service URL (e.g., http://192.168.0.1:80, https://internal-server:8443), an optional Cloudflare Zone Name (if different from the global CF_ZONE_ID), and TLS verification settings.
    • DockFlare automatically handles the creation/deletion of the corresponding Cloudflare Tunnel ingress rule and DNS CNAME record.
  • Path Stripping for Services: When adding manual rules, any path included in the service URL (e.g., https://my-service/app/) will be automatically stripped (to https://my-service) for the Cloudflare Tunnel configuration, as Cloudflare expects only the scheme, host, and port. The original path from the user's request will still be passed to your origin service.
• Refined Access Policy Management:
  • Access Policies can now be managed via the UI for both Docker-derived rules and the new Manual Rules, offering the same options (Bypass, Authenticate by Email, Default TLD, etc.).
  • The "Revert" button for UI-set policies on manual rules now clearly indicates it will remove the specific UI policy, making the rule public or subject to a TLD policy.

🎨 UI/UX Enhancements

• Improved Badge Readability: Status badges ("active", "pending deletion", "Manual", "UI Override") in the "Managed Ingress Rules" table are now solid colors (instead of outlines) for much better contrast and readability across all themes.
• Consistent Pulsating Animations (Optional & Configurable):
  • The "Agent Status: running" badge continues to pulsate.
  • The "UI Override" badge now pulsates to draw attention to configurations deviating from label/default settings.
  • The "active" rule status badges are now static solid colors by default for less visual noise.
• Localized Time Display: The "Expires At" column for pending deletions now displays the timestamp in the user's local browser timezone instead of UTC, making it much more intuitive.
• Clearer Rule Identification: The "Identifier" column now explicitly shows "Manual Rule" for manually added entries, distinguishing them from container IDs.

🐛 Bug Fixes & Internal Improvements

• Corrected Ingress Rule Deletion: Resolved a critical bug where deleting a manual rule (and previously, sometimes expired Docker rules) would remove the DNS record and Access Application, but the ingress rule would persist in the Cloudflare Tunnel configuration. The update_cloudflare_config logic is now more assertive, ensuring that rules removed from DockFlare's management are also properly removed from the Cloudflare Tunnel.
• Robust State Handling: The internal source field for rules (docker or manual) is now more consistently managed throughout the application lifecycle (loading, processing, saving state), ensuring accurate differentiation and behavior in reconciliation and cleanup.
• Jinja Template Rendering: Addressed several Jinja2 template syntax and logic errors encountered during development, ensuring smoother page rendering.
• JavaScript Stability: Improved the JavaScript for handling dynamic elements and event listeners related to policy editing, resolving console errors.
• PEP 8 Imports: Standardized Python import order for better code readability and maintainability.

🔧 For Developers & Advanced Users

• The update_cloudflare_config function now takes a more authoritative stance: for the DockFlare-managed tunnel, any non-wildcard, non-catch-all ingress rule found on Cloudflare that is not present in DockFlare's managed_rules (either from Docker labels or manual UI entries) will be removed by DockFlare. This ensures the tunnel configuration accurately reflects DockFlare's intended state. True external wildcards and the API's catch-all rule are still preserved.

You're absolutely right to structure it that way – Cloudflare cleanup first makes more logical sense before local cleanup.

Here's the revised "Upgrading to v1.7" section with that flow:

⬆️ Upgrading to v1.7

Due to significant improvements in state management and the introduction of the source field for rules, a completely clean state (both on Cloudflare and locally) is strongly recommended for the smoothest upgrade. This ensures all new logic operates from a pristine baseline and avoids potential conflicts. This is especially true if you are coming from a version prior to v1.7 or have experienced any inconsistencies.

Recommended Upgrade Path for a True Fresh Start:

1. Clean Up Existing Cloudflare Configuration:

   • Log in to your Cloudflare Dashboard: https://one.dash.cloudflare.com/
   • Navigate to Zero Trust from the sidebar.
   • In the Zero Trust dashboard, go to Access -> Tunnels.
   • Locate the tunnel previously managed by DockFlare (identified by your TUNNEL_NAME environment variable, e.g., "dockflared-tunnel" or your custom name).
   • Delete this tunnel. This will remove its configuration and associated ingress rules on Cloudflare.
   • Next, navigate to your DNS zone within the main Cloudflare Dashboard (usually by clicking your domain under "Websites"). Review and delete any old CNAME records that were pointing to the now-deleted tunnel's .cfargotunnel.com address. DockFlare v1.7 will recreate these as needed.

2. Stop and Remove your Local DockFlare Instance:
   (If using Docker Compose, navigate to the directory containing your docker-compose.yml file)

   docker compose down 

   (For older docker-compose v1, use docker-compose down)
   (If using docker run, use docker stop your_dockflare_container_name && docker rm your_dockflare_container_name)

3. Important: Back up Local State (Optional - for reference only):
   If you wish to keep a reference of your old state.json (e.g., to remember manual rules you'll need to re-add), you can back it up now. This old state file will not be reused for the clean upgrade.

   • Named Volume (e.g., dockflare_data): Note the content of /app/data/state.json within the volume if needed.
   • Bind Mount: Note the content of ./dockflare-data/state.json on your host if needed.

4. Pull the Latest DockFlare Image:

   docker pull alplat/dockflare:stable

   (You can also optionally remove the old image first with docker rmi alplat/dockflare:stable to ensure a completely fresh image pull.)

5. Purge the Local Docker Volume / Clear Bind Mount (CRITICAL for Clean Start):
   This step removes your old state.json, ensuring DockFlare v1.7 starts without any previous local state.

   • Named Volume (if named dockflare_data as per example docker-compose.yml):

     docker volume rm dockflare_data

     Note: If your docker-compose.yml is part of a project, Docker Compose might have prefixed the volume name (e.g., myproject_dockflare_data). Use docker volume ls to verify the exact name if the command above fails, and then use that exact name in the rm command.
   • Bind Mount: If you used a bind mount (e.g., ./dockflare-data:/app/data), delete the state.json file from your host directory (e.g., rm ./dockflare-data/state.json) or delete the entire host directory if it solely contains DockFlare data.

6. Start DockFlare with the New Image and Clean State:
   (If using Docker Compose)

   docker compose up -d

   (Or re-run your docker run ... command if not using Compose, ensuring your volume/bind mount for /app/data is correctly specified – it will be created fresh if it was a named volume that you removed).

   • DockFlare will start with an empty local state.
   • It will create a new tunnel on Cloudflare (using your TUNNEL_NAME).
   • It will perform its initial scan for Docker containers with labels, populating its rules and creating new ingress rules and DNS records.
   • You will need to re-add any services you wish to manage as "Manual Rules" via the new UI feature.

Why a completely clean state (Cloudflare & local) is recommended for v1.7:
The introduction of the source field ("docker" vs. "manual") and the refined update_cloudflare_config logic represent fundamental changes. Starting fresh ensures the integrity of the new rule management system, avoids potential conflicts from older state files or lingering Cloudflare configurations, and allows the application to establish itself as the authority for its managed tunnel from a known, clean baseline.

---

This discussion was created from the release ## DockFlare v1.7 Release Notes - Unified Ingress & Manual Rules!.

[ChrispyBacon-dev]

Hey everyone, thanks for the interest in DockFlare v1.7!

With the new ability to add manual rules for services like router UIs, Proxmox, NAS interfaces, etc., some folks might naturally have security concerns about "exposing" these internal services. I wanted to share a bit more about how DockFlare, when used with Cloudflare Tunnels and Access policies, aims to provide a secure way to access these resources, often offering advantages over traditional methods like VPNs.

The core principle here is Cloudflare's Zero Trust security model. Here’s a breakdown:

1. No Open Inbound Ports on Your Firewall:
   This is a big one. Cloudflare Tunnels work by establishing an outbound-only connection from a lightweight agent (cloudflared) running in your network to Cloudflare's global edge. This means you do not need to open any inbound ports on your home router or firewall for these services. This significantly reduces your direct attack surface from internet scans, as there's no listening port for attackers to find on your public IP.

2. Mandatory Authentication & Authorization via Cloudflare Access:
   This is the heart of the Zero Trust approach. Before anyone can even reach the login page of your internal service (e.g., myrouter.mydomain.com), they must first authenticate and be authorized by Cloudflare Access. You define these policies:

   • Who can access? Restrict by email address (with one-time PINs), specific identity providers (like Google, GitHub, Okta), or even by requiring specific client certificates on the user's device.
   • How strong is the auth? Enforce Multi-Factor Authentication (MFA) through your chosen identity provider.
   • From where? Optionally restrict access based on geography or IP address.
   • What can they access? Policies are per-application (per-hostname), so you can give User A access to your NAS, but not your router, and User B vice-versa.

   Only after passing these checks is the user's traffic securely proxied through Cloudflare's edge and the tunnel to your internal service.

3. Benefits Compared to Traditional VPNs:

   • Granular Control: VPNs often grant broad access to your entire local network. Cloudflare Access allows fine-grained, per-application access control.
   • Ease of Use: For many users, accessing a service via a normal web browser after a familiar SSO login is simpler than configuring and connecting a VPN client, especially across multiple devices.
   • Reduced Attack Surface (Network Level): No open VPN ports on your firewall.
   • Audit Logs: Cloudflare Access provides detailed logs of who attempted to access what, when, and whether they succeeded, giving you visibility.

4. Defense in Depth is Still Key:
   Using Cloudflare Access as a strong "front door" doesn't mean you should neglect security on your internal services themselves. Always use strong, unique passwords for your router, NAS, Proxmox, etc. Zero Trust adds a powerful layer on top of your existing security.

DockFlare's Role:
DockFlare aims to simplify the setup and management of these Cloudflare Tunnel ingress rules and DNS records. With v1.7, it extends this to manually added services and makes it easier to apply and manage the corresponding Cloudflare Access Policies directly from the UI (or via labels for Docker containers).

So, while it might seem like "exposing" services, it's about doing so through a modern, secure, and explicitly controlled Zero Trust gateway. This approach is becoming increasingly popular as a more flexible and often more secure alternative to traditional VPNs for accessing self-hosted applications.

Happy to discuss this further if anyone has questions or wants to share their experiences with Zero Trust setups!