the soul of babylon cloud

Babylon cloud is eco-sustainable and uses only carbon free energy sources


Software declared to be bug-free are eligible for release


the soul of babylon cloud

Babylon cloud is eco-sustainable and uses only carbon free energy sources


Software declared to be bug-free are eligible for release


the soul of babylon cloud

we are partners of

Heart of the Matter

Babylon Cloud has developed its software services and its functionality around the Zodiac Server System.


Zodiac merges the end-user server functionality (Babylon User Portal - BUP) and the internal resource management, provisioning, monitoring, billing and invoicing functionality (Babylon Admin Portal - BAP) into a single system.

Merging of the two systems allows native integration of the software services with the capacity management systems, enabling a high standard of activity automation at all levels.

Access to server functionalities is centralized via large scale APIs, used extensively by the client interface - both standard and custom - and Babylon User Portal. The unified access to the server functionalities allows management of different needs and functions within a single infrastructure, without any exceptions.

The overall system is built to operate as a "network", allowing each component at each level to connect with any other component of its upper and lower levels. This model enables the system to operate without interruption or resources unavailability, even partial ones, and even in case of component loss. It differs from all systems that generally operate within a resources chain, each of which depends on the previous one, such that the failure of one component affects the entire resource chain.

babylon box

Zodiac Server System relies on a hardware base named Babylon Box (BBox), a machine used to perform all the computational activities of the system. It is a unitary machine divided into various virtual machines "specialized" for different activities essential for running the system. Division of the tasks into virtual machines allows granular management and, at the same time, horizontal scalability. Moreover, since all virtual machines of the same type are interchangeable, they all work together to manage the entire activity.

babylon cluster

Starting from version 3.0 of the Babylon Cloud system, the BBoxes are structured in Babylon Clusters, each consisting of four BBoxes distributed on two nodes and redundant on the other two (2x2). The capacity of the BBoxes within a BCluster scales horizontally; BClusters increase the capacity by simply adding new BBoxes, or by joining new BClusters and increasing the system's overall capacity.

babylon storage

BBoxes use Babylon Storage (BStor) to store managed data. BStor, introduced in 2019 to replace hardware currently present in the market, are positioned in pairs within the infrastructure. Each BStor, member of the pair, is installed in RAID6 mode (the pair is installed in RAID61 mode, which is the mirror of RAID6), all data is preserved from the loss of 1 or 2 disks. Therefore, each pair has a fault tolerance of 5, being able to lose 3 disks on one BStor and up to 2 on the second one, which is higher than the triple-copy configuration, within which the fault tolerance is 2.

Babylon Cloud's Object Storage optimizes software components to occupy less and less computational and bandwidth resources, further reducing consumption, with the sub-strategies of information distribution and asynchronous management

Development and release strategy

The software development strategy is based on the principles of Optimisation, Control and Uniformity.


Each component is designed and developed to provide maximum functioning per unit of cost (weight, footprint, number, power consumption, investment), and be redundant to enable scalability and sustainability (high resilience and redundancy); this method ensures an infrastructure with very low impact per unit of resource.

All software components are progressively optimised after development processes to occupy less computational and bandwidth resources, further reducing consumption, with the sub-strategies of information distribution and asynchronous management.


In Babylon Cloud systems, every destructive activity must be additionally confirmed to become executable. This means that each cancellation command is aimed to trash the object of the cancellation, which must be permanently deleted afterwards, to be destroyed. In addition, all information sent to the server is centrally re-checked for consistency; the server discards all inconsistent information.


Functionality evolutions are managed centrally as new functionalities of the already existing system in its entirety, guaranteeing no exceptions to be managed at server levels. Furthermore, consistent management of all the functionalities provided, the objects handled, and the services delivered by the software are optional functions that are part of a unique system, thus preventing errors in exception management.

Babylon Cloud releases are managed by the Customer Operations (CO) Team. The same Team provides end-user support and performs massive, distributed testing per each release. Only software declared bug-free by the CO Team (bug-free at lab level) is eligible for release.



The cornerstone of Babylon systems is extreme resilience.

Elevated redundancy level

Babylon Cloud systems have an elevated redundancy level. Component redundancy allows major fault tolerance, meaning any component can be fixed while the system continues to operate. Moreover, it guarantees further failure tolerance, thus preventing the system from a condition where the potential additional failure could cause loss or unavailability of data or services (single-point-of-failure). The extreme redundancy of components at all levels, together with our "network" system, enables the availability of Babylon Cloud's services at very high levels and meets the goal of zero data loss, which has been maintained continuously since the Zodiac full-stack system came into existence (2017).

Resources redundant online

Babylon Cloud's strategy is to have all resources redundant online in the system; this allows zero recovery time and no data loss at the recovery point (RTO and RPO). As a result, the system does not have to recover errors and failures, but rather it tolerates them, keeping secondary resources constantly online, thus guaranteeing they can seamlessly take the place of any primary resources that have failed.

High resources distribution

High resources distribution, networked together at the same level and connected to all resources of lower and upper levels, allows the distribution of API calls and I/O, optimising the throughput and minimising the latency of system responses simultaneously. In addition, the high use of caching strategies and asynchronous computation further contributes to latency minimisation.

Environmental sustainability is achieved through overbooking and deduplication, developed in-house and based on the high-performance infrastructure


Our strength lies in our digital resources.

Green cloud

The two principles of overbooking and deduplication are among the pillars of the Babylon Cloud system's high level of Environmental Sustainability. In addition, Babylon Cloud's production systems are provided exclusively from renewable energy resources, enabling the company to achieve its goal of zero environmental impact. From the end of 2021, with the inauguration of the new Data Center in Rome, Italy entirely powered by photovoltaic solar energy, the whole company can be declared "carbon-free".


One of the cornerstones of Babylon Cloud's systems strategy is to minimize system usage through overbooking strategies, that allow resources allocation at the moment they are used, and not at the time of service allocation. Overbooking, among other tools, stipulates the basis for very low electricity consumption (as of today about 1.27Watt/Tb nominal/day), which would be impossible to achieve otherwise.


Deduplication by blocks helps reduce storage and network bandwidth usage. In addition, it enables the system not to send deduplicated blocks and not to store twice the information already written.

start your digital transformation