Environment:
- Devolutions Server container, devolutions/devolutions-server:release-2026.2 (client build 2026.2.15.0)
- Primary node: Azure App Service for Linux Containers, Azure SQL Database backend, fronted by Azure Front Door (custom domain)
- Planned second node: on-premises, same network as our Active Directory, connecting to the same Azure SQL database over a planned site-to-site VPN
Goal: We need PAM features that depend on reachability to our on-prem Active Directory. Since the Azure-hosted node can't reach on-prem AD directly, our plan is to run a second DVLS Server instance on-prem pointed at the same Azure SQL database as the Azure node so the on-prem node handles AD-dependent PAM operations while the Azure node continues serving cloud/remote users, both against one shared vault.
Questions:
1. Is running two DVLS Server instances concurrently (not active/passive failover — both actively serving traffic to different user populations) against the same database an officially supported topology? If
not supported today, is there a recommended alternative for giving a cloud-hosted DVLS instance access to an on-prem AD for PAM without a second live node?
2. If concurrent nodes are supported: does each node require the identical encryption.config/DVLS_ENCRYPTION_CONFIG_B64 to correctly decrypt shared vault data, or is there a different mechanism for multi-node encryption key distribution? fnaf
3. We used Set-DPSAccessUri with -AdditionalAccessURIs to register a second valid external hostname against one database (needed to fix an OAuth/AccessUri mismatch behind Azure Front Door). Is this the correct/intended mechanism for a node serving multiple hostnames, or is it meant only for a single node with multiple front-end domains, not genuinely separate server instances?
4. Are there known constraints around session affinity, caching, or concurrent-write conflicts when two nodes serve live traffic against one database simultaneously?
5. Is there a licensing consideration for running multiple concurrent instances against a single license/database?
@kseay1Hello
1. Yes, this is supported. Devolutions supports both high-availability/load-balancing and manual-failover topologies. However, running two active nodes does not guarantee that AD-dependent PAM operations will execute on the on-premises node. The Scheduler is automatically elected, and only one Scheduler is active at a time. This could cause problems with scheduled password rotation, checkout expiration, and automatic check-in if the active Scheduler cannot reach AD.
2. Both container instances must use the identical DVLS_ENCRYPTION_CONFIG_B64 value. There is no automatic key-distribution mechanism. Both nodes need the same encryption keys to access the shared encrypted database correctly.
3. Additional Access URIs: Yes, Set-DPSAccessUri -AdditionalAccessURIs is the intended mechanism. However, both nodes must have the complete list of valid hostnames configured. Otherwise, the node starting most recently could overwrite the shared OAuth redirect URI configuration.
4. Session affinity and caching: Session affinity is recommended and should be handled by the load balancer. There is also a known caching limitation: settings and domain configurations can remain cached for approximately five minutes on each node. Changes made on one node might not immediately be reflected on the other. Devolutions support did not report a confirmed concurrent-write problem but acknowledged that this scenario had not been independently verified.
