Defguard 2.0 Alpha now available for early user testing
February 10, 2026 • Robert Olejnik
11 min to read
If you would like to know only what’s new and not WHY we’ve changed things, skip the chapter below and go to the next one.
While the 1.x version of Defguard works great and is widely used by our growing customer base, we have observed (and received a lot of feedback), that it had some key shortcomings:
When a product (and customer base) grows, there’s never a good time to make significant changes. But I believe the sooner the better - so we have decided to take a “step back”, freeze major feature development for two months, and address all these issues, to create more solid foundations - so that not only we will deliver a better product but also have a solid ground to work on new features more efficiently.
So here we are with our first (actual) alpha of 2.0 introducing these new features - which address all the above.
Please note that this is an actual alpha and absolutely not meant for production use. There are still some features missing (listed below) and the intention of this alpha is not only to preview the features of 2.0, but hopefully gather feedback from you - our users - so that the 2.0 release will be rock solid.
For that reason we have not prepared all deployment methods - only a simple Docker Compose in order to easily and quickly launch 2.0 and play around with it. More details about this in the documentation.
Also, this alpha will not work with your current data - and there is no migration method (for now - we are working on that).

We have been working on this for at least 6 months - redesigning from ground up components, flows, naming (eg. from now on “proxy” is called Edge Component), so Defguard 2.0 will definitely feel like a completely different product (still familiar hopefully).
From 2.0 core will connect to gateways (and this is the most important and significant change - as current deployments will need to change their firewall rules for gateway<->core communication).
This is necessary not only for security reasons (listed in the section above) but also to provide:
To secure our component communication we strongly recommended implementing a dedicated self signed Certificate Authority - as this provided not only communication encryption but also enabled component authorization on the protocol level (all component certificates needed to be issued by the same CA in order to establish the connection).
With thousands of deployments we saw that this step is one of the hardest to overcome and made initial Defguard deployment really hard. This approach added a “silent requirement” for administrators to manage this CA and raised a number of questions: what about certificate renewal? What about revocation?
It became obvious that Defguard will have to implement a certificate authority to address ease of deployment & securing component communication, but also to solve all the certificate issues for all our admins - soon facing the common issues with certificate renewal, etc. What is also critical - given also our secure architecture, the core will never connect to any component that it has not initialized and secured itself (with certificates) - significantly raising the security bar.
A Certificate Authority is also opening a vast potential for multiple security features to come, like Multi-Factor Authentication with SSL Certificates - which can be placed on device secure storage providing an MFA method that will not require user interaction, and others (not to take over the post with this).
To make our ACLs easier to use and able to handle more use-cases we decided to make their configuration more explicit. We achieved that by extending their configuration to include explicit toggles for matching all addresses, all ports or all protocols when defining a destination.
We also decided to make the distinction between existing types of Aliases (Component aliases and Destination aliases) easier to understand by splitting them into completely separate sections in the UI.
There is also now a specific option for creating an ACL with only pre-defined Destinations.
We believe that those changes allow us to make it absolutely clear in the UI itself what will be the result of applying a given ACL rule. The user does not need to consider what firewall rules will be generated, what will be the interaction between them, how the specific location config will impact them etc.
This is not a visible feature - but changing and implementing a proper session management mechanisms we will be able to introduce a variety of new features like: terminating sessions, implementing time constrained sessions (eg. external workers), etc.
This mechanism also changes our stats component making dashboards and stats fast and more reliable.
We have decided that from 2.0 all configuration will be done in the UI. Environment variables will be supported just for the initial import of settings to the database (allowing for migration from 1.x) - this is necessary for automating many of the processes - especially the deployment that should be easy and done from the UI.
With the new UI we have introduced wizard flows for ease and clarity - allowing us to implement the initial setup wizard (next alpha will bring a migration wizard from 1.x).
We are also introducing a new concept of automated component adopting - where only by giving the location (ip & port) of the component (edge/gateway) the core will automatically do the rest:
Also on any step where/if an error occurs, no need from now on to search for the logs in console - all wizard components at any stage will provide all errors and relevant logs in the UI.
This automation should make Defguard one of (if not the) easiest on-premise security tools to deploy.
The 2.0 release will enable the deployment of multiple gateways and edge components (former proxy) implementing Active-Active High Availability approach for these components.
Hopefully as most architectural changes will be done in 2.0 - we can introduce Active-Active High Availability for the core component (multiple-core deployment) in 2.1.
We consciously are not bringing multi-core HA in 2.0 because:
Multi-Core Active-Active High Availability requires a dedicated and thoroughly tested release.
As mentioned this is an actual alpha release, and is missing:
Even though we do not bring some of the highly requested features yet (give us time for 2.1 ;-)) as you can see all these changes are really significant and will raise the bar of security and ease of Defguard use, management and maintenance.
We hope you will test the release and provide us feedback either by Opening a GitHub discussion or submitting issues (for bugs and missing features).