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.

    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