General Concepts
Hardware Requirements: General Concepts
The simplified platform architecture can be viewed as a top-to-bottom model that connects the user-facing services, platform infrastructure, compute provisioning layer, and underlying hardware.

Cluster Levels
Infrastructure and User Hosts
- Infrastructure hosts (infra nodes): servers that run internal PaaS services.
- User hosts (user nodes): servers that run customer applications inside containers or virtual machines.
Cluster Components
In addition to compute hosts, the cluster requires networking, DNS, and security resources that connect all layers into one operational platform.
- An external network, normally reachable from the Internet, with one or more routable public IP ranges.
- An isolated internal network dedicated exclusively to the PaaS cluster and using private IP addresses.
- A DNS zone controlled by the platform, including the platform and region domains.
- Wildcard SSL certificates for infrastructure and end-user domains.
High-Level Requirements
The following resources are required for an initial Virtuozzo Application Management deployment. These values are intended for launch and early workloads; additional capacity may be required as the platform grows.
1. Hosts
Provide bare-metal servers or virtual machines according to the selected installation scenario.
x86-64-v2 instruction set or a newer version.2. External Network
- Provide an external or pseudo-external NAT network accessible to platform customers and visitors.
- Assign one or more routable public IP ranges.
- Ensure fast access to external repositories such as Docker Hub and Virtuozzo repositories.
- Verify that the service provider can supply at least 300 Mbit/s of Internet bandwidth for installation and normal platform operations.
3. Internal Network
- Use a private network isolated for platform traffic only.
- Provide one or more routable private IP ranges.
- A single
/8or/16address space is preferred.
4. DNS Subdomains
Configure short DNS domains that are controlled by the platform:
*.{platformDomain}— the main platform domain, separate from the company website domain. Typical examples includeapp.{platformDomain}for the user dashboard andjca.{platformDomain}for the administration panel.*.{regionDomain}— a unique domain for each platform region. End-user environments are automatically assigned names in the form{envName}.{regionDomain}.
Use a different domain for the platform and for each region. This reduces the risk that abuse originating from one customer environment could affect the reputation or availability of the entire platform domain.
Example Domain Structure
Platform domain: mypaas.com Dashboard: app.mypaas.com Cluster admin: jca.mypaas.com First region: euregion.com Environment example: awesomesite.euregion.com Second region: usregion.com Environment example: supershop.usregion.com
{nodeId}— the container identifier, such asnode12345.{envName}— the environment name selected by the user.{regionDomain}— the domain assigned to the region.
As a practical planning value, the node ID can use up to 10 characters, the region domain should remain within approximately 25 characters, and two separators are required. This leaves up to 27 characters for the environment name in a 64-character hostname.
5. Wildcard SSL Certificate
*.{platformDomain}as a Subject Alternative Name (SAN).*.{regionDomain}as the Common Name (CN).
6. Uploader Storage
Provide storage for user-uploaded content. This storage can be shared with the Docker template cache.
- An external NFS mount is recommended.
- A shared SCSI LUN connected to infrastructure hosts can also be used.
7. Docker Storage
Provide storage for the Docker template cache. It can be combined with uploader storage.
- A shared external SCSI LUN across infrastructure hosts is recommended.
8. SMTP Server
An SMTP server is required for automatic platform notifications. An SMTP relay is optional but recommended for more reliable message delivery.
9. Docker Hub Account
Configure a Docker Hub billing account as the default registry account in the administration panel under Templates > Docker Registries.
- Use an account with unlimited image pulls so that customer deployments are not restricted by registry pull limits.
10. Supported Kernel Versions
Keep the host kernel current in accordance with the Virtuozzo support policy. The latest supported updates include important fixes required for stable and correct platform operation.
Virtuozzo supports the currently documented product versions and the latest released user-space update. For kernel support, maintain one of the two latest released kernels.
Backup Server
A backup server can use shared storage connected to an existing host through NFS, iSCSI, or a similar protocol. A dedicated server with local disks can also be used. The selected storage must provide adequate redundancy, reliability, and capacity.
- Minimum disk capacity should equal the combined capacity of the
/vzor/vz/privatedirectories on all protected hosts; twice that amount is recommended. - The backup server must be located on the same network as the protected hosts.
- Minimum network bandwidth: 1 Gbit/s.
- Recommended production bandwidth: 10 Gbit/s.
- CPU: x86_64, 8 or more cores / 16 or more threads.
- Memory: 16 GB RAM or more.
Installation Scenarios
Two installation approaches are available for public beta and commercial deployments:
- Local Storage Server
- Cloud Storage Cluster
Review the scenario-specific documentation for detailed hardware, networking, and operating-system requirements.
System Settings
The installation process applies required operating-system settings. These settings must remain unchanged after deployment because the platform depends on them for stable operation and supportability.
- Do not make unsupported changes to system configuration files.
- Do not remove or overwrite configuration files added or updated by the platform installation.
- Do not alter the kernel modules configured for preloading.
- Do not modify the TCP stack settings applied during installation.
- Do not remove or overwrite platform-specific
iptablesrules. - Allow the required platform infrastructure IP addresses through the firewall.
- Keep the approved operations-team SSH keys on every required host for emergency access.
- Keep the server timezone set to UTC.
- Keep SELinux disabled.
