live wire
▸INTEGRATION · Apache Camel exposes incident and web search as parallel tools for a local agentApache Camel▸AI · Red Hat makes confidential GPU AI GA and previews VM-isolated Agent Sandbox (Aug. 4)Red Hat Blog▸SECURITY · Red Hat fixes Important MariaDB GIS memory-corruption flaw in Hardened ImagesRed Hat Product Security▸SECURITY · Red Hat restores CVE pages after a CWE dependency outage; monitoring continuesRed Hat status▸PLATFORM · Red Hat implements a fix for docs.redhat.com degradation and begins monitoringRed Hat status▸AI · vLLM combines PCP, DCP and host-memory offload to serve 1M-token GLM-5.3 contextsvLLM▸AI · vLLM ships day-zero MiniMax-M3.1-Flash support across NVIDIA and AMD GPUsvLLM▸SECURITY · Red Hat revokes compromised eMudhra certificates across RHEL and OpenShift trust storesRed Hat Product Security▸SECURITY · Red Hat rates PHP2Shell request-handling flaws Important; fixes are rolling outRed Hat Product Security▸AI · IBM maps GPU observability and FinOps controls across OpenShift clustersIBM Community▸IDENTITY · Red Hat shows Data Grid authentication through Keycloak 26 on OpenShiftRed Hat Developer▸AI · Red Hat layers tenant isolation, tool authorization and rate limits onto MCP gatewaysRed Hat Developer▸DATA · Red Hat maps direct LDAP and LDAPS authentication for Data Grid on OpenShiftRed Hat Developer▸PLATFORM · OpenShift Service Mesh 3.4.3 restores strict enforcement of OpenShift TLS cipher profilesRed Hat release notes▸INTEGRATION · Apache Camel exposes incident and web search as parallel tools for a local agentApache Camel▸AI · Red Hat makes confidential GPU AI GA and previews VM-isolated Agent Sandbox (Aug. 4)Red Hat Blog▸SECURITY · Red Hat fixes Important MariaDB GIS memory-corruption flaw in Hardened ImagesRed Hat Product Security▸SECURITY · Red Hat restores CVE pages after a CWE dependency outage; monitoring continuesRed Hat status▸PLATFORM · Red Hat implements a fix for docs.redhat.com degradation and begins monitoringRed Hat status▸AI · vLLM combines PCP, DCP and host-memory offload to serve 1M-token GLM-5.3 contextsvLLM▸AI · vLLM ships day-zero MiniMax-M3.1-Flash support across NVIDIA and AMD GPUsvLLM▸SECURITY · Red Hat revokes compromised eMudhra certificates across RHEL and OpenShift trust storesRed Hat Product Security▸SECURITY · Red Hat rates PHP2Shell request-handling flaws Important; fixes are rolling outRed Hat Product Security▸AI · IBM maps GPU observability and FinOps controls across OpenShift clustersIBM Community▸IDENTITY · Red Hat shows Data Grid authentication through Keycloak 26 on OpenShiftRed Hat Developer▸AI · Red Hat layers tenant isolation, tool authorization and rate limits onto MCP gatewaysRed Hat Developer▸DATA · Red Hat maps direct LDAP and LDAPS authentication for Data Grid on OpenShiftRed Hat Developer▸PLATFORM · OpenShift Service Mesh 3.4.3 restores strict enforcement of OpenShift TLS cipher profilesRed Hat release notes
upstreambeat.ai
guideDEVELOPER HUB

Developer Hub 2.1 makes custom plug-ins an upgrade prerequisite, not an afterthought

Red Hat’s migration guide says legacy Scalprum mounts can stop the portal at startup, while standalone OCI plug-in images and Backstage extension blueprints redraw the packaging boundary.

By The News Desk· Oct 23, 2026the quick take — two AI hosts go live when you do

Red Hat is warning platform teams not to treat the Red Hat Developer Hub 2.1 upgrade as a routine image bump. The release removes the old front-end system and Scalprum-based runtime mounts, making custom plug-in migration a prerequisite for a clean startup rather than a post-upgrade cleanup task.

What changes in 2.1

Developer Hub 1.10 let adopters switch between the old and new Backstage front ends with environment flags. In 2.1, the app-next architecture becomes the application shell, and plug-ins that still depend on dynamicPlugins.frontend Scalprum mount points will not load. Red Hat says those legacy plug-ins can cause the deployment to fail during startup.

The replacement is upstream Backstage’s extension-blueprint model. Plug-in authors define pages, entity cards and other placement in TypeScript, then expose an ./alpha entry point alongside the existing root export. That dual-export pattern lets one package continue serving Developer Hub 1.10 while it is prepared for 2.1.

Configuration changes with the code. Routes, cards and default placement move out of scattered dynamic-plug-in YAML and into plug-in defaults, while operators use app.extensions and app.routes.bindings for overrides. One subtle migration risk is that app.extensions is an array: a higher-priority configuration file replaces the whole array rather than merging entries by identifier.

Packaging moves out of the core image

Developer Hub 2.1 also removes dynamic plug-in wrappers from the main product container. Red Hat says wrappers will instead ship as standalone OCI images built through Konflux and published on Quay. That separates plug-in fixes from the core Developer Hub release cycle and gives platform teams a more explicit artifact to promote and pin.

For custom authors, Red Hat’s six-step workflow is to inventory exports and mount points, add the alpha export, convert React components to Backstage blueprints, update the package map, add a new-front-end development harness, and verify with TypeScript and a build.

What platform teams should do now

Before moving a production portal to 2.1, teams should identify every custom front-end plug-in, convert legacy mount configuration, remove bundled-wrapper paths and test the resulting portal against an early 2.1 image. Red Hat provides experimental coding-agent skills for both plug-in migration and configuration conversion, but labels them community utilities rather than supported product features.

The practical gate is simple: a staging portal should boot with every custom route and entity card accounted for before the production upgrade begins. Teams that wait until deployment time risk discovering that the portal shell itself cannot start.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk