# Paladin Cloud CE: continuous cloud security policy with auto-remediation > Paladin Cloud is a Java and Angular platform that discovers cloud assets, evaluates security policies against them, opens prioritised issues and can execute predefined auto-fix actions, with a plugin architecture for ingesting data from Kubernetes, API gateways and scanners. The installer is Python and Terraform, and it deploys onto AWS ECS, Batch, Lambda and Elasticsearch. **PaladinCloud/CE** — Paladin Cloud is an extensible, cloud security platform for developers. Join the community at https://discord.gg/xvCFD29Jj4 - Repository: https://github.com/PaladinCloud/CE - Website: https://paladincloud.io/ - Stars: 568 · Forks: 55 - Language: Java - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/paladincloud-ce ## The loop is assess, report, remediate, repeat Paladin Cloud is a free open source cloud security platform focused on enabling you to find blindspots in your cloud security, and it identifies and visualises your cyber assets and security controls while monitoring multi and hybrid cloud environments for vulnerabilities, misconfigurations and security risks. The framing is Security-as-Code, and the platform functions as a policy management plane across multi-cloud and enterprise systems, protecting applications and data. The operating loop is stated in four words, Assess, Report, Remediate, Repeat, and the description of what happens in each phase is the clearest statement of the design in the README. The platform constantly assesses and monitors your cloud security posture on a near real-time basis, discovering assets, evaluating policy, creating issues for policy violations and prioritising remediation. If an auto-fix is configured with the policy, those auto-fixes are executed when the resources fail the evaluation. One rule stands out and it is unusual enough to quote, that policy violations cannot be closed manually, because the issue must be fixed on the inspected asset, and then Paladin Cloud will mark it closed in the next scan. That is a deliberate stance on what a finding means, and it is the difference between a ticketing system that reports on your cloud and one that refuses to consider a problem solved until the resource is actually fixed. ## Exceptions and asset groups are the two scoping mechanisms Two mechanisms let you control what the platform complains about, and both are described in detail. The first is exceptions. Exceptions can be added to policy violations, and sticky exceptions, which are based on resource attribute matching criteria, can be added to exempt similar resources that may be created in the future. The README adds a warning that exceptions should be used sparingly and only if they are aligned with corporate security guidelines, which is the right framing, because an exception is a permanent hole in a policy and a careless one turns a control into decoration. The second mechanism is asset groups, described as a powerful way to visualise cloud security and compliance. Asset groups are created by defining one or more target resource's attribute matching criteria, and the example given is creating a group of all running assets by matching all EC2 instances with the attribute instancestate.name=running. The behaviour that makes this more than a filter is that any new EC2 instance launched after the group was created is automatically included in it. Asset groups also scope the user interface, since you can select the scope of the portal to a specific group and all the data points shown are confined to it, and the README notes it is common practice to create groups per account or subscription or project, per application, per business unit, or per environment. They also scope rule execution, since policies contain rules and each rule can be configured to run against all resources or a specific group, which is how a team enforces additional tagging standards only on their own assets without loosening the global policy. ## The plugin architecture is how coverage is extended The section on extending your coverage explains the plugin-based connector architecture that allows data ingestion from multiple sources. Plugins pull data from various cloud-based enterprise systems, such as Kubernetes management, API gateways and threat intelligence systems, so you can manage cloud security across them rather than one at a time. The named examples are telling, since they are the tools a security team already runs, with Qualys Vulnerability Assessment Platform, Bitbucket, TrendMicro Deep Security, Tripwire, Venafi Certificate Management and Redhat. The point of the architecture is stated plainly, that you can write rules based on the data collected by these plugins to get a complete picture of your cloud security posture. So the plugin is a data source, not an integration with a fixed meaning, and the policy layer is where a vulnerability scanner result or a certificate expiry becomes a rule you wrote yourself. That is the difference between this and a vulnerability management tool, where the interpretation is baked in. The repository layout backs the description up, with a check-schema.json at the top level alongside pom.xml for the Java build, a .pre-commit-config.yaml, a sonar-project.properties file for static analysis, and directories named api, commons, jobs, lambda-functions, subsystem, webapp, installer and emailTemplates, plus a wiki directory, which is where the installation guides referenced from the README live. ## Installing means letting the installer build the AWS estate for you There is no command to copy here, and the reason is that the product is an application platform rather than a library. The README points at a Standard Installation Guide with detailed instructions and a Quick Install Guide that covers installation without step-by-step instructions for advanced AWS users or those looking for a refresher, and the documentation itself is hosted at paladincloud.io/docs. The installation section of the README tells you what the installer does, launching the required AWS services listed in the installation instructions. The deployment stack is worth reading as a list of AWS services, because it tells you the footprint before you commit. AWS ECS and ECR host the UI and the APIs, AWS Batch runs the rules and resource collection jobs, AWS CloudWatch Rules provide rule trigger and scheduler behaviour, AWS Elasticsearch is the primary data store used by the web application, AWS RDS holds admin CRUD functionality, AWS S3 stores inventory files and the persistent storage of historical data, and AWS Lambda handles policy execution. The installer, written in Python and Terraform, automatically launches all of these services and configures them. The technology stack behind that is Angular for the front end, Java for the backend APIs, jobs and rules, and Python and Terraform for the installer. The practical consequence is that this is an AWS-shaped product: the features list promises unlimited AWS, Azure and GCP accounts, but the deployment machinery described here is entirely AWS services. ## The capability list and the collaboration surfaces The key capabilities list reads like a product sheet, and a few items are more than marketing. Continuous asset discovery and continuous security policy evaluation are the core pair, and the rest build on them: detailed reporting, auto-fix for policy violations, the ability to search all discovered resources, simplified policy violation tracking and prioritisation, an easy to use self-service portal, custom policies and custom auto-fix actions, dynamic asset grouping to view compliance, the ability to create multiple compliance domains, exception management, email digests, support for unlimited AWS, Azure and GCP accounts, a completely automated installer, OAuth2 support, Azure AD integration for login, and role-based access control. The multiple compliance domains entry is worth pausing on, since it is the mechanism by which one installation serves several teams or business units with separate policies and separate views. The self-service portal and role-based access are the other pair, since a platform that only administrators can use will not be adopted by the engineers who have to fix the findings. The Azure AD integration for login sits alongside OAuth2, which is a deliberate choice to work inside an existing identity provider rather than add another. The community surfaces are a Discord, a Slack channel and a community survey, and the site is paladincloud.io. ## Where Paladin Cloud CE is the wrong choice The deployment is the first constraint, and it is a large one. Even with an automated installer, standing up ECS, Batch, Lambda, Elasticsearch, RDS, S3 and CloudWatch Rules is a substantial AWS estate to own and pay for, and a team with a dozen resources in one account is not going to justify it. The second is the manual-close rule. Not being able to close a violation without fixing the resource is a defensible design, but it means a policy that is wrong for a legitimate case pushes operators toward exceptions, and the README's own warning about using exceptions sparingly is an acknowledgement that the tension exists. The third is the plugin requirement. Coverage depends on connectors existing for the systems you care about, and the named examples are a specific set, so a team whose estate is built on something else writes its own plugin or runs without that data. The fourth is the maintenance picture, and here the numbers are the concern. The recent releases are 3.0.7 from 2025-01-09, 3.0.6 from 2024-08-28 and 3.0.5 from 2024-03-28, while the last push to the repository was on 2026-10-13, so code is landing long after the last tag. The README badge still points at 3.0.1 as the latest release, which does not match the tag list, so the version a reader believes they are installing is not clearly the version they would get. A platform that runs auto-fix actions against production accounts is exactly the kind of thing where that gap matters. ## Conclusion Adopt Paladin Cloud CE if you run a meaningful AWS footprint and want continuous policy evaluation with a defined auto-fix path rather than a periodic scan report. Skip it if your cloud estate is small enough to audit by hand, if you need a policy engine that runs in a different cloud, or if you cannot accept a deployment that pulls in a dozen managed AWS services. Verify first which release you are pinning, since the tags stop at 3.0.7 from 2025-01-09 while the repository is still receiving pushes, that the connectors you need exist as plugins, and that the auto-fix actions you enable are safe to run unattended. ## FAQ ### What is Paladin Cloud and what does it do? It is a free open source cloud security platform that finds blindspots in your cloud security, discovering assets, evaluating security policies against them, creating prioritised issues for violations and, where an auto-fix is configured with the policy, executing predefined actions. The working loop is assess, report, remediate and repeat, and a violation cannot be closed manually since it must be fixed on the asset and is marked closed on the next scan. ### What are asset groups and exceptions in Paladin Cloud? Asset groups are defined by resource attribute matching criteria and automatically include matching resources created later, such as all running EC2 instances. They scope both what the user interface shows and which rules execute against which resources, which is how a team enforces extra tagging standards on its own assets. Exceptions exempt resources from a violation, and sticky exceptions based on attribute matching also cover similar future resources, though the README says to use them sparingly and only when aligned with corporate security guidelines. ### How is Paladin Cloud deployed and what does it need? The installer is written in Python and Terraform and automatically launches the required AWS services, which include ECS and ECR for the UI and APIs, Batch for rules and resource collection jobs, CloudWatch Rules for triggers and scheduling, Elasticsearch as the primary data store, RDS for admin CRUD, S3 for inventory files and historical data, and Lambda for policy execution. The front end is Angular and the backend APIs, jobs and rules are Java, and there is a standard installation guide and a quick install guide on the project documentation site. ## Sources - [License: Apache-2.0](https://github.com/PaladinCloud/CE/blob/master/LICENSE) - [PaladinCloud/CE on GitHub](https://github.com/PaladinCloud/CE) - [Project website](https://paladincloud.io/) - [README](https://github.com/PaladinCloud/CE/blob/master/README.md) - [Releases](https://github.com/PaladinCloud/CE/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/paladincloud-ce