Project Overview
RayLife provides captive portal and SD-WAN services to businesses managing thousands of connected devices with real-time data and control. They run their platform on their own machines and on AWS.
Running and growing the platform was the problem. The AWS bill kept increasing faster than the business; on-premises had no redundancy to fall back on, visibility was limited when something broke, and scaling and recovery were done by hand.
Cloud Solitaire ran Kubernetes on hardware RayLife already owned, put every deployment under GitOps, and automated monitoring, storage, and provisioning.
Challenges
As RayLife was growing, four limits were holding the platform back:
- The cloud bill was rising faster than the business, because the AWS-based setup cost more as they grew
- No particular place to look when something broke, due to limited monitoring
- No redundancy, with on-premises running on a single Docker machine and no failover
- Everything being done manually on the on-premises side, so scaling and recovery were slow
Together, these meant every new enterprise customer took longer and cost more to onboard than the last. For a platform managing thousands of connected devices in real time, growth itself was becoming the bottleneck.
Our Approach
The work was split into four pieces, built around Kubernetes and GitOps: run Kubernetes on the hardware RayLife already owned, put every deployment under GitOps, add monitoring and alerting that actually fires, and make storage and provisioning automatic.
The most crucial work was making machines RayLife already owned behave like a proper platform.
Solutions
Kubernetes Foundation & GitOps
We deployed Kubernetes for container orchestration, standardising environments across machines. FluxCD now drives GitOps, so Git holds the desired state of the cluster, and resource changes are applied without manual steps.
Monitoring & Reliability
Prometheus handles metrics and Grafana powers the dashboards, with alerts that fire in real time. Load balancers sit in front of the services, and Linux-level tuning improves performance across the cluster.
Storage & Backup
Longhorn provides distributed storage across servers, so data stays safe if one machine fails. Automatic cloud backups and tested restores help ensure data can be recovered.
Automation
Ansible playbooks handle provisioning, so scaling is repeated rather than rebuilt each time. Automated failover workflows are in place, leaving far fewer places for human error.
Technologies & Tools Used
| Area | Tools |
|---|---|
| Orchestration | Kubernetes, FluxCD |
| Storage | Longhorn, cloud backups |
| Observability | Prometheus, Grafana |
| Automation | Ansible, load balancers, Linux performance tuning |
Results
- Onboarding: new customer environments now go live in under one day, where previously this took longer and was less predictable.
- Scaling: Kubernetes handles growth across environments without rebuilding every time.
- Reliability: distributed storage and automated backups keep the platform running even if a machine is lost.
- Delivery: every environment is built the same, repeatable way through Ansible playbooks.
- Observability: alerts arrive before customers notice a problem.
- Cost: running cost is down and more predictable.
Key Takeaways
Modernising on-premises infrastructure doesn’t always mean moving to the cloud. For RayLife, we improved their existing hardware instead of adding unnecessary AWS costs.
GitOps via FluxCD turns configuration into something reviewable and rebuildable, and removes manual deployment steps.
Storage and disaster recovery should be tested, not assumed. Longhorn’s distributed storage and automated, testable backups close that gap for a platform running on owned hardware.
New customer environments can now be set up in under a day without compromising reliability, using the same Kubernetes, GitOps, and Ansible setup every time.
The stack uses open-source tools - Kubernetes, FluxCD, Longhorn, Prometheus, Grafana, and Ansible - avoiding vendor or cloud lock-in.
This was not the first time Cloud Solitaire has run Kubernetes off the cloud. We have set it up on clients’ own hardware and added GitOps for management, designed storage and recovery from the beginning with Longhorn, created automated backups and restores that we test regularly, and built automation from the first environment using Ansible playbooks - so each new environment costs less than the previous one.
Frequently Asked Questions
Does modernising on-premises infrastructure always mean moving to the cloud? No. When customers and hardware are already on site, pushing them into a public cloud can raise costs without any benefit. Running Kubernetes directly on owned hardware, with GitOps, monitoring, and automation layered on top, can modernise a platform without adding cloud spend.
Can Kubernetes run outside AWS or other public clouds? Yes. Kubernetes can be deployed directly on hardware owned by the organization. It standardizes environments across machines the same way it would across cloud instances.
How does GitOps reduce manual deployment work? Tools like FluxCD keep Git as the desired state of the cluster, so resource changes are applied automatically instead of by hand, and every change is reviewable and reversible through Git itself.
Why does storage redundancy matter for networking and IoT platforms managing thousands of devices? A platform offering real-time data and control to enterprise customers cannot afford to lose data when a single machine fails. Distributed storage like Longhorn, with automated and tested backups, turns recovery from an assumption into a rehearsed procedure.