Skip to main content












Deploying to Containers

  • Edit
    Collaborate with us
    Edit this page on GitHub
  • Container deployment is available as an Early Access Program.

    Application deployment to containers is recommended for advanced users that are familiar with container-based solutions, their architecture and their network requirements.

    Before you start, make sure that:

    You can deploy OutSystems applications to containers based on Windows Server. OutSystems support different hosting technologies like Docker and Pivotal Cloud Foundry, as well as other Docker-based hosting technologies like Amazon ECS and Azure Container Service.

    This deployment possibility allows you to benefit from the continuous low-code delivery provided by OutSystems together with the advantages of using container-based public or private clouds. These benefits include resource efficiency and density, effective isolation, ability to achieve horizontal scaling easily and rapidly, which are usually associated with later stages in an application lifecycle (e.g. Quality Assurance and Production).

    Containers are supported in all non-development environments. This allows you to take advantage of the fast development cycles provided by OutSystems in earlier stages of your application lifecycle while being able to test your application (e.g. in Quality Assurance environment) running on a container similar to the ones available in your Production environment.

    The OutSystems deployment unit for containers is the application, in which all modules from an application will be deployed to the same deployment zone. Additionally, OutSystems only supports one application per container.

    The container model is suitable for a microservices architecture in which an application consists of multiple independent subsystems in the form of autonomous services that can be developed, tested, versioned, deployed and scaled independently.

    While it's possible to deploy a monolithic application inside a container, this is usually not a recommended architecture. The downside of this approach becomes evident when the application needs to scale, especially when this need only affects a few parts of the application.

    Instead, the typical recommended architecture for applications in containers is one where the application consists of a set of services that implement a specific end-to-end domain or business capability within a certain context boundary, which can be developed autonomously.

    In OutSystems, the recommended way to take advantage of containers is to create small applications that own their related domain data model and domain logic (to achieve the "sovereignty" and "decentralized data management" goals), i.e. applications that on their own are much smaller than a business application and are responsible for providing services to other applications, e.g. via REST APIs.

    If your application has many modules, this can be a sign of a poor architecture. You should refactor your application and split it into smaller applications, so that the overall architecture of these smaller applications is more scalable and can take better advantage of containers.

    To learn more about this topic, check for example the following articles:

    "Architecting Container- and Microservice-Based Applications" (by Microsoft)
    While oriented at a much broader scope of applications, they are also applicable to OutSystems applications. The following sections are particularly interesting for building a container-bound application with the right architecture: "Challenges and solutions for data management", "Identify domain-model boundaries for each microservice" and the "Creating composite UI based on microservices, including visual UI shape and layout generated by multiple microservices".
    "Docker Reference Architecture: Designing Scalable, Portable Docker Container Networks" (by Docker)
    Provides a good starting point for a solid architecture design.


    OutSystems applications deployed to containers have some limitations in terms of application features and available operations.

    Unavailable Application Features

    You will not be able to deploy into containers any application with the following functionality:

    • HTTP Security with client certificates;
    • Integrated Authentication on UI flows or screens;
    • Integrated Authentication on SOAP web services;
    • Applications using DB2 databases;
    • Applications or modules using SEO rules.

    In addition to the recommended practice of keeping system applications like Service Center and LifeTime in the "Global" deployment zone, you will not be able to associate or deploy system applications to deployment zones whose hosting technology is containers, or to deployment zones that do not include any front-end servers.

    Using the localhost address to render pages or access any endpoint from other applications will not work. For an application running inside a container, localhost refers to the container itself. Since in OutSystems there's only one application per container, any referenced application will not live in the same container. Also, due to the nature of containers, there's no guarantee that the containers for two applications will be on the same server, which means that applications must not refer to each other by using localhost or the address of the container engine host; the developer must always use the address of the deployment zone of the desired application.

    Unavailable Operations

    Some operations are not available when an application is set to be deployed to a deployment zone configured with a container-based hosting technology.

    In Service Studio you will not be able to:

    • Create a new module in a container-bound application;
    • Move a module from one application to another one if any of them is a container-bound application;
    • Perform 1-Click Publish of a module in a container-bound application;
    • Perform 1-Click Publish of a container-bound application;
    • Delete a module that belongs to a container-bound application;
    • Debug a module in a container-bound application (debugging must be done in an environment where the application is not in a deployment zone using containers).

    In Service Center or using the OSPTool the following operations will not be available:

    • Perform 1-Click Publish of a module in a container-bound application;
    • Delete a module that belongs to a container-bound application;
    • Download or publish a solution containing a partial subset of the modules of a container-bound application.

    In addition, in Service Center it's not possible to:

    • Set a deployment zone as the default zone when its hosting technology is container-based;
    • Delete an application manually deployed to a container (check this procedure that enables you to delete such an app).

    Application Scheduler Service in Containers

    Each container-bound application has an Application Scheduler Service, which is bundled together with the application inside the container. If any problem occurs with this service, the container will stop.

    Asynchronous tasks like BPT and timers are supported in container-bound applications through this service. It is very similar to the Scheduler Service provided with the platform, but it is only responsible for handling the asynchronous tasks of the application running inside the container.

    Articles in this Section