RHEL dedicated servers

Een RHEL dedicated server is een fysieke machine voor één gebruiker die Red Hat Enterprise Linux rechtstreeks op de hardware draait — geen virtualisatielaag tussen je workload en de CPU, het geheugen en de NVMe. Je krijgt volledige root, elke core en het gecertificeerde, support-gedekte platform waar enterprise-software en compliance-regimes tegen geschreven zijn.

RHEL wordt per abonnement gelicentieerd in plaats van los verkocht, dus het model op bare metal is bring-your-own: je koppelt je bestaande Red Hat-entitlement aan de machine. Wil je het RHEL-platform zonder abonnement, dan zijn AlmaLinux en Rocky Linux gratis, RHEL-compatibele rebuilds die we kosteloos uitrollen — dezelfde binaries, minus de support-relatie met de vendor.

RHEL afwegen tegen de gratis rebuilds? Lees onze gids voor Linux dedicated servers.

Hoe een RHEL-abonnement aan een fysieke server koppelt

RHEL is geen eenmalige aankoop — de software wordt geëntitled door een Red Hat-abonnement, en dat abonnement is wat je gecertificeerde errata, een support-SLA en toegang tot de ondersteunde lifecycle koopt. Op een Serverside-machine neem je je eigen mee: wij rollen het OS uit en geven je root, waarna je de machine registreert tegen je Red Hat-organisatie en die updates begint te halen van de CDN van Red Hat.

Registratie is één commando — subscription-manager register met je organisatie-ID en een activation key — waarna het systeem geëntitled is. Het huidige model van Red Hat is Simple Content Access (SCA), tegenwoordig de standaard voor accounts: zodra een systeem geregistreerd is, heeft het content-toegang zonder een expliciete attach-stap, dus de oude subscription-manager attach-dans is nu een no-op. Let op: SCA inschakelen op een organisatie is een eenrichtingswijziging.

Je bent niet gebonden aan onze images: mount je eigen RHEL-installer-ISO en draai de installatie zelf vanaf de KVM-console, terwijl je de grafische of tekst-installer ziet booten precies zoals op hardware die voor je staat. Dat is het schone pad wanneer je de machine wilt inrichten volgens je eigen kickstart- of partitioneringsstandaard voordat je je Red Hat-abonnement koppelt — neem je eigen installer mee, neem je eigen entitlement mee.

Elke entitlement is gebonden aan een systeem, dus een bare-metal host verbruikt één abonnement voor de fysieke machine ongeacht hoeveel cores die heeft — een dichte EPYC-machine kost niet meer om te entitlen dan een kleine. Omdat je volledige root hebt en de server standaard unmanaged is, zijn hoe je registreert, welke repositories je inschakelt en hoe je patcht volledig aan jou.

Huidige releases en de 10-jarige lifecycle

RHEL 10 is de huidige major-release, algemeen beschikbaar sinds mei 2025 en gebouwd op een moderne kernel en toolchain. RHEL 9 blijft in Full Support tot in 2027 met onderhoud dat loopt tot 2032, en RHEL 8 zit in zijn Maintenance-fase tot 2029 — alle drie zijn dus haalbare doelen, afhankelijk van waar je applicatiestack tegen certificeert.

Elke RHEL-major krijgt een tienjarige lifecycle: ruwweg vijf jaar Full Support (nieuwe features en hardware-enablement), dan vijf jaar Maintenance Support (security- en dringende bugfixes op de laatste minor), gevolgd door een optionele Extended Life-fase. Dat decennium-lange, voorspelbare venster is een kernreden waarom gereguleerde en langlevende workloads standaardiseren op RHEL in plaats van op een sneller bewegende distributie.

Moet je bevriezen op een specifieke minor-release — omdat een ISV alleen tegen bijvoorbeeld RHEL 9.4 certificeert — dan houdt Extended Update Support (EUS) een gegeven minor 24 maanden gepatcht, en de op SAP gerichte E4S-stream rekt dat tot vier jaar. Deze add-ons rijden mee op je abonnement; de hardware eronder is dezelfde machine die we binnen een minuut uitrollen.

RHEL, AlmaLinux en Rocky na de bronwijziging van 2023

Halverwege 2023 maakte Red Hat CentOS Stream de enige publieke repository voor RHEL-gerelateerde broncode, en beëindigde het de vroegere praktijk van het publiceren van per-release-bronnen naar git.centos.org. Betalende Red Hat-klanten ontvangen nog steeds volledige RHEL-bronnen via het Customer Portal; de wijziging trof specifiek de downstream-rebuilds die op die publieke bronnen leunden om 1:1 binaire kopieën te produceren.

De twee grote community-rebuilds reageerden verschillend. AlmaLinux verlegde zijn doel van "1:1 bug-voor-bug" naar Application Binary Interface (ABI)-compatibiliteit — software gecertificeerd voor RHEL draait nog steeds, maar Alma belooft niet langer byte-identieke pakketten. Rocky Linux, waarvan de achterban hielp de Open Enterprise Linux Association (OpenELA) te vormen met Oracle en SUSE, blijft mikken op bug-voor-bug RHEL-compatibiliteit met bronnen via OpenELA. Beide zijn gratis, en we rollen elk kosteloos uit.

Voor de meeste self-supported workloads is een rebuild de pragmatische keuze: je krijgt het RHEL-platform en -ecosysteem zonder abonnement. Je grijpt naar echte RHEL wanneer de support-relatie, gecertificeerde errata of vendor-sign-off het punt zijn — wat precies is waar de volgende sectie over gaat.

Wanneer betaalde RHEL een gratis rebuild verslaat — en wanneer niet

De rebuilds zijn binair compatibel, dus de doorslaggevende factor is zelden de software zelf — het is het papierwerk en de vendor-relatie eromheen. Echte RHEL verdient zijn abonnement wanneer een derde partij aansprakelijk is:

• ISV-certificering: SAP, Oracle Database en veel commerciële middleware zijn alleen gecertificeerd en ondersteund op RHEL (of zijn SAP/E4S-varianten), en vendors kunnen weigeren te troubleshooten op een rebuild
• Compliance-regimes die een ondersteund, vendor-gedekt OS met een SLA en traceerbare errata verplichten
• Hardware- en platformcertificering, waar een specifieke server of accelerator tegen RHEL is gevalideerd
• Fleetbeheer via Red Hat Lightspeed (voorheen Insights) en Satellite voor zichtbaarheid op kwetsbaarheden, patches en drift op schaal
• Omgekeerd: voor een self-hosted weblaag, containerhosts, CI-runners of interne tooling geven AlmaLinux of Rocky je hetzelfde platform gratis — geen abonnement om bij te houden, één verlenging minder

SELinux standaard in enforcing

RHEL wordt out of the box geleverd met SELinux in enforcing-modus — mandatory access control die processen inperkt tot gelabelde policy, zodat een gecompromitteerde daemon wordt ingesloten tot wat zijn type mag aanraken in plaats van de rechten van de aanroeper te erven. Op Debian en Ubuntu is de equivalente laag AppArmor; op RHEL is SELinux de native, standaard houding en de policies van het ecosysteem gaan ervan uit dat het aanstaat.

Operationeel op een dedicated server betekent dat tijd inruimen voor context- en boolean-tuning in plaats van het reflexmatig op permissive zetten: label je datamappen correct (restorecon, semanage fcontext), zet de relevante sebooleans om voor diensten als httpd of containers, en lees de audit-log (ausearch, sealert) wanneer iets wordt geweigerd. SELinux in enforcing laten is een wezenlijk deel van waarom RHEL wordt vertrouwd in gereguleerde omgevingen, dus het is de moeite waard om het aan te houden.

Segmenteer het netwerk zoals een audit verwacht

SELinux perkt processen op de host in; de netwerklaag perkt in wat ze kan bereiken, en RHEL-shops hebben doorgaans beide nodig. Je kunt je servers op een privénetwerk tussen machines plaatsen en een echte multi-tier-deployment draaien — de app-tier die over de private interface met de database-tier praat, met een publieke interface alleen op de front-end die naar gebruikers moet wijzen. De database hoeft helemaal geen publiek adres te hebben.

Voor compliance-gedreven segmentatie kun je je eigen netwerk-DMZ definiëren: stel alleen de tier bloot die bereikbaar moet zijn en houd interne systemen erachter geïsoleerd, precies de topologie die een auditor gedocumenteerd verwacht te zien wanneer je workload PCI-, HIPAA- of vergelijkbare verplichtingen draagt. Omdat je de segmentatie zelf definieert, sluit de grens aan op je controls in plaats van op een gedeelde provider-default.

RHEL-native tooling

Het dagelijkse beheervlak is de Red Hat-stack die je zou verwachten, en dit alles werkt hetzelfde op echte RHEL of een rebuild:

• dnf en RPM voor pakket- en transactiebeheer, met modularity en application streams
• kpatch live kernel patching om kritieke kernel-CVE's toe te passen zonder reboot — ondersteund sinds RHEL 8.1 — wat goed past bij een bare-metal host met lange uptime
• Image Builder (osbuild) om reproduceerbare custom OS-images te maken die je over een fleet kunt uitrollen
• Red Hat Lightspeed en Satellite (abonnementsfeatures) voor advisories, patch-orkestratie en kpatch-uitrol op schaal
• System roles en Ansible-content voor herhaalbare configuratie op een machine die van begin tot eind van jou is