live wire
▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel
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