pluralsh/plural: a self-hosted platform for deploying and updating services across Kubernetes clusters

What the platform actually manages

Plural describes itself as the fastest way to build great infrastructure and deploy your software, and as empowering you to build and maintain cloud native, production ready infrastructure on Kubernetes.

The concrete scope is in the feature list. Plural will deploy open source applications and proprietary services on Kubernetes in your cloud using common standards like Helm and Terraform. The platform then adds four things on top.

The first is a fleet scale GitOps engine to deploy any Helm, Kustomize or YAML based service into your fleet, described as securely and seamlessly scalable. The second is full visibility of the fleet and of all deployed services through a secure Auth Proxy. The third is Kubernetes CRD native infrastructure as code management, supporting Terraform, Ansible and Pulumi, and the marketing line for it is that you get the scaling promise of Crossplane with the configuration language of Terraform, which is a fair summary of what a CRD backed layer over existing IaC tools is.

The fourth is automated pull request generation, which is described as providing full UI based self service while still maintaining the rigor and auditability of GitOps. That is the piece that distinguishes the product from a dashboard, because a change still arrives as a diff that a reviewer can read and approve, while the operator that applies it is Plural's own.

On top of that sits the AI layer, which is described as 360 degree and is driven by the accumulated knowledge of the state of your infrastructure from GitOps deployments, IaC management and the Kubernetes API's rich REST API. The stated outputs are natural language explanations of why a service or a Terraform stack is currently failing, suggested code changes using the context of the GitOps manifests associated with the failing service, and plain language explanations of any Kubernetes or Terraform user interface page to reduce the platform engineering learning curve.

That last one is a strange and rather good idea, taking the shape of the product apart for a person who does not yet know it.

The pull model is the security argument

The section on being secure by default is short and it is the most load bearing claim in the README.

Plural is fully self-hosted within your own environment, meaning we don't touch your credentials or sensitive information. Cluster setup includes deploying the Plural deployment operator, which efficiently polls the control plane for any changes that need to be applied. This ensures that the control plane doesn't reach into these workload clusters, providing a more secure setup than push based models and removing the need for credentials to be centralized in a single major attack vector.

That is a real architectural difference, and it is worth being precise about what it means. In a push model, the management plane has credentials for every cluster it manages, which makes the management plane the single most valuable target in the estate and creates a credential sprawl problem. In a pull model, an operator runs inside each workload cluster, pulls the desired state from the control plane, and applies it locally. The management plane holds no cloud credentials at all, and a compromised management plane can at worst cause changes to be proposed, not applied silently.

The cost is latency. A pull model converges rather than pushes, so a change takes a polling interval to land, and the failure mode is a cluster that has drifted from the control plane rather than a command that did not arrive. The README also notes that all Plural deployments are fully customizable with its centralized secrets management, and that Plural natively supports deploying to brand new clusters or adopting existing Kubernetes clusters, which is the practical point for anyone with an estate that predates the platform.

The API layer: DNS under onplural.sh and an OIDC provider

Beyond the fleet management, the platform's API provides two services that are worth understanding separately, because they solve problems that are awkward to solve yourself.

The first is a DNS service to register fully qualified domains under onplural.sh, described as eliminating the hassle of DNS registration for users. The reasoning is straightforward. Every service you deploy needs a hostname, and a hostname needs a DNS record, and a DNS record needs a zone you control with an API you can talk to. Registering a domain and delegating a subdomain is a small, tedious, per service chore, so the platform does it centrally under a domain it operates.

The second is being an OIDC provider to enable zero touch login security for all deployed Plural Console applications, or any other application managed by it. The mechanism is the same one the platform uses for its own console, and once you have an OIDC provider, every service you deploy can accept logins from the identity you already have rather than each application inventing its own account system.

Those two services are the kind of thing that makes a platform feel like a platform. A team that deploys thirty internal services with a shared sign in and a shared DNS zone has solved two problems that otherwise multiply across every project.

The local stack and the release image

The repository is a Phoenix and Elixir application with a separate front end, and the local development environment is defined in a compose file.

The root dependencies are two PostgreSQL 14 instances, one named `db` and one named `cloud`, the second one evidently for a different data domain, both with logical WAL enabled via the `wal_level=logical` setting. There is RabbitMQ 3 with the management image, a RabbitMQ server for the job queue. There is InfluxDB 1.8, with HTTP auth enabled and a database named `plural`, which points at a time series store for metrics. And there is ChartMuseum at the Helm chartmuseum image version 0.16.6, serving charts from local storage on port 8080, which is a private Helm repository for the charts the platform serves.

The Docker image is a two stage build on Elixir 1.19.4 with OTP 28.5 on Alpine 3.23.4, where the builder fetches the dependencies, compiles and produces a Mix release, and the runtime stage is a much smaller Alpine 3.21.7 image that carries the release plus a set of tools fetched at build time. Those tools are Helm at v3.22.0, the plural CLI at v0.12.65, `goon` at v1.1.1 and Trivy at v0.75.0, and the versions are annotated as Renovate managed, which is a small sign of how the dependency set is kept current.

Including Trivy and a vulnerability scanner in the runtime image is a detail worth noticing, since it means the deployed image can scan what it deploys. The Makefile then wires the local workflows together, with targets to start and stop the root dependencies, to build the Mix release images sequentially and run the api, rtc, worker and cron services, to run the backend tests in Docker, and to build and serve the front end.

The documentation is mid-migration, and says so

The documentation section carries a sentence that tells you a lot about the project's current shape. The documentation site covers both the mainline Fleet Management platform and the legacy open source marketplace, which is soon to be merged into the mainline product, and the README recommends that any new users start with Plural's fleet management suite of solutions.

So the product you are evaluating is the fleet management platform, and the older marketplace is on its way out. That is a significant fact for an adopter, because it means the public documentation is a mixture of two products and the parts that look most like the old open source marketplace are the parts being retired. The getting started instructions follow the new path, create an account at app.plural.sh, install the Plural CLI, and deploy the Plural Console, with the note that the account is simply to track your open source installations and to deploy your Console.

Support is arranged in three channels, the documentation for general help, Discord for live discussions with the team, and GitHub for bug reports, feature requests and contributions, plus a Twitter account for news. There is a code of conduct and the README asks people to read it.

The roadmap is published as GitHub artefacts rather than prose, an Application Onboarding Roadmap project board, the Plural Core issues and the Plural CLI issues, with the instruction to help prioritise by reacting to an issue. The CLI living in its own repository is worth noting, since it means the command line tool a user installs is versioned separately from the platform, and the Dockerfile pins a specific CLI release rather than building it from this tree.

Where Plural is the wrong choice

The first wrong case is a small estate. The platform is built for a fleet. If you have one cluster and a handful of Helm charts, an existing GitOps operator plus plain Terraform is a much smaller commitment, and the operational surface of a control plane, an API, an OIDC provider, a DNS service and a metrics store is real.

The second wrong case is a team that does not want a platform layer at all. Plural's value proposition is that it provides the things best practice tools do not, the pull request generation, the AI explanations, the shared identity. If your team is happy writing Helm and Terraform by hand, that value is not for you.

The third is a licensing question that the repository does not answer. The README says to see the LICENSE file for licensing information and, if there are questions about the license, to visit the Discord channel. A licence GitHub cannot classify, with the terms to be discussed in chat, is not a licence you can hand to a legal team without reading the file, and that is a real friction for a platform a company would run as infrastructure.

The fourth is a cloud provider you have standardised against. The pull model assumes the operator can run inside your clusters and reach them, and that assumption holds for Kubernetes, but a platform that also wants to manage other things needs a path for those, and the README does not describe one.

On the state of the project, the releases are frequent, with v0.12.53 on 2026-09-19, v0.12.54 on 2026-09-24 and v0.12.55 on 2026-10-12, the last push was on 2026-10-12, the repository is not archived, and the tree carries a `SECURITY.md`, a `renovate.json`, a `.trivyignore.yaml` and a `.tool-versions` file, which is the usual set of files for a project that takes its supply chain seriously.

Editorial conclusion

Adopt Plural if you run services across several Kubernetes clusters and want Helm and Terraform deployments, infrastructure as code and pull request based changes managed in one place, since that is the combination the platform is built around and the pull model removes a whole class of credential exposure. Do not adopt it for a single cluster with a handful of Helm charts, where Argo CD or Flux plus plain Terraform is a smaller commitment. Verify first what the licence file actually permits, since the repository is published under a licence GitHub cannot classify and the README sends licence questions to a Discord channel rather than summarising the terms, that the clusters you adopt are ones the operator can reach, and that the legacy marketplace documentation is not what you need, since the documentation site says it is being merged into the mainline product.

Frequently asked questions

Official sources

1. Issues
2. pluralsh/plural on GitHub
3. Project website
4. README
5. Releases