Isolated Containers

Isolated Containers

Each service inside an environment—such as a database, application server, load balancer, or storage node—runs in its own isolated container, with containers distributed across separate hosts whenever possible.

The platform uses individual role-based containers mainly to support live migration, high availability, and strong workload isolation.

Live MigrationContainers can be moved between hosts without restarting the application.
High AvailabilityContainers are distributed to reduce the impact of a single host failure.
SecurityEach container is isolated so that workloads do not interfere with one another.
On this page

Isolated Containers Live Migration

As application demand grows, the physical server that hosts a container may no longer have enough free capacity. In this situation, the platform can move the running container to another suitable host, typically within about 30 seconds.

Containers live migration to another server
Live migration relocates a running container to a host with sufficient free resources

The application remains active during migration and can continue scaling vertically. When one workload needs additional room, other containers may be relocated to free the required resources. This avoids container restarts and reduces application downtime.

Live migration is also useful during planned maintenance because containers can be evacuated automatically from a physical server before it is taken offline.

Horizontal scaling works in the same resource-aware manner. When new instances are added, the platform selects hosts with sufficient capacity and distributes the new or existing nodes to maintain performance.

High Availability for Applications

The platform improves availability by spreading containers from the same environment across different physical servers. Anti-affinity rules are used to ensure that selected containers are not placed on the same hardware node.

Containers high availability
Anti-affinity distributes containers across different physical servers

As a result, a performance issue or hardware failure on one physical server is less likely to interrupt the entire application.

Security of Isolated Containers

The platform uses operating-system virtualisation to run many containers on one host while keeping them isolated. Containers do not share their application processes or files with neighbouring workloads, so one compromised container does not automatically expose the others on the same hardware node.

Connection note: Because every service runs in a separate container, another node cannot reach it through localhost:port or 127.0.0.1:port. Use the target container hostname, private IP address, or public IP address instead.

This is especially important when connecting an application server to a database container or when linking any two services located on different nodes.

What’s next?