Cloud Foundry Summit 2026

Cloud Foundry was built for boring operations. Rolling deploys, canaries, health checks, resurrection, and high availability are part of how the platform works. This talk applies those same ideas to a larger change: moving a live Cloud Foundry foundation from one IaaS to another without application downtime.

We will describe a real migration from an on-prem IaaS to OpenStack. The talk will cover the migration strategy, BOSH and CPI considerations, network and routing changes, foundation sequencing, service constraints, validation points, rollback planning, and the operational choices that kept the platform available throughout the move.

This is not a rebuild story or "The snap migration". It is a walking story: moving the platform in controlled steps while preserving developer experience, application availability, and operator confidence.

This talk explores how we achieved a fully declarative deployment model on Cloud Foundry while re-platforming the App Autoscaler from a BOSH deployment to CF-native applications.

BOSH deployments provided reproducible manifests, environment-specific customization through ops files and a clear separation between deployment intent and deployment execution. Recreating those capabilities with standard Cloud Foundry manifests proved challenging for a system composed of multiple services, applications, and dependencies.

In this session, we'll share the lesson learned from modernizing App Autoscaler and how we used Cloud Foundry Foundation Project, MultiApps Controller and the MTA (Multi-Target Application) model to get to a declarative deployment experience for complex Cloud Foundry applications. We will demonstrate how MultiApps and the MTA model helped us manage configurations, coordinate multiple components, and deliver consistent deployments across environments.

Attendees will learn how MultiApps project can simplify the deployment and operation of complex Cloud Foundry applications through declarative configuration, deployment orchestration and consistent environment management.

Anyone who has tried to manage Cloud Foundry network and route policies via infrastructure-as-code knows the pain: everything revolves around org, space, and app GUIDs, values that are not meant for human consumption.
We built a pragmatic solution, yes, a bit of “duct tape”, that abstracts away GUIDs and allows policies to be defined using familiar org, space, and application names. The result is a simpler, safer, and far more maintainable policy management.
Beyond usability, we also address a key challenge: securely managing network policies between orgs and spaces owned by different teams.
In this talk, we’ll share:

* The design and trade-offs of our approach.
* How we handle cross-org policy ownership safely.
* Lessons learned from running this in production.

Finally, we’ll open the discussion to the broader community: should this kind of “duct tape” evolve into a standard Cloud Foundry capability? What would it take to make that transition, and where should it live in the ecosystem?

Building a CPI is not only a matter of implementing methods. It is a set of design choices about how BOSH expresses placement, identity, storage, networking, recovery, and operator intent on a specific platform.

We learned this while building a Proxmox VE CPI for Cloud Foundry BOSH. As part of that work, we studied six existing CPIs—AWS, Azure, Google, OpenStack, vSphere, and Alicloud—from their handler code, not just their documentation. We looked for the techniques each CPI uses to preserve the BOSH contract while adapting to its IaaS.

This session distills that work into a practical guide for CPI authors, platform engineers, and BOSH operators. We will compare the concepts every CPI must handle: placement, lifecycle identity, disk and stemcell management, networking, long-running operations, retry boundaries, rollback, hooks, observability, and operator controls.

Proxmox is the case study, but the talk is about CPI design. We will show how platform capabilities shape implementation choices, what belongs in the CPI, what belongs in the platform, and what should remain configurable.

The Paketo Cloud Native Buildpack Repositories are highly automated to ensure automatic CVE fixes and version bumps, but what happens when the automation gets stuck and no one is responsible to look after it? This talk describes the work that was done to “revive” the Ruby and PHP related Paketo buildpacks after being stuck for up to 2 years to in the end ensure automatic bumps and CVE fixes are happening again.

Join the Cloud Foundry Weekly crew for a show built around real-world Cloud Foundry users and, as we usually do, we're doing it live on stage. We're bringing users and contributors into the same conversation to talk about how their organizations actually run on Cloud Foundry day to day, focusing on the practical stuff rather than the marketing version. We'll close out the show by connecting the dots between the work contributors put in and how it shows up in the real world, powering the systems people rely on every day.
Are you running Cloud Foundry in production? We want to hear your story. Come join us on stage and tell the community how CF works for you.

Cloud Foundry has quietly become the platform powering agentic AI development across Broadcom's engineering org. This is the story of how that happened.
When Broadcom's Global Technology Organization rolled out AI coding assistants to developers, the hard part wasn't the model; it was governance. MCP is still an early, fast-moving standard, not yet enterprise-ready, and giving agents access to internal tools raised real stakes: protecting intellectual property, keeping the software supply chain intact, and preserving data privacy. GTO's first instinct was to lock MCP servers down, but that restriction blocked the very goal of scaling coding assistants across the company. The real problem wasn't whether to allow MCP; it was how to enable it safely.
This talk shows how GTO used Cloud Foundry as the application platform for Model Context Protocol servers: pushing MCP servers as first-class CF apps, fronting them with platform routing and identity, chaining agent functions across internal tools, and gaining the per-server observability needed to tune performance and control costs.

AI agents are becoming operational workloads. Picture a pull-request reviewer powered by an AI coding agent: when a PR opens, it clones the repository, analyzes the changes, runs tests, performs a security review, leaves comments, and disappears. What would it take to run that on Cloud Foundry?

First we need a way to think about it. We introduce a framework for understanding what AI agents need from a platform — a small set of dimensions that let you characterize any agent and reason precisely about the runtime it requires — built from first principles and used to separate the easy requirements from the genuinely hard ones.

With the framework in hand, we put Cloud Foundry to the test against two leading agent technologies: Claude Code and Claude Managed Agents. The analysis stays grounded in working code — a live cf push deploys a Claude Code agent — then turns to what it would take to host the session containers behind a Claude Managed Agents environment.

By the end, attendees will know what AI agents demand from a platform, how Cloud Foundry measures up today, and what is already possible.

RFC055 introduced identity-aware routing to Cloud Foundry, enabling per-domain mTLS and platform-enforced authorization at the route level.

But the more interesting story is how it was created.
This session reflects on shaping a large, cross-cutting RFC as a largely AI-assisted effort—covering both the technical outcome and the contribution process itself.

Topics include:
- The feature: identity-aware domains, route policies, and platform-enforced authorization
- The process: using AI to draft, iterate, and expand a complex RFC spanning multiple components
- What worked well—and what didn’t when collaborating with the community
- Where existing review and working group structures struggled with large, single-author contributions

The session explores how contribution models may need to evolve to better digest AI-accelerated proposals that cut across project boundaries.

A candid look at building features, learning faster, and adapting the Cloud Foundry contribution process for the next wave of contributors.