Skip to main content

IaaS platforms

OroCloud supports two IaaS platforms out of the box: Both platforms group resources into a GCP project or OCI tenancy. Resources are optimized for communication within the same region and distributed across multiple availability zones for redundancy.

Data center locations

Google’s and Oracle’s data centers are located in the US, South America, Europe, and Asia. IaaS providers organize resources into zones or availability domains to ensure:
  • Fault tolerance — each zone/domain is isolated; it is highly unlikely for two zones to fail from the same cause.
  • Fast connectivity — latency of under 5ms between zones in the same region.
  • Global distribution — on-demand resource distribution to multiple regions for protection against regional disasters.
In OroCloud, you choose the IaaS region(s) for your environment. All resources reside in the same geographic region for optimized response time but are distributed across multiple zones for fault tolerance.

Infrastructure components

CDN and load balancing

OroCloud offers two CDN and load balancing options depending on the service provider:
Google CDN uses globally distributed edge servers integrated with GCP logging and monitoring services.The GCP load balancer distributes traffic between web nodes, providing basic DDoS mitigation.
GCP CDN and load balancing is available only for GCP-hosted environments.

Web nodes

Inbound traffic is balanced between web nodes to enable on-demand scaling, fault tolerance, and DDoS protection. At least two web nodes are allocated in different availability zones/domains.

Search index

Oro application data is indexed and stored in Elasticsearch, which provides cluster architecture and the ability to add nodes to spread load and enhance reliability.

Database

Application data is stored in PostgreSQL. Each environment has at least two PostgreSQL instances — one in the main zone and one in the secondary zone. If the main instance becomes unresponsive, the environment automatically fails over to the secondary zone.

Message queue

Oro application uses RabbitMQ as its message queue broker for asynchronous processing. RabbitMQ supports cluster architecture and tolerates individual node failures. The proprietary consumer service runs as a daemon and handles all queued messages. It is scalable and can run as parallel processes on multiple hosts to handle large message volumes.

SMTP relay

The dedicated SMTP Relay service sends emails from the OroCloud environment using a set of mail relays with different priorities — similar to a master-master replication setup, with more than one active service handling requests.

Cache

Oro application uses a Redis cluster to store cache. Redis Sentinel provides high availability through automatic failover and failure detection.

File storage

OroCloud environments use GridFS clustered file storage for application files related to user data (attachments, images, documents).

Backups and restore

Backups include the database dump, media files, and either the application source code or the repository commit hash.

Backup schedule and retention

Oro maintains a regular backup process covering both database and media content.
Backup typeRecovery Point Objective (RPO)Retention
Hourly1 hourLast 7 days
WeeklySundayLast 4 weeks
MonthlyLast Sunday of the monthLast 12 months
You can list available backups and restore to a specific recovery point using maintenance tool commands.

Encryption

All backed-up data is encrypted using AES-256 keys.

Restore time objective (RTO)

Restore time varies from 30 minutes to a couple of hours depending on the amount of data to be restored.

Maintenance

To maintain optimal performance, reliability, and security, the OroCloud team performs regular environment maintenance during predefined maintenance windows. For critical infrastructure security patches or urgent maintenance, the OroCloud Services team reserves the right to perform unplanned maintenance windows. The Oro team will notify the environment owner in such cases.

Disaster recovery

Disaster Recovery (DR) is the process that allows the Oro IT support team to recover OroCloud service operations during a total failure or major malfunction of main hosting resources.

Criteria for disaster recovery

An event is classified as a disaster recovery scenario when:
  • The IaaS Region hosting a particular OroCloud environment is unavailable and is not anticipated to recover within the next hour.
  • The OroCloud environment is inaccessible due to network issues related to the IaaS region’s geographical location.

Disaster recovery objectives

  • Recovery Point Objective — The instance is restored from the last daily backup.
  • Minimal Recovery Time — At least 60 minutes to restore service availability after DR is approved.
  • Maximum Recovery Time — Depends on backup volume and integration complexity.

Disaster recovery principles

Oro uses a cold disaster recovery location — no resources are allocated or billed until DR is initiated. When a disaster occurs at the primary location, the OroCloud environment is re-created in a different IaaS Region unaffected by the disaster. Oro provides both primary and DR IP addresses during onboarding. Add both to any external whitelists.

Disaster recovery flow

1

DR approval

Customer Support contacts the environment owner’s technical contact to request DR approval.
2

Infrastructure provisioning

The OroCloud SWAT team provisions the DR infrastructure and restores the latest backups.
3

DNS update

The DNS record is updated to point to the new location (if possible).
If the Oro application uses a customer-managed domain, the DNS record update must be handled by the domain owner.
4

Health check and notification

Health checks are performed for the restored instance. Once the instance is up and running, Customer Support notifies the technical contact.

System configuration

System configuration is managed as code via the configuration management tool (Puppet).

Build docs developers (and LLMs) love