Cloud Foundry Summit 2026

Abstract:
How do you reduce Cloud Foundry infrastructure costs during idle periods without pain on Monday morning? Especially, sandbox/qa platforms may not be needed in full measure over the weekend or between testing phases. This talk covers the do’s and don’ts of automated scaling.

Outline & Takeaways:
Which components can be easily scaled, and what should be prevented?
What needs to be temporarily manipulated regarding the configuration?
How to safely scale without interruption?

Accurately metering reserved application memory can be essential for billing. Traditionally, Cloud Foundry application memory metering solutions have relied on application usage events.

This session introduces an alternative approach to reserved application memory metering based on periodic sampling rather than application usage events. We will discuss the motivation behind it, explain how the solution works, and highlight the benefits it provides.

Over the years, Cloud Foundry has been more than just a platform to me. It has shaped how I think about developer experience, platform engineering, operational excellence, organizational culture, business strategy, and the relationship between developers and operators.

Like many people in this community, I have spent countless hours building, migrating, operating, upgrading, troubleshooting, and advocating for CF. Through those experiences, I developed a deep appreciation for the values behind the platform: simplicity, automation, reliability, and enabling developers to focus on delivering value.

This lightning talk is a personal project and a creative experiment. Rather than presenting architecture diagrams or technical deep dives, I will share an original song inspired by my experiences with Cloud Foundry. The lyrics celebrate the people, components, and ideas that make Cloud Foundry special: from BOSH and Diego to Buildpacks, UAA, and Genesis, and most importantly, the philosophy that great platforms should make complexity disappear.

This is Cloud Foundry through my eyes: not just as technology, but as a community, a culture, and a philosophy that continues to inspire me.

Getting classic Cloud Foundry running locally with BOSH can be a big challenge for both newcomers and experienced developers. This entry barrier discourages first-time users before they can experience their first cf push, and the complex setup process slows down development and testing workflows for everyone. This lightning talk demonstrates kind-deployment, a containerized alternative that provides the complete Cloud Foundry ecosystem including UAA, Diego, CAPI, and all the familiar components without requiring BOSH or virtual machines.

The approach uses the exact same Cloud Foundry components you already know, simply deployed through a different installation method. In this session, we will walk through setting up this environment and explore practical use cases such as local component development and quick integration testing across a full Cloud Foundry landscape.

How do you approach continuous deployment pipelines when your systems have fundamentally different architectures? We recently tackled this question while implementing pipelines for two Cloud Foundry components: App Autoscaler and Application Memory Metering (AMM).

App Autoscaler is a complex, multi-service system with numerous applications and dependencies. AMM is a straightforward single-application service. Despite their architectural differences, both needed continuous deployment pipelines—but the paths we took were quite different.

In this talk, we'll compare the two Python pipeline implementations, exploring how system complexity shapes your deployment strategy, what architectural patterns emerged, and which lessons apply regardless of your system's scale.

Abstract:
The Prometheus BOSH Release helps set up a powerful monitoring system for Cloud Foundry and beyond. With the Prometheus BOSH Release v31.0.0, Prometheus v3 has been introduced, which brings a major upgrade. Such major upgrades need to be planned in advance and implemented in a way that is applicable to operators to prevent issues and risks, such as data loss. This talk is not about the binary update, but migration design.

Outline & Takeaways:
What changed between Prometheus v2 and v3
How much effort is needed for such a migration (Maintainer / Operator)
How to design such a migration to minimize risks for the operator

Building a Cloud Provider Interface (CPI) is no quick journey. After a previous attempt to open source the STACKIT BOSH CPI before the last CF Day fell through, Maurice is thrilled to finally announce its official open source release at this Cloud Foundry Summit! In this 5-minute lightning talk, Maurice will quickly show what is implemented and powering Cloud Foundry installations in production for several month now.

In recent years, AI has completely transformed programming. No one writes code anymore. Almost No one. However, What happens after code gets written is still largely governed by traditional software release Paradigms.
A large number of “ Vibe coders” tend to use Netlify or Vercel For deployment. The reason is easy to Decipher. Write your code and hand it off to a sophisticated method of deployment. This is limited by the language and frameworks One can use, In this case, JavaScript.
Which other platform has the capability to take code written in any language or framework and transform that into an immutable artifact, Deployable to staging? You You guessed it, right - Cloud foundry. And the reason it can is because of buildpacks.
In this talk, I intend to cover some of the internals of buildpacks and the developer experience they enable, especially when paired with code generation tools.

Running Large Language Models typically requires massive, expensive GPU resources—but the landscape is shifting rapidly. In this 5-minute lightning talk, Maurice will demonstrate how to deploy a fully functional AI inference engine directly on Cloud Foundry using standard compute resources.

Maurice will showcase the magic of 1.58-bit ternary models, specifically running Falcon3 Edge via the BitNet framework. The attendees will see how these heavily quantized, low-memory models make it perfectly viable to push an LLM as a standard CF app without melting the underlying infrastructure. Maurice will quickly walk the attendees through the deployment steps, highlight the container footprint, and prove it works with a live, on-platform prompt execution.

CI is where most CF contributors find out their change broke something. By then the context is cold and the feedback loop is long. cf-on-kind already gives us a fast local CF - what's missing is the glue: figuring out which image to rebuild for this change, swapping it into the cluster, and finding a sensible test command for this release.

This lightning talk shows a small portable skill for your coding agent that automates that glue. The agent reads the repo, calls a deterministic redeploy script, picks a test command from the release's conventions, and reports back. It's a few hundred lines of code + Markdown.

The broader point: coding agents are a practical way to shift verification left without replacing existing toolchains.