Configure session recording without gateway

Hello Michel,

Thank you for reaching out to us. Why a Gateway is necessary ?

DVLS leverages the Devolutions Gateway as a proxy between Remote Desktop Manager and the target host whenever remote session recording is enabled. The Gateway captures the video stream and stores it. If a session is not routed through a Gateway, DVLS will default to using the Gateway defined at the data‑source level for the recording. There is currently no separate recorder service that can record remote sessions without a Gateway.

Within an entry’s Session recording properties, you can choose “Remote” mode and select which Gateway should be used for recording. As of DVLS 2026.1, the Gateway used for recording can be different from the Gateway used to connect the session, allowing you to centralize recordings on a specific Gateway while other Gateways are used for connectivity.

Storing recordings on a network path :

When configuring session recording, you may select a custom destination to save the recording files. By default recordings are saved locally on the Gateway, but the destination can be changed to a UNC path so that all .webm and .dat files are written to a shared file server. The Gateway service account must have write permissions to this share. (Recordings are not stored in the DVLS database.)

Retention and clean‑up :

Recent releases of Devolutions Server include a native recording retention policy. In the DVLS web interface, Administration → System settings → Recording and enable Gateway recording automatic clean‑up. This setting lets you specify how many days to keep recordings; the scheduler will automatically delete recordings older than the retention period.

Alternatives:

There is also a local session recording mode in RDM that captures the session directly on the user’s workstation. This does not require a Gateway and could be used in isolated environments, but note that local recordings are controlled by the user and cannot be enforced centrally, so they may not satisfy compliance requirements.


I hope this clarifies the current design and limitations. Please let me know if you have further questions .

Best regards,

@Michel Audi

Thank you for your reply. I’m still not entirely clear about the network flow and architecture regarding the recording gateway.

Does this gateway need to be able to reach the remote servers? I don’t fully understand what you mean by “the Gateway used for recording can be different from the one used to establish the connection.”

Is it possible to have a single Gateway object, located in the same network as DVLS without direct access to the target servers, and use it exclusively for recordings?

The end user will have direct access from their workstation to the Devolutions infrastructure and will only use RDM.

Thank you.

Hello Michel,

Thank you for your follow‑up questions. Let me provide some additional context and an example based on what we have in our documentation and internal discussions.

Network flow

• The connection Gateway still proxies the session from the user workstation to the target server. This Gateway must be in the network segment that can reach the remote host.
• When a dedicated recording Gateway is selected, the connection Gateway forwards a mirrored copy of the session stream to the recording Gateway. The recording Gateway writes the captured file to its local or network‑share storage. Because it is receiving a mirrored stream, the recording Gateway does not need direct access to the target servers; it only needs to communicate with the connection Gateway and Devolutions Server.
• The recorded file is then indexed in DVLS so it can be viewed or downloaded from the web interface or Remote Desktop Manager.

This separation allows you to centralize recordings on a Gateway that sits in the same network as DVLS (for example, in your datacenter), while keeping the connection Gateway close to the remote network. The key is ensuring that the two Gateways can communicate securely to transfer the recording stream.

Let me give you example: central recording server for multiple client Gateways

One support case shows a customer with approximately 150 client Gateways deployed in various customer environments and a single recording server Gateway in their infrastructure. After upgrading the recording server Gateway, all client Gateways attempted to push their session recordings to this central Gateway. This illustrates how a central recording Gateway can be used to consolidate recordings from many connection Gateways. In that scenario, each client Gateway establishes the session with its local remote hosts and then forwards the recording to the central recording Gateway. The central Gateway does not connect to the remote hosts directly; its role is purely to receive and store the recordings.

Final considerations

• Recording storage – ensure that the recording Gateway has adequate storage (local or network share) and appropriate permissions.
• Network reachability – the recording Gateway must be reachable by the connection Gateways and DVLS over the configured ports.
• Updates and patches – keep Gateways and DVLS on aligned versions; some customers experienced TLS handshake issues when connection Gateways and the dedicated recording Gateway were on different patch levels.

Additional resources:
For complete documentation and installation details, you may refer to the following resources:

• Devolutions Gateway product page – provides an overview of the Gateway, deployment options and system requirements: https://devolutions.net/gateway/
• Devolutions Gateway GitHub repository – contains release binaries, configuration guidance and the open‑source code: https://github.com/Devolutions/devolutions-gateway

I hope this clarifies how you can centralize your recordings while keeping your session connections efficient. Please let me know if you have any additional questions or would like assistance designing your Gateway deployment.

Best regards,