It focuses on practical improvements that came straight from your real-world setups, and I really appreciate how specific and actionable the reports were.

Highlights

• Added Match SNI to Host support for manual ingress rules in the web UI.
• Added a UI setting to preserve unmanaged Cloudflare ingress fields during sync.
• Updated Cloudflare Zero Trust deep links to match Cloudflare’s current URL structure.
• Fixed tunnel-name edge cases where Docker-invalid characters could break cloudflared agent container creation.
• Added Dashboard grouping for Managed Ingress Rules by Status, Tunnel, or Access Policy.

Community shout-outs

• Enhancement: add grouping to dashboard #320
  Thank you @MischaBoender

• Match SNI to host toggle or option to ignore rules #319
  Thank you @Slogstorm

• Wrong endpoint in access manager #304
  Thank you @x3lq for raising the Cloudflare email endpoint issue in Access Manager

• Invalid container name #309
  Thank you @martingjohn

Added

• Manual Rule SNI Control:

  • New Match SNI to Host toggle for manual rules (create/edit).
  • Persisted in DockFlare state and synchronized to Cloudflare as originRequest.matchSNIToHost.

• UI-Managed Ingress Field Preservation:

  • New General Settings option:
    • Preserve Unmanaged Cloudflare Ingress Fields
  • Lets DockFlare keep Cloudflare-side route fields it does not explicitly manage.

• Dashboard Grouping:

  • New Group by control in Managed Ingress Rules.
  • Group by:
    • Status
    • Tunnel
    • Access Policy
  • Includes per-group counts for easier navigation on larger rule sets.

Fixed

• Cloudflare Dashboard Deep Links:

  • Tunnel route links now use:
    • .../networks/connectors/cloudflare-tunnels/.../public-hostname/.../{index}
  • Access application links now use:
    • .../access-controls/apps/self-hosted/.../edit?tab=basic-info
  • Access policy links now use:
    • .../access-controls/policies/.../edit

• Access Manager Cloudflare Email Call:

  • Corrected account email retrieval flow related to the wrong endpoint behavior raised in issue #304.

• Tunnel Name Character Handling:

  • Fixed cloudflared agent startup failures when tunnel names contain Docker-invalid characters (for example spaces or parentheses), as reported in issue #309.
  • DockFlare now normalizes generated container names across setup, config load, and settings updates.

Notes

• No migration steps required for standard installs.
• If you rely on Cloudflare-only ingress options, consider enabling:
  • Preserve Unmanaged Cloudflare Ingress Fields
• Existing rules continue to work; grouping is a UI enhancement.

Thanks again for building, testing, and pushing DockFlare forward with me.

Happy tunneling and cheers,
Christian

Hi everyone,

After a break to recharge and revisit a few open topics, I’m back with v3.0.6. This release focuses on performance improvements and clarity in the UI. Nothing flashy, just solid refinements that make DockFlare behave better in real-world environments.

Improvements & Fixes

Docker Event Listener Optimization

Reduced log noise and improved resource usage by introducing filtered Docker event listeners.

DockFlare now processes container start and stop events only for containers explicitly opted in via:

• dockflare.enable
• cloudflare.tunnel.enable (legacy support)

This prevents unnecessary inspection of unmanaged containers and keeps things much cleaner, especially on hosts running many services.

Fixes #296

Access Policy Label Clarification

Renamed the Access Policy label from:

None (Public - No App)

to:

No Policy Assigned

The previous wording implied that a service was public, which is not necessarily true since a broader Zone Policy may still apply. The new label better reflects the actual state without creating confusion.

Thanks to everyone who continues to report issues and share feedback. More refinements are coming.

Christian

Hello everyone,

This is a small feature release that adds two new CloudFlare features for more specific use cases.

A special thank you to @SeraphimSerapis for the input on GitHub issue #281, which directly led to the features in this update.

New Additions

• HTTP/2 Origin Support: You can now enable the HTTP/2 protocol for the connection between cloudflared and your origin services. This is necessary for services that use gRPC and only applies to HTTP/HTTPS services.

• Disable Chunked Encoding: Support has been added to disable chunked transfer encoding. This is useful for origins that do not properly support it, such as some WSGI servers (Flask, Django, FastAPI).

These new settings can be configured in a few ways:

• Container Labels: Use the new dockflare.http2_origin and dockflare.disable_chunked_encoding labels on your Docker containers. This works for containers on the main DockFlare instance as well as those on remote servers running the DockFlare Agent.

• Manual Rules: When creating or editing a manual rule in the web UI, both "HTTP/2 Origin" and "Disable Chunked Encoding" can now be enabled for the rule.

For usage details on the new labels, please see the updated Container Labels documentation.

Vielen Dank!
Cheers,
Chris

Hello everyone,

I've just pushed a new update, version 3.0.4. This release is focused on fixing several key bugs that many of you have reported, along with some nice quality-of-life improvements for the UI.

Bug Fixes and Stability Improvements

Thanks to some very helpful and detailed bug reports from the community, I was able to track down and fix a few significant issues:

• Agent Management is working again: A couple of key features on the Agents page were broken. Trying to roll an agent's API key was causing a network error, and attempting to redeploy a tunnel container would result in a 500 error from the server (fixes #274). Both of these issues have been resolved, and those actions should now work as expected.
• Access Policy editing is fixed: There was an annoying bug where, after saving a policy with country restrictions, the selected countries wouldn't be displayed correctly when you went back to edit it. This has been fixed (addressing #275), so you should be able to see and modify your selections properly now.
• Multi-hostname Access Policies fixed: I fixed an edge case where if you assigned the same access group to multiple hostnames on a single container (like www.domain.com and domain.com), only the first rule would be secured correctly. Subsequent hostnames would incorrectly bypass authentication. This is now resolved, and the policy will be applied to all hostnames as expected (addressing #276).
• Better security validation: I've added some important checks to prevent accidentally creating an insecure Access Policy. The system will now make sure you specify required email addresses when using an Identity Provider and will warn you if you're only using geo-restrictions without any real authentication.
• Prevents duplicate system policies: DockFlare is now smarter about checking if the default system policies already exist before trying to create them on startup. This should prevent duplicate policies from being created if you happen to run multiple instances.

UI Improvements

One thing that has bothered me for a while was the use of the default browser popups for alerts and confirmations. They were functional, but they didn't really fit DockFlare's style. I went through and replaced all 53 of them with custom modals that match the DaisyUI theme, which I think makes for a much cleaner and more consistent experience.

I also made a few other small improvements to the UI:

• I added a new sort option to the Dashboard so you can group your ingress rules by their assigned Access Policy. This should make it a bit easier to audit which services are using which policies.
• The Agents page got a small visual refresh to match the style of the Access Policies page.

A New Tool for Advanced Users

Finally, I've included a new command-line utility in this release. To be honest, I originally built this tool for myself. While testing and fixing the agent bugs, I had to run multiple DockFlare instances, which left my Cloudflare account with a lot of duplicate policies. This tool was my way of cleaning that up safely. It has a --dry-run mode to let you see what it will do before it makes any changes. I decided to leave it in the project in case it might be useful for anyone else who runs into a similar situation. You can find more details on how to use it in the CLI_USAGE.md file.

As always, thank you for using DockFlare and for all the valuable feedback. For a more detailed breakdown of all the changes, you can refer to the full changelog. Let me know if you run into any issues with this new version.

Cheers,
Chris

Hey everyone,

I’m excited to share this update with you. This release has been a real labor of love, focused on solving the same pain points that led me to build DockFlare in the first place.

It’s a longer read, but worth it: not just what changed, but why it changed.

Identity Provider Management

This is the big one I’ve wanted for a long time: manage OAuth/OIDC Identity Providers (IdPs) directly inside DockFlare, no more jumping between dashboards.

What’s New

• Full IdP management: Add, edit, test, and delete Identity Providers (Google, Azure AD, GitHub, Okta, or generic OIDC) directly from DockFlare.
• Friendly names: Use human-readable labels like google-main or github-dev. DockFlare automatically maps them to Cloudflare UUIDs.
• One-click Cloudflare sync: Import existing IdPs with auto-generated friendly names.
• Built-in testing: Verify OAuth flows before production rollout.
• Brand-accurate icons: Instantly recognize each provider.
• System protection: Prevent accidental deletion of critical providers like one-time PIN.

Security by Design: Email Restrictions Required

By default, Cloudflare allows any Google account when using "Google" as an IdP, even personal ones.
DockFlare now enforces secure defaults: you must specify allowed emails or domains (admin@example.com, @company.com).

Both UI and API validations ensure you cannot create insecure configurations by accident.

“When using Identity Providers, you must specify allowed email addresses to prevent unauthorized access.”

Integration with Access Groups

Identity Providers now tie neatly into Access Groups:

• Choose one or more IdPs
• Specify allowed emails or domains
• Users must authenticate via the IdP and match the allowlist
• Both conditions must pass for access to be granted

Public vs Authenticated Access Modes

Previously, DockFlare mixed Cloudflare’s bypass and allow modes in confusing ways.
This release introduces a clean separation.

Public Access Mode (bypass)

• No authentication required; ideal for public sites or marketing pages
• Supports geo-blocking (for example, block high-risk countries)
• Visitors from allowed countries access directly, no login

Authenticated Access Mode (allow)

• Authentication required via email/domain or IdP
• Perfect for internal dashboards or private apps
• Geo restrictions stack on top of authentication

Why it matters: DockFlare now aligns perfectly with Cloudflare’s intended behavior, clean, predictable, and secure.

Zone Default Policies & Performance

Wildcard Zone Protection

A new section on the Access Policies page displays all DNS zones and their wildcard protection status. With one click, create a *.yourdomain.com policy to protect all subdomains even future ones.

This serves as a safety net: every subdomain gets a default protection policy automatically.

Migration to Reusable Access Policies

Summary:
DockFlare now creates reusable Access Policies in Cloudflare, replacing older inline policies. This change dramatically improves maintainability, sync accuracy, and scalability.

The Old Way (Inline Policies)

Originally, DockFlare embedded policies directly in each Access Application. It worked, but:

• Rules were duplicated everywhere.

• Maintenance was painful (e.g., update an email in 10 places).

• No centralized overview.

• Policy drift between DockFlare and Cloudflare.

The New Way (Reusable Policies)

Reusable policies scale far better, especially with upcoming DockFlare Agent Swarm mode, where multiple agents report services to a master node. With reusable policies:

• Create once, use everywhere – Apply one policy to many services.

• Single source of truth – Edit once, update everywhere instantly.

• Bi-directional sync – Cloudflare ↔ DockFlare stay aligned.

• Cleaner dashboards – Cloudflare Access view makes sense again.

• Swarm-ready – Centralized management for multi-agent deployments.

In short: reusable policies are how DockFlare should work at scale. Inline rules served early simplicity; reusable rules bring long-term reliability.

API Token Update Required

Add one new permission to your Cloudflare API token for IdP management:

• Account:Access: Organizations, Identity Providers, and Groups:Edit

Without it, IdP creation or sync will fail (existing features still work).
See: [Prerequisites]

Security Testing and Validation

A full audit of all 99 application endpoints was performed for authentication, CSRF, injection, and authorization.

✅ All routes secured (100%)
✅ Strong CSRF protection
✅ XSS, path traversal, and SQL injection mitigated
✅ Sessions managed safely with no leaks detected

Full reports:

• Security Assessment Report
• Security Fix Plan
• Comprehensive Test Results

Important: “Disable Password Login” Setting

This feature is intended to avoid double authentication when DockFlare is already behind an enforced SSO gateway.

Risks when enabled:

⚠️ All API endpoints become unauthenticated.

⚠️ Containers on the same Docker network can bypass Cloudflare Access entirely.

⚠️ The app assumes security is handled elsewhere — dangerous without proper isolation.

Example:

Internet → Cloudflare Access (Protected) → DockFlare ✅
         ↓
Docker Network → Other Container → DockFlare API (Unprotected) ❌

Recommended approach:

1. Use local DockFlare credentials for simplicity, or
2. Configure OAuth/OIDC providers (Google, GitHub, Azure AD, etc.) for secure SSO.

Both options maintain proper authentication while preserving convenience.

Bottom line: Unless your network isolation is airtight, keep password login enabled and use OAuth for SSO.

Breaking Changes?

None. Existing setups continue to work.
DockFlare automatically migrates your groups to reusable policies on next sync.
Manual Cloudflare edits will sync back correctly.

Why This Update Matters

As a daily DockFlare user, I wanted to fix the things that frustrated me most:

“I want to use my Google account for login, but setup in Cloudflare is tedious.”
“I want my portfolio site public, but still block some countries.”

Identity Provider management and access-mode separation directly solve these.
No more dashboard switching. No more unnecessary authentication prompts.
DockFlare now aligns perfectly with how Cloudflare designed these features, flexible, secure, and practical.

Shout-outs and Credits

A huge thank-you to the community for helping shape this release with testing, feedback, and sharp insights:

• @solipsist01 – detailed beta testing and feedback on issue [#250]
• @kernel-sanders – great observations on access rule logic and issue [#261]
• @sidbena – helpful suggestions and testing feedback on issue [#83]
• @johntdyer – excellent input on access handling and usability in issue [#259]

Your contributions directly improved DockFlare’s development. 🙌

Final Thoughts

DockFlare is still a solo-developer passion project, something I genuinely love building.
If you find bugs or have ideas, please open a GitHub issue. Your feedback drives DockFlare’s evolution.

The IdP feature alone took about 80% of this release’s development time, from OAuth flow debugging to security hardening, but it was worth it.

Thank you to everyone using DockFlare and supporting its growth.

Next up:

• Migration assistant for legacy policies
• Policy conflict detection
• More granular access controls
• DockFlare Agent Swarm Mode (in active development)

Stay tuned, and happy tunneling!
Chris

Documentation Updates

The in-app help system and Markdown docs are updated for v3.0.3:

• [Identity Providers]
• [Prerequisites]
• [OAuth Provider Setup]

Full Changelog

For a detailed list of all changes, see the full changelog on GitHub:
CHANGELOG.md

Note: The project site (dockflare.app/docs) will update soon. For now, use the in-app help or Markdown files.

DockFlare v3.0.1 is here, and it's all about tightening up security. I've added OAuth support, letting you protect the main management interface with your existing accounts from providers like Google, GitHub, and more.

✨ New Feature: OAuth Authentication

DockFlare's management interface can now be secured using OAuth 2.0 and OpenID Connect (OIDC). This allows you to delegate user authentication to a trusted third-party provider, adding a robust layer of security to DockFlare itself.

• Secure the Dashboard: Protect access to the DockFlare UI and API, ensuring only authorized users can manage your services.
• Provider Integration: Easily add and configure OAuth providers directly through the settings interface.
• User Authorization: Manage a list of authorized users (by their email address) who are allowed to access the DockFlare dashboard.

OAuth Configuration & Best Practices

To secure the DockFlare dashboard with an access policy (e.g., restricting by IP) and use OAuth, you must create a bypass rule for the OAuth callback path. This ensures that users can authenticate with the provider even if their IP isn't on the allow list, while the main interface remains protected.

Here is an example configuration:

services:
  dockflare:
    image: alplat/dockflare:stable
    labels:
      # Secure the main DockFlare interface with your access policy
      - "dockflare.enable=true"
      - "dockflare.hostname=dockflare.example.com"
      - "dockflare.service=http://dockflare:5000"
      - "dockflare.access.group=team"  # Your custom access policy (e.g., IP whitelist)

      # Create a bypass policy for the OAuth callback path
      - "dockflare.0.hostname=dockflare.example.com"
      - "dockflare.0.path=/auth/google/callback" # The path for your specific provider
      - "dockflare.0.service=http://dockflare:5000"
      - "dockflare.0.access.policy=bypass"

This configuration ensures that your main DockFlare interface is protected, while the OAuth authentication flow works seamlessly without security compromises.

Migration Notes

No breaking changes in this release. All existing configurations remain compatible. The new OAuth feature for the dashboard is optional and can be configured as needed.

Known Issues

• OAuth provider configuration changes may require a brief moment to propagate through the system.
• Ensure OAuth callback URLs in your provider's dashboard match the bypass path in your DockFlare configuration exactly.

What's Changed

Technical Details

• Implemented the OAuth 2.0 / OIDC authentication flow for the main Flask application.
• Added a new UI section in Settings for adding OAuth providers and managing authorized users for the dashboard.
• Created documentation and examples for configuring OAuth, including the callback path bypass method.
• Updated the docker-compose.yml file with commented-out examples for the new OAuth functionality.

Files Modified

• dockflare/app/templates/settings.html - Added UI for OAuth management.
• dockflare/app/web/api_v2_routes.py - Added API endpoints for OAuth configuration.
• dockflare/app/templates/docs/OAuth-Provider-Setup.md - Added setup documentation.
• docker-compose.yml - Added commented OAuth callback examples.

Security

Security Assessment

• DockFlare has undergone comprehensive security testing as documented in security_assessment_report.md. This security assessment will be repeated with every major feature addition to ensure no vulnerabilities are introduced through new functionality.

Security Reporting

• If you discover any security issues or have security concerns, please report them through the project's GitHub issues or contact me directly. I take security seriously and appreciate responsible disclosure.

Thank You

I want to thank the community for its continued support and feedback. Your contributions, bug reports, and suggestions help make DockFlare better and more secure with each release.

A special thanks to everyone who participates in making DockFlare a robust and reliable tool for the community.

Happy tunneling! 🚀

Overview

DockFlare 3.0 is the biggest leap forward for the project to date. The master can now orchestrate Cloudflare tunnels across multiple Docker hosts via the new DockFlare Agent, transforming the UI into a central fleet control room. With Redis underpinning the event bus for enhanced reliability, this release also introduces a hardened security posture and a completely new compose stack. Please review the upgrade notes carefully before pulling the new image.

Highlights

• Multi-Host Management with DockFlare Agent (Beta): Deploy lightweight agents on remote Docker hosts, enroll them from the master UI, and let DockFlare manage their tunnels automatically. (Agent Repository).
• Centralized Agent Dashboard: A new dashboard to generate API keys, enroll agents, monitor heartbeats, assign tunnels, and revoke access, all in one place.
• Remote Manual Rules: Create manual ingress rules from the master UI and apply them to any enrolled tunnel, regardless of where the target container is running.
• Simplified Tunnel Cleanup: The "All Cloudflare Tunnels on Account" panel now includes a one-click delete option to easily remove stale tunnels.
• Redis-Powered Architecture: Redis is now required for caching and the command/event bus, improving reliability and paving the way for future scalability.
• Major Security Hardening: The DockFlare container now runs as a non-root user, significantly reducing its attack surface. This release also includes reveal-on-demand master API keys, a locked-down setup wizard, an encrypted agent key store, and a detailed Security Architecture guide.
• Full Backup & Restore: Download a complete, timestamped archive of your DockFlare instance (including encrypted credentials and agent keys) and restore it via the UI to rebuild a master in minutes. (Backup & Restore Guide).
• Comprehensive Documentation Refresh: The documentation has been updated, including a new Quick Start (Docker Compose) guide for v3 and an expanded Multi-Server & Agent Guide.

Upgrade Notes

1. Create a Full Backup: Before upgrading, go to Settings -> Backup & Restore and click Download Backup (.zip). This archive contains all necessary files, including your encrypted credentials.

2. Update your docker-compose.yml: The v3 release requires a new docker-compose.yml that includes Redis and uses a more secure socket proxy. Replace your existing compose file with the new version provided below. See the Quick Start Guide for more details.

   ⚠️ Click to expand the recommended `docker-compose.yml` for v3

   The stable v3 stack expects Redis and the new network layout. Update your compose file before restarting the master:

   version: '3.8'
   services:
     docker-socket-proxy:
       image: tecnativa/docker-socket-proxy:v0.4.1
       container_name: docker-socket-proxy
       restart: unless-stopped
       environment:
         - DOCKER_HOST=unix:///var/run/docker.sock
         - CONTAINERS=1
         - EVENTS=1
         - NETWORKS=1
         - IMAGES=1
         - POST=1
         - PING=1
         - INFO=1
         - EXEC=1
       volumes:
         - /var/run/docker.sock:/var/run/docker.sock
       networks:
         - dockflare-internal
   
     dockflare-init:
       image: alpine:3.20
       command: ["sh", "-c", "chown -R 65532:65532 /app/data"]
       volumes:
         - dockflare_data:/app/data
       networks:
         - dockflare-internal
       restart: "no"
   
     dockflare:
       image: alplat/dockflare:stable
       container_name: dockflare
       restart: unless-stopped
       ports:
         - "5000:5000"
       volumes:
         - dockflare_data:/app/data
       environment:
         - REDIS_URL=redis://redis:6379/0
         - DOCKER_HOST=tcp://docker-socket-proxy:2375
       depends_on:
         docker-socket-proxy:
           condition: service_started
         dockflare-init:
           condition: service_completed_successfully
         redis:
           condition: service_started
       networks:
         - cloudflare-net
         - dockflare-internal
   
     redis:
       image: redis:7-alpine
       container_name: dockflare-redis
       restart: unless-stopped
       command: ["redis-server", "--save", "", "--appendonly", "no"]
       volumes:
         - dockflare_redis:/data
       networks:
         - dockflare-internal
   
   volumes:
     dockflare_data:
     dockflare_redis:
   
   networks:
     cloudflare-net:
       name: cloudflare-net
       external: true
     dockflare-internal:
       name: dockflare-internal

   Note: Create the external network once via docker network create cloudflare-net. This compose file uses named volumes for data persistence.

3. Create External Network: If you haven't already, create the required external network: docker network create cloudflare-net.

4. Pull the New Image & Restart: Pull the alplat/dockflare:stable image and restart your stack with docker compose up -d.

5. Review Agents Page: After the upgrade, your existing setup will be in single-node mode. Go to the new "Agents" page to start enrolling remote agents.

6. Deploy DockFlare Agents: Deploy the dockflare-agent container on your remote hosts and enroll them using the API keys from the master's Agent Dashboard.

7. Restoring on a Fresh Install? The setup wizard now has a "Restore from Backup" option. Use this to import your backup archive on a fresh installation before creating a new account.

Breaking Changes

• Redis is now required. DockFlare will not start if the REDIS_URL environment variable is missing or if the Redis server is unreachable.
• The docker-compose.yml file has a new structure. The v3 stack requires Redis, a socket proxy, and new volume configurations. Old compose files are incompatible and will fail to start. Please use the new template.
• The embedded cloudflared is for the master host only. For managing tunnels on other hosts, the new DockFlare Agent is the required approach.

Known Issues

• The DockFlare Agent is in beta. Performance with high-volume event streams may vary and might require tuning of settings like POLL_INTERVAL or Redis resources.
• The Master API Key is still used for external integrations. If you have stored this key elsewhere, it's recommended to regenerate it.
• Redis is a critical component. In a single-node setup, ensure you monitor the health of the Redis container. If Redis goes down, agent communication will be interrupted.

Resources

• Quick Start Guide (Docker Compose)
• Multi-Server & Agent Guide
• Security Architecture Guide
• Backup and Restore Guide
• DockFlare Agent Repository
• Full Changelog

Hey everyone!

This update brings a couple of nice quality-of-life improvements that I think you'll like. I've completely reworked the Settings page to make it easier to get around, and I've added a simple version checker so you can quickly see if you're on the latest version.

A Much Better Settings Page

The Settings page was getting a bit long and unwieldy. Finding your way around it should be a lot less of a headache now.

• I've added a navigation menu on the left that sticks with you as you scroll, so you can jump between sections without having to scroll all the way back up.
• You can also now link directly to specific sections (like /settings#general-settings), which is handy.
• I also threw in some smooth scrolling and a little highlighter for the nav links to make it feel a bit more polished.

Know When to Update!

I've also added a new "Version Check" button on the Settings page. It'll tell you if you're running the latest Docker image. It's pretty simple: it checks your image's unique signature (the digest) against the one on Docker Hub. If for some reason it can't do that, it'll just compare the app version with the latest one I've released on GitHub. Now you can easily know if an update is available!

As always, thanks for using DockFlare!
Cheers,
Chris

This release bundles security enhancements from v2.1.6 with the feature and bug fixes from the previously unreleased v2.1.5.

The security vulnerabilities were identified by GitHub's automated Dependabot and code scanning services.

What's New

The old DockFlare logo has been retired and replaced with a brand new animated version in the web UI. It's time to start thinking in tunnels ;)

Security (v2.1.6)

This release resolves several security issues to harden the application and its deployment pipeline.

• Dependency Vulnerability: Patched an outdated brace-expansion npm package by updating it to version 2.0.2, addressing a CVE related to inefficient regex.
• Path Injection: The /help/<path:page> route was hardened against path traversal attacks by implementing stricter path validation using os.path.abspath.
• Open Redirect: The login redirect mechanism was secured by validating the next parameter, preventing redirects to external, malicious sites.
• Information Exposure: Prevented the leakage of sensitive exception details and stack traces in API/JSON responses for the /cloudflare-ping, /debug, and /api/v2/debug-info endpoints.
• Insecure CI/CD Workflow: To adhere to the principle of least privilege, permissions for the GitHub Actions workflow have been explicitly restricted to contents: read.

Features & Fixes (from v2.1.5)

• New - Help Documentation: A comprehensive help section has been added to the web UI, providing users with easy access to documentation and guides.
• Fixed - Country Dropdown Menu: An issue where the country dropdown menu in the Access Group modal was limited to 50 entries has been resolved. Raised in #204 thank you @MattW for finding this bug
• Fixed - UI Refinements: Various minor refinements were made to the web UI for improved usability and a more polished user experience.

How to Upgrade

1. Pull the latest Docker image: docker pull alplat/dockflare:stable
2. Restart your DockFlare container.
3. Open the DockFlare UI in your browser.

As always, thank you for using DockFlare and for your feedback!

Cheers, Chris

Hey everyone,

This release brings some major upgrades to Access Policies, making them much more powerful and flexible. I've also moved them to their own dedicated page to make them easier to manage. A huge thank you to GitHub user @psybernoid for suggesting these enhancements in issue #183!

What's New in v2.1.4:

• Geo-Fencing (Country Blocking): You can now add country-based rules to your Access Groups! This makes it simple to implement geo-fencing and block traffic from specific countries for any of your services.

• Multiple Policies per Rule: This has been a big request. You can now apply multiple Access Groups to a single ingress rule. This is perfect for layering policies—for example, combining a "Family Access" group with a "Block High-Risk Countries" group. This works both in the UI and via a new dockflare.access.groups (plural!) label.

• IP-Based Rules in Access Groups: I've also officially added support for IP-based rules within Access Groups. You can now create policies that allow access from specific IP ranges (like your home or office network) and reuse them across any of your services.

• Dedicated "Access Policies" Page: To support all these new features, I've moved the entire Access Groups manager to its own page in the main navigation bar. This should make creating and managing your reusable policies a much smoother experience.

I'm really excited about these changes and I think they open up a lot of possibilities for securing your services. As always, thank you for using DockFlare and for your feedback!

Cheers, Chris