Composite Modules allow you to create a Module from other existing Modules. This enables you to manage complex configurations by breaking them down into smaller, reusable components called "submodules".
With composite Modules, you can customize the variables of the Modules that you include as submodules. You can also customize the configurations and secrets of any entities defined in submodules.
Learn more about composite Modules.
Apollo now supports directly integrating with your existing OCI registry to allow the management and deployment of software directly from your registry. Rather than publishing containers for Product Releases directly to Apollo's Container Registry, you can link your existing OCI registry to Apollo and create Product Releases in Apollo that reference artifacts from your own OCI Registry.
Learn more about Artifact Registries.
This update introduces improvements to how you can configure promotion pipelines.
Apollo now supports dynamic Environment strategies for promotion pipelines. With these strategies, Apollo evaluates conditions on a dynamic set of Environments, chosen with filters. To enable this, you can select Canary promotion when configuring a promotion stage.
Learn more about canary promotion stages.
This update introduces several improvements to how you can view and manage vulnerabilities.
Apollo now differentiates between vulnerabilities, which may impact many resources, and findings, which are surfaced through scans and identify the specific resource where a vulnerability was found. Each table in the Risk Management applications will only surface a vulnerability once.
The Risk Management application enables you view all the active vulnerabilities detected in Product Releases on your Apollo Hub. You can select vulnerabilities to view information such as risk scores, paths to files that contain the vulnerability, fix versions, and affected Entities.
In addition to the global context, the Risk Management application is also available in the context of a specific Environment through the Environment Security tab.
You can also use the Risk Management application to create suppressions for vulnerabilities.
When suppressing a vulnerability that has multiple findings, you can now set a suppression scope that defines what findings Apollo will suppress. You can suppress findings on a specific image, image prefix, or for the distribution bundle of a Product. You can also suppress the finding across all deployed Products.
Additionally, we have made updates to core workflows of requesting a suppression, identifying other affected resources, and re-running vulnerability scans after creating a suppression.
This update introduces several improvements to how you can manage secrets in Apollo.
You can now create secrets for an Entity at installation time. To do this, use the new Add secrets option in the Entity installation form. Apollo will create the secret in the Environment when it installs the Entity.
When editing secrets, you can now view existing secret keys. In addition, you can now change some key-value pairs in a secret without modifying others.
Learn more about creating and editing secrets in Apollo.
-, _, and ..The apollo-cli get-central-namespace command is now Deprecated. It will be deleted in November 2024.
After you edit a Module and Apollo generates a change request to update every installation of the Module, Apollo can now automatically approve the change request.
You can enable automatic approvals for Module updates like marking Entities for uninstallation, changing the default Release Channel, adding a new Entity, and more.
Learn more about automatic approvals.
This update introduces several improvements to how you update and manage Module installations in your Environments.
After you edit a Module, Apollo will now automatically attempt to update all installations of the Module. You can view the available updates for each installation of the Module in the Installations tab of the Module overview page.
You can also update a Module installation manually by following same steps as when installing a Module.
Learn more about updating Module installations.
You can now mark Entities for uninstallation in the Module YAML file:
Copied!1 2 3markedForUninstallation: minVersion: 1.0.0 unmanageAfterUninstall: AUTOMATIC
Marking the Entity for uninstallation in the Module definition will ensure that the Entity is uninstalled from the Environment when the Module is updated. If you simply remove the Entity from the Module definition, the Entity will not be uninstalled from the Environment when the Module is updated.
You can now unlink a Module from an Environment to remove the Module installation. The Entities that were part of the Module will remain in the Environment after the Module is unlinked but will no longer be managed by the Module.
Learn more about unlinking Modules.
Apollo now supports Product Release incompatibilities. This allows you to declare that a Product Release is incompatible with a range of other Product Releases. Apollo will ensure that Product Releases that are incompatible with each other are not installed in the same Environment at the same time.
You can define Product Release incompatibilities in the Product Release manifest:
Copied!1 2 3 4 5 6 7extensions: product-incompatibilities: - product-group: org.postgresql product-name: postgresql product-type: helm-chart minimum-version: 9.3.6 maximum-version: 9.6.x
Learn more about configuring Product Release incompatibilities.
This update introduces Experimental commands for the following Apollo resources:
View an example end-to-end workflow using the new commands.
To begin using these commands, you can re-download the Apollo CLI.
Install pending state.This update introduces several improvements to how you uninstall Entities from an Environment in Apollo.
After you uninstall a local Entity, Apollo will unmanage the Entity by removing it from the Environment settings.
For remote Entities, you can uninstall the Entity from the source Hub and then transfer the update in a bundle to the target Hub. After the Entity is uninstalled from the target Hub and you confirm this from the source Hub, Apollo will unmanage the Entity by removing it from the Environment settings.
Learn more about uninstalling local and remote Entities.
This update introduces several improvements to how you recall Releases in Apollo. To prevent shipping known bugs, users can now issue an open ended recall, and Apollo will auto-recall any new Releases. Users can edit the range of recalled Releases anytime to update the range of recalled Releases.
Users can also recall the same Release for different reasons. Apollo will intelligently resolve multiple recalls for a Release and ensure that Entities are rolled off bad Releases.
Learn more about improved recalls in Apollo.
The first time you navigate to an Environment will land you on the new Environment Overview tab. This tab displays relevant information about an Environment, such as the owner, the default Release Channel, the labels applied to the Environment, and the maintenance windows. You can also view the upgrade status of Entities in the Environment and the status of Apollo Agents deployed in the Environment.
The Activity tab for Entities and Environments allows you to view Plans, commands, and upgrades in a single tab. This tab displays any blocking constraints for ongoing work, as well as the status of completed work.
This update introduces labels for Entities and Environments. Add labels to these resources to tag with them information that is key to your organization or software operations. Then, use labels to filter the list of Entities or Environments based on specific properties.
This feature provides a single workflow entry point to manually add a Release to a Release Channel. With this manual promotion workflow, the break-glass operation of adding a Release to a Release Channel scales to match the ability to configure complex promotion pipelines.
This update adds support for managed Environment Configs to Apollo.
Common configuration values, such as domain names, may be useful across many Entities in an Environment. Prior to this update, these shared values had to be provided to Entities through bespoke systems in your Environment, or stored many times in each Entity Config in Apollo. Either solution meant more work for Environment owners and less clear visibility into shared values.
Apollo now supports managed Environment Config through a similar workflow as available for each Entity. These values are also represented in each Entity Config tab to make sure every operator in the Environment knows about them and Pans for each Entity include both Config values. Changes to these values go through standard Change Management processes, and updates are propagated to each Entity through rolling Plans across the Environment.
Promotion Stages between Release Channels support flexible rollout strategies across environments for your products. To make it easier to manage these promotion stages, the Release "Canary Analysis" tab has been replaced with comprehensive "Promotion" workflows.
The Promotion Graph clarifies the representation of complex branching pipelines in the Apollo interface and makes it easier to interpret the observations that led to automated action. Interactive components now provide in-context answers to key questions about automated recall, pending upgrades, in-flight promotion constraints, and more.
There is now a Permissions panel in Settings that provides visibility into the roles that exist for each context and who they are granted to. Previously, root role grants for various resource types in Apollo were inaccessible to end-users, requiring Palantir intervention to set appropriate admin teams or groups for each context. Now, root admins can use the Permissions panel to independently set access for roles.
Environments managed by Apollo must include a well-defined set of control plane services; the "Create Environment" workflow now contains a set of predefined options for your control plane. These options help operators make an informed decision about which services are relevant to a use case and prevent problems with misconfigured environments.
Vulnerability scanning is critical for modern software security: given the number of open source components most software products use, discovered vulnerabilities will affect most product releases eventually. We are deeply integrating security scanning and scan result visibility into Apollo to help.
Product releases now have a "Security" tab that provides in-context access to results. Severe vulnerabilities will be subject to automatic release recall. This information is made visible for all operators to help them pinpoint in exactly which Products and Environments active vulnerabilities are deployed.
To make it easier for first-time Apollo users to manage an environment, we have introduced a dedicated in-app walkthrough to guide new environment owners through the steps required to connect an Apollo agent. This update also includes new manifest generation capabilities and a clear workflow to enable self-service setup for new users.
Creating new environments or products along with many other settings updates were only possible for users with highly privileged administrative control within an Apollo organization. These changes are now all possible through the Change Request system. Any user can propose changes to settings, and the policy engine controls determine whether those actions are auto-approved or require a specific approval.
Ownership, promotion, and rollout settings for products can now be configured directly from the products list. These changes previously required navigating to a separate settings page. That page has been removed now that there is a clearer entrypoint.
We've added a new default landing page to Apollo, focused on providing more information about key Apollo concepts. In particular, this landing page describes Environments, products, and teams - concepts that Apollo users must understand and configure when getting started with the platform.
You're reading this on the new public Apollo documentation site! Apollo's documentation will provide descriptions of core concepts, tutorials, and developer-focused specifications, and will be connected to the Apollo platform to provide specific help or context where appropriate.
Many Apollo-supported installations of software are only accessible from specific air-gapped secure networks with strict data controls. That means that new releases of Apollo products need to go through a special process in order to be deployed into these environments.
Apollo supports this process through an application now available in the primary sidebar navigation called the Payload Bundler. Namespace owners are the primary users of the Payload Bundler: software operators who use Apollo to make sure the environments in these secure spaces are healthy and up-to-date. They can easily prepare and manage "bundles" of software with prepared updates for all tracked environments in a remote namespace. Apollo ensures these bundles contain the releases, settings, and metadata that are critical to keeping these critical applications and environments working.
Authorization in Apollo is based on the concept of Teams. To make it easier to determine the team responsible for Products, Environments, or Installations, we have improved the interface for viewing a user's identity and team membership. The user settings page now includes a Profile & Preferences panel where you can see all teams for which the current user is a member or administrator. Additionally, the navigation sidebar now provides quick access to the full logged-in user ID, a logout button, and a link to the Profile & Preferences settings panel.
We've introduced an improved sidebar navigation component. This component contains quick links to all of the key concepts, owned environments, key tools or settings, and more.