Network environment requirements
The OutSystems services use the following ports:
12000 - OutSystems Deployment Controller Service
12001 - OutSystems Deployment Service
12002 - OutSystems Scheduler Service
For each server of an OutSystems environment,
- must resolve to 127.0.0.1 (IPv4)
- must be accessible by HTTP on 127.0.0.1
It's possible to configure some of the ports used. Check the Configuration Tool documentation to learn more.
The table below details the ports that need to be accessible in each server of an OutSystems environment for publication and runtime connectivity. If a server has both roles (Controller and Front-End), then consider the ports for both profiles on that server.
|SysOps||Server||22/3389||TCP||Access the server through SSH or Remote Desktop|
|End Users||Front-End||80||TCP||Applications HTTP access|
|End Users||Front-End||443||TCP||Applications HTTPS access (always required for Mobile and Reactive Web apps)|
|Development Tools||Front-End||80||TCP||Deploy applications to the environment|
|Development Tools||Front-End||443||TCP||Deploy applications to the environment|
|Front-End||nativebuilder.api.outsystems.com||443||TCP||Generate Mobile apps (more info)|
|Front-End||Controller (by default)
— Depends on where the Cache Invalidation Service/RabbitMQ is installed.
|5672||TCP||Cache Invalidation Service connection|
|Front-End||Controller||12000||TCP||OutSystems Deployment Controller Service connection|
|Front-End||SQL Server / Oracle||1433 / 1521||TCP||Database connection|
|Controller||Front-End||12001||TCP||OutSystems Deployment Service connection|
|Controller||SQL Server / Oracle||1433 / 1521||TCP||Database connection|
The following table lists the ports that should be open to correctly monitor OutSystems. A failure on opening these ports may result in warnings and error messages.
|Front-End||Controller||12000||TCP||OutSystems Deployment Controller Service Monitoring|
|Front-End||Front-End||12001||TCP||OutSystems Deployment Service Monitoring|
|Front-End||Front-End||12002||TCP||OutSystems Scheduler Service Monitoring|
|Controller||Front-End||12001||TCP||OutSystems Deployment Service Monitoring|
|Controller||Front-End||12002||TCP||OutSystems Scheduler Service Monitoring|
In case you are using a hybrid infrastructure where some part is in OutSystems Cloud and another is managed by yourself, it's possible to create a VPN connection between the environments (hybrid configuration is only supported in OutSystems licenses purchased before January 2020). Learn more in the Amazon documentation.
If you are using a container-based hosting technology for deploying OutSystems applications, your network topology and firewall configuration should fulfill these requirements:
The Container Runtime network endpoint must accept connections on port 80.
The platform database and logging database addresses (and ports) must allow connections from the Container Runtime.
The Platform Server Deployment Controller port (12000) must allow connections from the Container Runtime.
The Cache Invalidation Service (RabbitMQ) port (default is 5672) must allow connections from the Container Runtime.
SSL offloading is required to run applications in containers. Follow the instructions presented in End-to-end SSL and SSL Offloading. Note that you do not need to follow the step instructing you to add a new record to the
OSSYS_PARAMETER table, since the platform already does this step for you when deploying to containers.
Even though OutSystems is built to scale horizontally, you need to consider the network latency between the database server, the Platform Server, and the front-end servers. For this reason, it’s advisable to have all servers that make up an environment, running under the same provider.
As an example, if you are using Amazon RDS as your database server and running the Platform Server on your own infrastructure, the application’s performance will be degraded.
Experience Builder must be able to connect to the environment where you want Experience Builder to publish apps. Ensure that the front ends of that environment accept inbound connections from the Source address.
Alternatively, ensure that the front ends of the environment used with Experience Builder accepts connections from the IP addresses in the Notes. These IP addresses are subject to change.
Workflow Builder must be able to connect to the environment where you want Workflow Builder to publish apps. Ensure that the front ends of that environment accept inbound connections from the Source address.
Alternatively, ensure that the front ends of the environment used with Workflow Builder accepts connections from the IP addresses in the Notes. These IP addresses are subject to change.
To use IT user governance based on LifeTime teams, Workflow Builder needs to be able to connect directly to LifeTime via TCP using HTTPS, port 443.
Network infrastructure requirements
To use LifeTime to manage your application lifecycle, you need to have bidirectional communication between the front-end of the LifeTime environment, and all other servers (front-ends and deployment controllers) of your OutSystems Infrastructure.
In case HTTPS isn't supported, LifeTime communicates with the environments it manages by HTTP.
Applications must be deployed as follows:
|LifeTime Front-End||Environment Front-End||80||TCP|
|LifeTime Front-End||Environment Front-End||443||TCP|
|Environment Front-End||LifeTime Front-End||80||TCP|
|Environment Front-End||LifeTime Front-End||443||TCP|
Depending on the version of the Architecture Dashboard probe, ensure that one of the following destination endpoints is reachable:
|LifeTime Front-End||architecture.outsystems.com/Broker_API/rest/ArchitectureDashboard||443||TCP||Version 4.0 or higher of the Architecture Dashboard LifeTime probes.|
|LifeTime Front-End||architecture.outsystems.com/Broker_API/ArchitectureDashboard.asmx||443||TCP||Version 3.0 or lower of the Architecture Dashboard LifeTime probes.|