NanoCloudBox hardware is designed around the deployment. It can be a single purpose-configured appliance, or a multi-device architecture with a managed network gateway/router in front of a separate storage appliance and, when needed, a dedicated backup node.
Each role can run on the same appliance or be separated onto dedicated devices. The final architecture depends on workload, network, storage, recovery and physical-location requirements.
A compact deployment may use one NanoCloudBox appliance behind the existing office network. A larger or more security-sensitive deployment can place a managed gateway/router at the network boundary, with a separate storage appliance behind it.
Where recovery requirements justify it, a dedicated backup node can be added in the same location or at a separate approved site. All devices remain parts of one documented and managed NanoCloudBox system.
These are architecture patterns, not fixed commercial SKUs. Device roles, capacity and redundancy are selected after discovery.
A compact NanoCloudBox appliance provides the agreed storage and platform roles behind the existing network. This suits smaller environments where separate hardware roles would add unnecessary complexity.
A managed gateway/router sits in front of a separate storage appliance. Network-boundary responsibilities and data-storage responsibilities are separated while both devices operate as one managed system.
A dedicated backup node adds a separate recovery role to the gateway and primary storage architecture. Its location, retention and restore procedure are defined around the required recovery model.
NanoCloudBox can use compact, low-power hardware — including ARM-based systems — when the required services, storage profile and software compatibility make it the right fit. These systems can reduce power, heat and space requirements for always-on infrastructure. Where workloads need more compute performance, expansion capacity or broader software compatibility, an x86-class or higher-performance platform is selected instead.
One system can use a single location or distribute selected roles across approved locations when the recovery model requires it.
On-premises placement for local network performance, direct physical control and day-to-day office workflows.
A practical location for owner-operated businesses, smaller teams and private work environments.
A professional facility when power, connectivity, site access and physical infrastructure are the priority.
NanoCloudBox is sized around real operating requirements rather than a public list of fixed boxes.
Number of active users, simultaneous access, application roles and expected growth.
Current data volume, file sizes, performance needs, archive growth and retention direction.
Local throughput, remote access, network-boundary role and available connectivity.
Backup frequency, separation, retention, restore expectations and acceptable recovery time.
Energy budget, available space, cooling, noise and whether an ARM-based or higher-performance platform best fits the role.
Files, access, network protection, credentials and other agreed roles affect the architecture.
The customer approves the physical locations, business requirements, access ownership, data scope and recovery expectations. The deployment remains visible and documented rather than disappearing into an unspecified infrastructure layer.
NanoCloudBox handles architecture design, hardware sizing, assembly, configuration, monitoring, updates, backup checks, support and recovery assistance within the agreed service scope.
Multiple devices do not automatically mean high availability. Redundancy, failover and recovery behavior are defined and validated explicitly for each deployment.
Start with users, data, network, location and recovery requirements. NanoCloudBox can then recommend the smallest architecture that meets the agreed operational scope.
Request pilot