Rainbond v6.7.0 Release | Native K8s Resource Management with YAML and Helm Workflows

If previous versions of Rainbond were stronger on application-centric delivery, helping teams build, ship, and operate cloud-native applications efficiently, then v6.7.0 takes another major step toward Kubernetes-native workflows.

The biggest update in this release is the official introduction of native K8s resource management. Rainbond no longer serves only its internal application model. It can now more fully accommodate Kubernetes native objects, raw YAML, Helm releases, and existing namespaces. For teams already working deeply with Kubernetes, this is a very meaningful capability upgrade.

At the same time, v6.7.0 also continues to strengthen Rainbond across both delivery and operations:

• On the build side, source-code builds now fully support CNB (Cloud Native Buildpacks)
• On the application operations side, application snapshots are now available, completing the workflow for version archiving, export, publishing, and rollback

Native K8s Resource Management: Bringing Native Workflows into Rainbond Naturally

The most important update in v6.7.0 is the official support for native K8s resource management. With this capability set, Rainbond now provides a more complete path for managing Kubernetes-native resources. Users can now:

• Connect existing namespaces and continue managing resources in a native way
• Create and maintain Kubernetes objects directly from raw YAML
• Install, upgrade, and manage applications as Helm releases
• View workloads, pods, networking, configuration, and storage resources from a unified team-level view
• Manage platform-level resources such as StorageClass, PV, and PVC from the platform administration side

This means that whether you are taking over existing cluster resources or handling ongoing Kubernetes-native operations and troubleshooting, Rainbond can now provide a more unified entry point and management view.

Compared with previous versions, the biggest difference is that Rainbond is no longer limited to platform-specific application models when handling delivery workflows. In the past, if a team wanted to bring existing YAML, Helm charts, or namespaces under Rainbond management, they often had to adapt them into the platform model first. In v6.7.0, users can keep native Kubernetes semantics and continue using familiar YAML and Helm workflows directly.

In other words, from this version onward, Rainbond supports two parallel paths: teams can continue using the application model for standardized delivery, or preserve native Kubernetes object structures and manage them in a Kubernetes-native way.

Source-Code Builds Now Fully Support CNB: Faster, Smaller, and More Standardized

On the delivery side, v6.7.0 also introduces an important upgrade: source-code builds now fully support CNB (Cloud Native Buildpacks), with Paketo Buildpacks as the core implementation.

One important note: starting from v6.7.0, new source-based components use the new CNB + Paketo Buildpacks pipeline by default. Existing components upgraded from older versions will keep their previous build mode and can continue running as-is. If there are no compatibility constraints, the new CNB path is recommended going forward.

Compared with the traditional slug-based build approach, the benefits of this upgrade are clear:

• Faster builds: in common source-code build scenarios, the time from code to image can be significantly reduced
• Smaller final images: build outputs are more compact, reducing unnecessary runtime overhead and improving image distribution and deployment efficiency
• More standardized artifacts: images generated through Cloud Native Buildpacks align more closely with cloud-native best practices, making later operations, migration, and ecosystem integration smoother

As one of the more mature Buildpacks implementations in the ecosystem, Paketo helps Rainbond move its source-code build pipeline toward a more standardized model. This is not just a replacement of underlying build technology. It marks a shift from simply "being able to build" toward a build system that is more modern, more standardized, and more cloud-native.

At present, this new build pipeline already covers common language stacks including Java, Python, PHP, and .NET. For developers, the most direct gains are higher build efficiency and lighter images. For the platform itself, it also creates a more stable foundation for future build capability expansion and governance.

Application Snapshots: Clearer Version Archiving, Distribution, and Rollback

In addition to native K8s resource management and source-code build upgrades, v6.7.0 also introduces application snapshots.

Application snapshots preserve the version state of an application at a specific point in time, recording component orchestration, configuration, dependencies, and version metadata. The core problem this solves is straightforward: when an application keeps changing, how do you keep a traceable, comparable, and rollback-ready baseline?

With application snapshots, users can:

• Save the current application state and build a version timeline
• Compare the current state with historical versions
• Export an application directly from a snapshot
• Publish a snapshot to the internal component library
• Roll back to a historical snapshot when problems occur

This capability is especially useful in scenarios such as:

• Preserving a milestone version after a round of feature or configuration changes
• Keeping a stable baseline before upgrades, migration, or refactoring
• Exporting a version for delivery or publishing it to an internal component library for reuse
• Quickly restoring a verified stable version after an unexpected change

It is worth noting that application snapshots store application-level metadata and orchestration state. They are not the same as VM snapshots, disk snapshots, or database backups. They are designed for application version management, not as a replacement for business data backup or disaster recovery.

With application snapshots, Rainbond further completes the application operations workflow, covering version archiving, version flow, and version rollback in a much clearer way.

Final Thoughts

Rainbond v6.7.0 is a highly focused release. Its most important change is the official support for native K8s resource management, allowing Rainbond to more naturally accommodate YAML, Helm, namespaces, and Kubernetes-native resource management scenarios. At the same time, source-code builds now embrace CNB + Paketo Buildpacks, making builds faster, images smaller, and delivery more standardized. With application snapshots added as well, the application version management workflow is now much more complete.

If previous versions of Rainbond were mainly about helping teams "get applications running," then starting with v6.7.0, Rainbond is going a step further by helping teams manage native resources, source-code builds, and application versions together.

Other Changes

• Helm Chart now supports OCI #2495
• Fixed a failure when creating applications with Helm #2514
• Fixed automatic certificate issuance failures
• Fixed the issue where re-uploading a package with the same name could not be extracted on the second build

Platform Upgrade

• Online environments: go to Platform Management -> Enterprise Settings -> Upgrade and perform the one-click upgrade.
• Offline environments: please refer to the offline upgrade documentation.

Full Changelog: https://github.com/goodrain/rainbond/compare/v6.6.2-release...v6.7.0-release