AIRShip ships files between Locations. Locations are managed by our Shipping Agent application, installed on each computer involved in shipping. The Shipping Agents do the actual shipping, between the Locations they are managing.
In this situation the Locations are acting as Endpoints in the delivery chain. However, an AIRShip Location can also be set up as as a Transit Hub, which acts as an intermediary, providing a stepping stone for the delivery of files. The transitory files are stored encrypted on the Transit Hub, and are deleted when they have been delivered to the destination Endpoint Location. Using a Transit Hub is the best way to resolve the problem of a computer configured to use AIRShip not being able to receive inbound connections on port 4115 (the default port via which our software communicate). Transit Hubs can also act as edge devices, managing the flow of data in/out of a facility, and are also capable of bridging public/private networks (where this is desirable). We explain Transit Hubs in more detail in the Tech specs section of this website.
We host our own Transit Hubs on AWS instances. Most of these are not used constantly, so we usually turn them on and off manually, which is somewhat inconvenient. Therefore, we thought it would be helpful to develop the ability for AIRShip to turn on and off AWS instances automatically, so they can be turned on to carry out AIRShip Workflow Tasks, and turned off when these complete.
We are in the process of integrating this functionality into AIRShip, and aim to make it available in the first incremental release following our launch of AIRShip v2.3.