RHEL dedicated servers

A RHEL dedicated server is a physical, single-tenant machine running Red Hat Enterprise Linux directly on the hardware — no virtualisation layer between your workload and the CPU, memory, and NVMe. You get full root, every core, and the certified, support-backed platform that enterprise software and compliance regimes are written against.

RHEL is licensed by subscription rather than sold outright, so the model on bare metal is bring-your-own: you attach your existing Red Hat entitlement to the machine. If you want the RHEL platform without a subscription, AlmaLinux and Rocky Linux are free, RHEL-compatible rebuilds we provision at no cost — the same binaries, minus the vendor support relationship.

Weighing RHEL against the free rebuilds? Read our Linux dedicated server guide.

How a RHEL subscription attaches to a physical server

RHEL is not a one-time purchase — the software is entitled by a Red Hat subscription, and that subscription is what buys you certified errata, a support SLA, and access to the supported life cycle. On a Serverside machine you bring your own: we deploy the OS and hand you root, then you register the box against your Red Hat organisation and it starts pulling updates from Red Hat’s CDN.

Registration is a single command — subscription-manager register with your organisation ID and an activation key — after which the system is entitled. Red Hat’s current model is Simple Content Access (SCA), the default for accounts today: once a system is registered it has content access without an explicit attach step, so the old subscription-manager attach dance is now a no-op. Note that enabling SCA on an organisation is a one-way change.

You are not limited to our images: mount your own RHEL installer ISO and drive the install yourself from the KVM console, watching the graphical or text installer boot exactly as you would on hardware in front of you. That is the clean path when you need to lay the machine out against your own kickstart or partitioning standard before you attach your Red Hat subscription — bring your own installer, bring your own entitlement.

Each entitlement is tied to a system, so a bare-metal host consumes one subscription for the physical machine regardless of how many cores it has — a dense EPYC box costs no more to entitle than a small one. Because you have full root and the server is unmanaged by default, how you register, which repositories you enable, and how you patch are entirely yours to control.

Current releases and the 10-year life cycle

RHEL 10 is the current major release, generally available since May 2025 and built on a modern kernel and toolchain. RHEL 9 remains in Full Support into 2027 with maintenance running to 2032, and RHEL 8 is in its Maintenance phase through 2029 — so all three are viable targets depending on what your application stack certifies against.

Every RHEL major gets a ten-year life cycle: roughly five years of Full Support (new features and hardware enablement), then five years of Maintenance Support (security and urgent bug fixes on the final minor), followed by an optional Extended Life phase. That decade-long, predictable window is a core reason regulated and long-lived workloads standardise on RHEL rather than a faster-moving distribution.

If you need to freeze on a specific minor release — because an ISV certifies only against, say, RHEL 9.4 — Extended Update Support (EUS) keeps a given minor patched for 24 months, and the SAP-focused E4S stream extends that to four years. These add-ons ride on your subscription; the hardware underneath is the same machine we deploy in under a minute.

RHEL, AlmaLinux, and Rocky after the 2023 source change

In mid-2023 Red Hat made CentOS Stream the sole public repository for RHEL-related source code, ending the previous practice of publishing per-release sources to git.centos.org. Paying Red Hat customers still receive full RHEL sources through the Customer Portal; the change specifically affected downstream rebuilds that had relied on those public sources to produce 1:1 binary copies.

The two major community rebuilds responded differently. AlmaLinux shifted its goal from "1:1 bug-for-bug" to Application Binary Interface (ABI) compatibility — software certified for RHEL still runs, but Alma no longer promises byte-identical packages. Rocky Linux, whose backers helped form the Open Enterprise Linux Association (OpenELA) with Oracle and SUSE, continues to aim for bug-for-bug RHEL compatibility sourced through OpenELA. Both are free, and we provision either at no cost.

For most self-supported workloads, a rebuild is the pragmatic choice: you get the RHEL platform and ecosystem without a subscription. You reach for genuine RHEL when the support relationship, certified errata, or vendor sign-off is the point — which is exactly what the next section is about.

When paid RHEL beats a free rebuild — and when it doesn’t

The rebuilds are binary-compatible, so the deciding factor is rarely the software itself — it is the paperwork and the vendor relationship around it. Genuine RHEL earns its subscription when a third party is on the hook:

• ISV certification: SAP, Oracle Database, and much commercial middleware are certified and supported only on RHEL (or its SAP/E4S variants), and vendors may decline to troubleshoot on a rebuild
• Compliance regimes that mandate a supported, vendor-backed OS with an SLA and traceable errata
• Hardware and platform certification, where a specific server or accelerator is validated against RHEL
• Fleet management via Red Hat Lightspeed (formerly Insights) and Satellite for vulnerability, patch, and drift visibility at scale
• Conversely: for a self-hosted web tier, container hosts, CI runners, or internal tooling, AlmaLinux or Rocky give you the same platform for free — no subscription to track, one fewer renewal

SELinux enforcing by default

RHEL ships with SELinux in enforcing mode out of the box — mandatory access control confining processes to labelled policy, so a compromised daemon is boxed into what its type is permitted to touch rather than inheriting the caller’s rights. On Debian and Ubuntu the equivalent layer is AppArmor; on RHEL, SELinux is the native, default posture and the ecosystem’s policies assume it is on.

Operationally on a dedicated server that means allocating time for context and boolean tuning rather than reflexively setting it permissive: label your data directories correctly (restorecon, semanage fcontext), flip the relevant sebooleans for services like httpd or containers, and read the audit log (ausearch, sealert) when something is denied. Leaving SELinux enforcing is a meaningful part of why RHEL is trusted in regulated environments, so it is worth keeping on.

Segment the network the way an audit expects

SELinux confines processes on the host; the network layer confines what can reach them, and RHEL shops usually need both. You can put your servers on a private network between machines and run a proper multi-tier deployment — the app tier talking to the database tier over the private interface, with a public interface only on the front-end that has to face users. The database never has to hold a public address at all.

For compliance-driven segmentation you can define your own network DMZ: expose only the tier that must be reachable and keep internal systems isolated behind it, which is exactly the topology an auditor expects to see documented when your workload carries PCI, HIPAA, or similar obligations. Because you define the segmentation yourself, the boundary matches your controls rather than a shared provider default.

RHEL-native tooling

The day-to-day management surface is the Red Hat stack you would expect, and all of it works the same on genuine RHEL or a rebuild:

• dnf and RPM for package and transaction management, with modularity and application streams
• kpatch live kernel patching to apply critical kernel CVEs without rebooting — supported since RHEL 8.1 — which pairs well with a long-uptime bare-metal host
• Image Builder (osbuild) to produce reproducible custom OS images you can redeploy across a fleet
• Red Hat Lightspeed and Satellite (subscription features) for advisories, patch orchestration, and kpatch rollout at scale
• System roles and Ansible content for repeatable configuration on a machine you own end to end