Modernization Templates in Cloud

Find out how to simply transfer modernization resources when Green Screens Terminal Service is running in cloud environment and developer access is limited.

Green Screens Terminal (GST further in text) support screen and spool modernization through HTML templates and custom scripts.

When GST is used in internal company network it is not a problem. There are few approaches available.

  • Web Admin console simple resource web explorer to transfer file by file which is not the best optimal way to do it.
  • Another option is to give resources to the system admins to deploy them on GST resource directory. But that is also not the best approach. It really depends on security policy, responsibility policy etc.
  • GST resources directory can be shared inside local network no matter if GST is running on Windows or Linux machine. So, anyone with directory credentials can change modernization resources.

The question is how to do it when GS service is running in Cloud Environment?!



Syncthing is a royalty free open source directory syncing tool written in GO with support for multiple platforms. It is just a single EXE file which once started will run as a syncing service. There is an embedded web-based administration console running on localhost used instead of desktop GUI. Admin console is used for all setups including option for joining other computers to the running service based on unique ID.

The Basic principle is very simple. Upon installation, Syncthing will create a unique ID which should be exchanged between two remote instances to mutually authorize them for automatic synchronization. The System works in various networks without too much hassle as it use auto-discovery service through STUN and TUN server protocols. The Next step is to declare a shared folder and that's it.

In cloud environment, GST use Docker Named Volume for data storage. That allows data to be accessed from the host machine. We can install Syncthing as a secondary Docker image also attached to the same named volume and just leave it running.

Once, Syncthing instances are paired, every change in local directory will propagate to the remote server. Every developer will run its own Syncthing service and use unique ID to be authenticated on a remote server.


Another approach is to use Git and Git Server. The Easiest installation is again through Docker. Use one of many available Dockerfiles which has support for Docker Volumes. By starting Dockerized Git Server, the remote user will be able to use the remote modernization resource directory similarly as with GitHub.

Developer will clone repository to local disk, and alter sync and commit local changes to remote repository.


The Main difference between Syncthing and GitServer is that Syncthing is fully automatic, but does not support versioning. While Git server requires manual update but has versioning. To overcome shortcomings, both solutions can be mixed or used separately. For example, use Syncthing for automatic remote syncing, and local Git client (without server) for tracking changes (block syncing. Git directory).

Booth options (Syncthing and GitServer) requires some setups on server side to enable security.  Which approach to use depends on preference. The Bottom line is that there is no limitation. Remote developers can easily change modernization resources and use available open-source versioning and synchronization tools.

GST has one more interesting feature - cluster mode. When cluster mode is enabled, all GST nodes in the same group will me auto-discovered and linked. Any change in one node will automatically reflect in other nodes. Thus, changing modernization template on one node will propagate to all other nodes.

Having this in mind, it is enough to set up Syncthing or GitServer on just one node in the cluster to receive changes for modernization resources, and all other nodes will be updated automatically.