Platform architecture
This page describes the architectural foundations of the SC//Reliant™ platform: the hypervisor and runtime model, the orchestration engine, the cloud control plane, the open-standards posture, multi-tenancy isolation, hardware-agnostic deployment, data residency, multi-group and multi-brand support, MACH alignment, the unified-edge-platform consolidation pattern, and supported deployment models.
Hypervisor and runtime
The SC//Reliant platform is multi-hypervisor by design. KVM+QEMU (a Type 1, kernel-based hypervisor) handles full virtual machines, and Docker (Type 2, dockerd/containerd/runc) handles containers. Both run simultaneously on the same edge node, because distributed-edge estates rarely have the luxury of being all-modern or all-legacy. A typical deployment runs one of each on the same hardware.
Orchestration engine
Workloads are orchestrated through the SC//Reliant Platform Manager, backed by Puppet and SC//Reliant platform proprietary code. The same orchestration applies to both container and VM workloads. There is no separate tool for each.
Scale is achieved through templating. A generic site image is built once, then customized through templates with overrides at enterprise, group, or individual-site level. A deployment can target a single site, a region, a group, or the whole fleet, and changes propagate in near real time.
Lifecycle management is declarative. Puppet's model continuously enforces the desired state, with agents converging on every scheduled run. The schedule is set through properties, so it can differ between environments. See Configuring automated Puppet runs. Rollback is built in:
- Container workloads revert by redeploying the prior immutable image tag.
- VMs revert via snapshot.
- OS-level configuration reverts to the prior Puppet state on the next convergence cycle.
Cloud control plane
Because the control plane is cloud-agnostic, it can run in AWS, Google Cloud, Azure, or a private environment. Hosting region, redundancy, and geographic distribution are configurable per the selected cloud, making data residency a configuration choice rather than a re-architecture.
Site operations do not depend on control-plane reachability. Each SC//Reliant platform edge node operates fully autonomously if the control plane is unreachable. POS, payments (store-and-forward), networking, firewall, IDS, surveillance, fueling, kitchen, and IoT workloads all continue running at full performance. Configuration changes are deferred until the control plane returns. Nodes continue operating with their last-known-good state.
Open standards posture
The platform is built on open standards wherever practical: Debian Linux, Docker (OCI-compliant containers), KVM, libvirt, OVF/OVA and QCOW images, and Puppet (open-source DSL). The SC//Reliant platform uses Puppet plus Docker directly for container orchestration, with no proprietary scheduler in between.
The proprietary components are intentionally narrow: the SC//Reliant Platform Manager (the web UI for orchestration), the SC//Reliant platform configuration logic, and the site-image build tooling. Native Kubernetes is supported via hosted KxS images, and CNCF projects (Prometheus, Fluentd, and similar) deploy as containerized workloads. TOSCA-formatted blueprints are supported when KxS is run as VMs under the platform's Type-1 hypervisor.
Multi-tenancy
A single appliance can host multiple, fully isolated workloads. Multiple isolation mechanisms are used concurrently and can be combined as the workload demands:
- Docker containers with cgroup-based CPU, memory, and IO quotas.
- KVM VMs with full hardware-level isolation for workloads that require kernel separation.
- Virtual Local Area Network (VLAN) segmentation isolating POS, IoT, back-office, and guest networks.
- iptables firewall rules between VLANs and workloads.
- PCI-scope workloads (POS, payment) network-segregated from non-PCI per the PCI-compliant network design.
Hardware-agnostic deployment
The SC//Reliant platform is hardware-agnostic. Operators (or Scale Computing engineering) select hardware that meets the baseline specifications. The platform is commonly used to virtualize POS applications and retain existing card readers, printers, and scanners, eliminating capital-intensive hardware replacement. There is no lock-in to compute, peripherals, or POS software.
Data residency
The SC//Reliant platform control plane can run in any AWS, Azure, or GCP region, so deployments requiring specific regional data residency are a configuration choice rather than a re-architecture.
Site-resident processing. POS, payments, transactions, and video, stays at the site. Only orchestration metadata, monitoring telemetry, and logs traverse to the cloud control plane in the chosen region. Contractual data-residency commitments and region-specific SLAs are addressed during deployment planning.
Multi-group and multi-brand support
Operators with multiple business units or brands can model them natively in the hierarchical configuration model. The SC//Reliant Platform Manager supports three tiers, enterprise, group, and individual site, implemented through Puppet's Hiera key-value lookup system.
Distinct business units or brands can be modeled as independent groups with their own configurations, branding, network rules, application stacks, and operational policies, all managed within a single platform instance. Inheritance with override is supported: enterprise-level defaults cascade down, and group- or site-level settings override where required. Every change is audited at every level.
MACH and composability alignment
The SC//Reliant platform's alignment with MACH (Microservices, API-first, Cloud-native, Headless) principles is as follows:
- Microservices. Aligned. The platform is container-native (Docker), so customer and third-party workloads naturally follow microservices patterns.
- API-first. Aligned. The SC//Reliant Platform Manager and platform components are built API-first and fully expose APIs for integration.
- Cloud-native. Aligned. Cloud-managed control plane, hybrid edge model, container-native runtime, and infrastructure-as-code (Puppet) are all cloud-native.
- Headless. Partial. The SC//Reliant Platform Manager is a management UI that consumes its own APIs. The underlying control plane is service-oriented, but the UI is not strictly decoupled from the orchestration backend in the headless-commerce sense.
The edge OS layer (Debian) is intentionally not MACH-aligned: it is monolithic by design, optimized for stability and small footprint over composability.
Unified edge platform
An SC//Reliant platform node, whether deployed as a cluster or a singleton, is a unified edge platform rather than a collection of point appliances. A single node consolidates the following workloads:
- POS and payment processing
- Networking (LAN/WAN routing, VLANs, VPN)
- Security (firewall, IDS, FIM, vulnerability scanning)
- Virtualized back-office applications
- Fuel and forecourt controllers
- IoT integrations
- AI/ML inference
- Digital signage
- Customer-loyalty workloads
This consolidation typically replaces three or more single-purpose devices found in legacy edge stacks.
Workflow: how the platform operates
- Device enrollment and edge deployment
- Edge devices are provisioned and registered via the SC//Reliant Platform Manager.
- Policies and security configurations are pushed from the cloud to each site location.
- Application and security policy management
- Operators deploy containerized applications to edge devices via the web console.
- Firewall rules, network access controls, and monitoring policies are enforced at each location.
- Continuous monitoring and compliance enforcement
- Logs, vulnerability scans, and event data are sent to centralized security monitoring tools.
- The platform continuously validates compliance and alerts administrators on security risks.
- Resilience and local failover
- If cloud connectivity is lost, the edge platform continues operating autonomously.
- Data is stored locally and synchronized once the connection is restored.
Deployment models
The SC//Reliant platform supports flexible deployment options based on enterprise needs. The control plane can be hosted in three configurations, which can be mixed as needed.
- Cloud-managed control plane with site-resident edge (standard) – The SC//Reliant Platform Manager, Puppet master, central logging (rsyslog to Splunk), and SC//AcuVigil™ monitoring run in the selected cloud. The on-site appliance handles every production workload locally.
- Customer-hosted control plane – The SC//Reliant Platform Manager, Puppet, and logging stack run in the operator's own AWS, Azure, GCP, or private cloud. The operator retains full control of the data plane, the identities, and the compliance scope.
- Hybrid – Some control-plane services hosted by Scale Computing, others hosted by the operator.
Cloud-resident components typically include the SC//Reliant Platform Manager (web app), the Puppet server, the Postgres and Redis primary, central rsyslog/Splunk, and the SC//AcuVigil dashboards. Site-resident components include the Debian Linux nodes, Docker containers, KVM VMs, OpenVPN, the iptables firewall, Snort IDS, OpenVAS scanner, Quagga routing, and the Puppet agent.
Additional deployment patterns include:
- Hybrid cloud integration – Integrates with existing enterprise security tools (for example, SIEM, SOC).
- On-premises resilience – Ensures offline operation with local failover capabilities.