In the 1.6.0 release of the agent, we have introduced the test mode, a new way to help you test and try your redirect rules before they are published to your production servers. Historicaly, it was not possible to log the traffic from instances configured with this "test mode", which was meant for pre-production or testing servers - we estimated that it did not make much sense to log traffic from these platforms.

However, due to several requests on this topic, we have changed the behavior in the recent 2.1.0 release of the agent, and we have made it possible to enable HTTP traffic logging from instances using the "test mode". From now on, you can get a view of your live HTTP traffic logs even on "test" instances.

Another much-demanded feature about instances was the ability to configure their behavior directly within the agent.yml configuration file. We have introduced, also in the 2.1.0 release of the agent, the new test_mode and logging configuration, which can be used to statically set the configuration of agents server-side. If those keys are defined, you will not be able anymore to change this setting in the instances management interface:

This morning, we have launched an improved way for managing roles within organizations and projects. In particular, these enhancements allow for the creation of "contributor" and "financial" users, with restricted permissions.

financial users can access billing information and invoices - this role is designed to fit the requirements of financial departments, which usually do not require access to all the project functionnality.

contributor users can create new rules or modify existing ones, but they can not publish rules, which means that they do not have direct access to the redirection rules that are executed on your public website. This is especially useful to allow an external SEO consulting company to contribute new redirect rules for your website, while having a way to control upstream what is going to be changed on your website.

Our documentation about permissions has been updated to reflect these changes.

Some times ago, we have been made aware that several customers found it difficult to figure out the concept of rules "rank".

The "rank" of a rule is helpful to elect the redirection to execute when several rules match a given request. However, many users were hesitating when configuring the rank: was the lower rank executed first, or after? Several other concerns about the "rank" have been raised, among others the fact that the rank could not be lower than 0, thus forbidding to insert new rules infront of already existing 0-level rules.

Therefore, we have renamed and migrated the "rank" model to a "priority" property, that can be attached to the redirect rules of your projects just like the rank did before. The legacy rank was somehow limited in the range 0-32768, so we have transformed it into a "priority" property, that can range from -32768 to 32767.

From now, if two redirection rules match a request, then the one with the higher priority will be applied. We have migrated all the existing redirection plans, so you do not notice any issue with existing rulesets.

As before, you can change the priority of each rule inside the rule creation/edition form. You can also add example requests to your rules, and have the relative priorities of rules be auto-defined when tweaking the rules order for a given example. Please read our guide about creating rules to learn more!