For platform teams building cloud-native software, the local developer workstation has evolved from a productivity tool into an operational risk. Developers lose valuable time wrestling with local VM setups or hunting down "works on my machine" bugs. As local environments diverge, architectural friction stalls engineering progress and pulls platform teams into endless troubleshooting. The post Build a multi-tenant platform with OpenShift Dev Spaces appeared first on Red Hat Developer.
At the 2026 Red Hat Summit, we offered a hands-on lab titled "AI-powered Red Hat Enterprise Linux management: Get hands-on with Model Context Protocol (MCP) servers for Red Hat Lightspeed, Satellite, and Red Hat Enterprise Linux." The post Manage RHEL with MCP servers and Red Hat Lightspeed appeared first on Red Hat Developer.
In this article, we explore what network quality of service (QoS) means, preview an upcoming native capability that's addressing it declaratively, and then step through a practical solution you can deploy today using the Linux traffic control (tc) command. We'll set up a full reproducer lab, run it, and look at real test results that demonstrate production traffic maintaining throughput while background traffic is deprioritised under contention. The post Egress network quality of service on Red Hat OpenShift appeared first on Red Hat Developer.
Red Hat's migration toolkit for applications 8.3 is now generally available, bringing agentic code modernization, direct storage mobility, and automated pipeline generation to OpenShift. Upgrading workloads to cloud-native architectures often means struggling with legacy code and complex stateful data transfers. Migration toolkit for applications 8.3 simplifies this process with automated multi-agent code transformation, live storage migrations, and pre-built deployment pipelines. The post Migration toolkit for applications 8.3: Agentic code modernization, PVC mobility, and out-of-the-box…
Containerizing applications is an important step in modern software development. It helps with consistency, portability, and reliability across different environments. The Paicku project helps you streamline the process of containerization and testing so you can be sure that your application works as expected during development and once it's been released.Paicku is a command-line tool, as well as a Node.js library, that lets you containerize applications with Cloud Native Buildpacks. You can run Paicku from the command-line or from Node.js. The post Use Paicku to containerize and test any app…
Innovation is a core value of Red Hat's emerging technologies team. Beyond simply developing brilliant ideas, we work to align them within Red Hat's portfolio—ensuring every concept addresses a genuine need and fits purposefully into our broader ecosystem. The post How IdeaBot drives AI innovation workflows on OpenShift appeared first on Red Hat Developer.
In modern enterprise data centers running on bare-metal infrastructure, resource efficiency and agility are paramount. Traditionally, deploying a new Red Hat OpenShift cluster required dedicating at least 3 physical nodes for the control plane. When multiplying this across development, test, and production environments, the hardware footprint grows rapidly, leaving valuable compute power underutilized. The post Declarative clusters: GitOps deployment of hosted control planes on Red Hat OpenShift Virtualization appeared first on Red Hat Developer.
Imagine deploying a pair of agents to Red Hat OpenShift and watching them thrive. But fast-forward 6 months and you find your environment cluttered with 40 of them, their purposes largely unknown. Redundant agents emerge across namespaces, duplicating work. Meanwhile, a security review uncovers agents utilizing static API keys over insecure HTTP. When an agent falters, the lack of tracing makes it impossible to distinguish between model hallucinations, tool errors, or downstream failures. The post Rossoctl for agent discoverability, security, and observability on Kubernetes appeared first on…
You are a platform engineer running Red Hat OpenShift. A development team runs a monitoring sidecar as a non-root user that needs to perform ICMP ping health checks. They need CAP_NET_RAW, the capability required for raw socket access. Straightforward enough, and the security context constraints (SCC) is configured to allow the capability: The post Why your non-root container dropped its capabilities (and how to fix it) appeared first on Red Hat Developer.
Your LangGraph agent can call tools, follow a system prompt, and answer domain questions. That's not the same as being safe to put in front of users. Without guardrails, a banking customer service agent might explain how to commit check fraud, reply to profanity, or happily help you bake a chocolate cake. The post Add NeMo Guardrails to a LangGraph agent on OpenShift AI appeared first on Red Hat Developer.
As enterprise generative AI applications move to production, platform engineers face a key challenge: balancing the flexibility of LLM-as-a-judge guardrails with the reliability and portability of traditional classifiers that require custom training data. The recent emergence of "decision models"—highlighted by TypeSafe AI's recent announcement of Jev and “System One” models—promises a flexible middle ground by producing fixed “decisions” given a state and a list of questions rather than generating text. The post Benchmarking AI decision models against traditional guardrails appeared first on…
Kube AuthKit is a lightweight Python library that unifies Kubernetes and Red Hat OpenShift authentication behind a single, consistent API. Whether you're running locally with kubeconfig, inside a pod with a service account, or authenticating via OIDC or OpenShift OAuth—it's one line of code. The post Kube AuthKit: Unified Kubernetes and OpenShift auth in Python appeared first on Red Hat Developer.
GPU demand for AI workloads is surging, and sharing GPUs fairly across teams remains one of the hardest problems in cluster management. The Kubernetes device plug-in model was never built for this. It treats GPUs as anonymous, countable integers—for example, NVIDIA GPUs are requested as nvidia.com/gpu: 1. This tells the scheduler nothing about the device, not its VRAM, compute capability, or whether it's a full 80 GB GPU or a 5 GB slice of a partitioned one. The post Smarter GPU sharing: How Red Hat build of Kueue works with dynamic resource allocation appeared first on Red Hat Developer.
In my article Standardize project context with AGENTS.md and Agent Skills, I discussed agent context, how skills work, and how to share skills across projects and teams. If you followed along with that article, you now have skills in .agents/skills/, and maybe even a marketplace set up, which is a good foundation to build on. But how do you know your skills actually work? The post Master your skills: Building skills you can trust appeared first on Red Hat Developer.
Enterprise AI environments are increasingly moving from dedicated GPU servers toward shared accelerator infrastructure that can support multiple users, teams, and workloads on the same hardware. This shift creates an important infrastructure question: How can organizations increase GPU utilization while maintaining strong workload isolation and predictable performance? The post GPU virtualization at scale: AMD MI300X SR-IOV on Red Hat OpenStack Services on OpenShift appeared first on Red Hat Developer.
For years, the gold standard of infrastructure engineering and chaos testing was just uptime: Either a system survived a disruption and passed, or it crashed and failed. In the era of massive cloud-native deployments, however, this binary pass or fail metric no longer tells the whole story. A Kubernetes cluster or virtualized workload can technically remain operational through an experiment, yet silently drop packets, breach internal service level objectives (SLO), or suffer catastrophic performance degradation that ruins the end-user experience. The post Beyond pass or fail: The new era of…
You pull a model from Hugging Face. Maybe you merge in a LoRA. You run benchmarks, spot-check a few completions, and ship it. That workflow assumes the model you tested is the one you'll get in production. The post Backdoors in LLMs: Why model scanning isn't enough appeared first on Red Hat Developer.
Until recently, running distributed training on Kubernetes meant picking a framework-specific custom resource definition (CRD): PyTorchJob for PyTorch, TFJob for TensorFlow, MPIJob for Message Passing Interface (MPI). Each had different semantics, different failure behavior, and different ways of configuring the same fundamentals: how many nodes, how they find each other, and what happens when something breaks. The post Distributed training on OpenShift AI 3.4 with Kubeflow Trainer v2 appeared first on Red Hat Developer.
Your team just shipped an internal chatbot built on an open-weight model. It works great! It answers all of your questions, summarizes documents, and helps onboard new hires with scary efficiency. But then your security team asks, “Has anyone tested whether this thing can be jailbroken?”Jailbroken? What's that? The post Red team your AI model with garak appeared first on Red Hat Developer.
80 failed jobs, each with a trace log reaching 50,000 lines. That was a typical Monday morning for our platform team after a nightly build across multiple GPU and CPU architectures, where a single missing dependency could paint the entire dashboard red. The post How we cut CI failure triage from hours to minutes using AI appeared first on Red Hat Developer.
Read at the source
Your visit, your choice.
Optional Google Analytics helps us understand visits. Microsoft Clarity records masked interactions to improve the site. Optional tools stay off unless you choose them. Privacy details.