📦 Cloudomation On-Premise Installation Guide
This guide outlines recommended practices for installing and maintaining Cloudomation in an on-premise environment. Following these guidelines ensures system stability, performance, and a smooth update process.
✅ System Requirements
Supported Platforms
Cloudomation must run on a Linux-based virtual machine (VM) with Docker support. Supported distributions include:
- Ubuntu (20.04+)
- Debian (10+)
- CentOS / RHEL (7+)
- Other modern distributions with Docker support
ℹ️ Windows Server is not supported natively. Use a Linux VM or WSL2.
Hardware Requirements
| Resource | Recommended |
|---|---|
| vCPUs | 4+ |
| RAM | 8+ GiB |
| Disk | 50+ GiB (SSD preferred) |
⚠️ Disk requirements depend on usage. High activity setups may need additional storage for logs, history, and integration data.
Software Dependencies
The following tools must be installed on the VM:
docker(v20+)docker-compose(v1.29+ or v2.x)unzip
🔧 Installation Recommendations
- Install Cloudomation on a dedicated VM to avoid resource conflicts.
- Enable network access to:
- The Azure Container Registry and Docker Hub during installation
- All third-party systems that Cloudomation integrates with during operation
- The Cloudomation Web UI (must support WebSocket connections)
🔄 Backup & Rollback
Before each upgrade:
- A full VM-local backup of the database and configuration files is automatically created
- This allows for rollback in case of a failed upgrade
- Customers are advised to regularly export their content (flows, scripts, configurations) manually or via automation
- Especially before updates
🧪 Test Workspace Setup
Why a Test Workspace?
Due to the flexible and highly integrative nature of Cloudomation, we strongly recommend that customers maintain a dedicated test workspace. This helps ensure updates and changes are safely validated before being applied to production.
🛈 A test workspace is included in the Standard and Premium licenses.
Not included in the Starter license.
Test Workspace Requirements
| Parameter | Recommendation |
|---|---|
| Environment Type | Separate VM (same spec as production) |
| Resources | Match production specs as closely as possible |
| Content | Clone or synchronize from production (see note below) |
| Integrations | Use test instances of integrated systems if available |
| Testing | Use a dedicated "test suite" of automation flows |
| Access | Internal only (unless integration testing requires external access) |
⚠️ Important Note on Cloning Content:
When cloning or synchronizing content from the production workspace, customers must pay close attention to active schedules and third-party integrations:
- Schedules should only be active if the test workspace is connected to third-party test systems.
- If the content includes direct access to third-party production systems, it may be difficult to distinguish whether an action was triggered from the test or production workspace.
- Having both workspaces interact with the same external resources may lead to conflicts or unintended side-effects.
Customers are responsible for ensuring that test environments are isolated appropriately to avoid overlaps and interference.
🧪 The test workspace should be updated before production. Validate updates, resolve any deprecation warnings, and verify integrations before rollout.
📤 Update and Compatibility Process
Update Cadence
- New major versions are released approximately twice per year
- Cloudomation officially supports the latest and previous major version
Pre-Update Checklist
-
Check logs for deprecation warnings
- Deprecated features are removed in the next major version
- Warnings are issued one major version in advance
-
Export your content (flows, scripts, configurations)
-
Run updates first on the test workspace
-
Validate key workflows and integrations
-
If successful, proceed to update the production workspace
🔐 Summary of Best Practices
| Area | Recommendation |
|---|---|
| Deployment | Use a dedicated Linux VM with Docker |
| Resource Planning | Allocate 4+ cores, 4+ GiB RAM, 50+ GiB disk |
| Backup | Use internal backup + regular content export |
| Testing | Maintain a near-identical test workspace |
| Updates | Test first, check logs for deprecations, then deploy |