Can SEAL be installed on a local engineering server to run a SEAL script?

[Niklas]

We’re looking into running a SEAL script on a site’s local engineering server (no default internet access).
Is this setup supported, and what are the requirements or limitations—especially regarding login and network configuration?

[Benji]

@Niklas currently this is not supported. That said, it has been requested various times, and we're currently looking into how we can accomodate for this, and it is planned to be made possible in some way in a near future.

[StefanLundin · Accepted solution]

I'd like to expand on this topic since it's been raised several times.  

Today temporary internet access is required during the login process, as SEAL authenticates the user online. After successful login, the connection can be shut down, and SEAL will continue to operate offline for up to 14 days. The login process requires port 443 to be open. If internet access is restricted, local IT may need to temporarily allow this port.
But as Benji mentioned we are looking into this specific topic for a future release. 

SEAL can technically be installed on a local engineering server to run a SEAL script. However, this setup is not officially tested or supported by us. Some users have managed to get it working on server systems. We are currently evaluating whether to support server installations in future versions.

[Niklas]

Many thanks for the prompt and comprehensive response!

In this case the local IT is (obviously) very strict with allowing outbound traffic. They are willing to make an exception if they now the exact IP's where the SEAL wants to connect to. Could you share the information of the server IP's where SEAL application wants to communicate before and during the Login process?

Thanks for your support!

[StefanLundin]

As of today, SEAL requires internet access during the login process, and unfortunately, we cannot provide a list of specific IP addresses. The authentication is handled through Schneider Electric’s global login infrastructure (IDMS/PingID), which uses distributed services that may resolve to different IPs depending on location and network conditions.

What you're trying to achieve—running SEAL in a closed environment with tightly controlled outbound traffic—is not currently supported. We understand the need and are actively looking into solutions for such scenarios in future releases, but for now, temporary internet access with port 443 open is required, and we cannot define an IP-level whitelist.