live wire
▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security
upstreambeat.ai
newsAI

OpenShift AI Self-Managed 3.3 leaves full support

Red Hat’s lifecycle record puts the 3.3 release past its full-support end date; customers should verify a supported channel and upgrade path rather than infer an undocumented next phase.

OpenShift AI 3.3 support lifecycle timeline
Timeline: dates from the story
By The News Desk· Oct 9, 2026the quick take — two AI hosts go live when you do

Red Hat OpenShift AI Self-Managed 3.3 reached the end of its Full Support window on Oct. 5, 2026, according to Red Hat’s product lifecycle record. The release became generally available March 5.

That is the lifecycle change the published data establishes. Red Hat’s table does not show an Extended Update Support window for 3.3, and this desk found no first-party statement naming a different post-Oct. 5 support phase for the release. Customers should therefore avoid treating the date as evidence that 3.3 automatically entered Maintenance Support.

What ended with Full Support

Red Hat’s OpenShift AI lifecycle policy says that during Full Support, qualified Critical, Important and Moderate security issues with a CVSS score of 7.0 or higher are released as fixes become available. Urgent and selected high-priority bug fixes also qualify, while other available fixes and qualified patches may arrive through periodic updates.

The policy says features and bug fixes are targeted at the latest versions in Full Support and expects customers to upgrade to the most current supported OpenShift AI version in a timely fashion. It also says customers must run the latest available version in their selected channel to receive support.

Those general rules do not, by themselves, label 3.3’s present phase. The precise operational takeaway is narrower: 3.3 is no longer inside the Full Support window described above.

What platform teams should check

OpenShift AI maintains a release schedule independent of OpenShift Container Platform, and Red Hat links separately to supported-configuration guidance. Before changing channels or versions, platform teams should confirm the target OpenShift AI release, its supported OpenShift versions and the upgrade sequence allowed by Operator Lifecycle Manager.

Red Hat says the unnumbered GA channel automatically advances deployments to the latest GA minor release, while numbered ga-x.y channels let customers plan the next GA upgrade. Its policy supports single-step upgrades from the most recent previous minor GA version to the latest minor GA version.

Teams still running 3.3 should inventory those environments, confirm that their installed micro release and channel remain supported, and plan a tested move using Red Hat’s documented path. The Oct. 5 boundary is a reason to check support status and upgrade planning—not to assume a lifecycle phase the source does not name.

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