Open Source Arlon Is Now Available


With a single unified architecture, Arlon connects workload and infrastructure management. An effective declarative policy-driven framework for the entire cloud-native stack is now available to DevOps and IT teams.

Today, Platform9 announced the debut of Arlon, its newest open source endeavour. With the help of GitOps, declarative APIs, and Kubernetes, Arlon specifies a potent unified architecture that can manage and reconcile the state of workloads as well as infrastructure (clusters and underlying resources) (apps and configurations). With the use of reusable profiles and groupings, Arlon is the first open source project to fully automate and integrate the management of infrastructure and workload lifecycles.

Developers and DevOps teams may streamline scalable deployments at a lesser cost with Arlon. Wherever the clusters are placed, enterprise IT teams can implement uniform governance standards.

Introducing Arlon, a centralised infrastructure and task management solution

With a lot of community support and momentum, ClusterAPI, a Kubernetes project that enables the creation, update, and dismantling of Kubernetes clusters, is growing in popularity and strength.

ArgoCD, which uses a declarative framework to maintain desired sets of settings, is quickly becoming as the standard choice for workload management and continuous delivery.

Arlon is what you get when you combine the greatest features of these two pillars to maintain, manage, and scale the entire cloud-native stack, from infrastructure to workloads and everything in between. In a single integrated system, Arlon satisfies the requirements of enterprise IT, operations, and developers. The system is currently being tested with AWS, and the roadmap calls for adding other public clouds in addition to bare metal. Arlon has its own GitHub page, documentation, and community and is entirely open source.

Issues with fragmented workload, application management, and scaling

The overall workflow is interrupted by workload and infrastructure deployment and configuration that are not coordinated. The manual intermediary procedures frequently result in configuration mistakes. Applications that function properly during development might not function properly throughout subsequent phases of the CI/CD workflow.

DevOps teams could find themselves spending a lot of time debugging problems that result in extended outages and downtime that can have a big impact on the business. The infrastructure that the app is operating on is frequently configured incorrectly, rather than the app itself. As businesses scale clusters, teams, and locations, these issues get worse.

The scale of cloud-native varies according to a company’s use case:

  • Locational scale (e.g 1000s of edge locations)
  • A number of clusters with 100 or more nodes that are broken up by namespace in your data centre or a single public cloud


Please enter your comment!
Please enter your name here