DEV Community: Ana Villar

Building a Kubernetes Cluster on Red Hat Enterprise Linux 10: A kubeadm Guide

Ana Villar — Thu, 18 Jun 2026 18:22:11 +0000

Introduction

In this post, I'll walk you through deploying a production-ready Kubernetes cluster on Red Hat Enterprise Linux 10 using kubeadm. This lab was inspired by Anthony E. Nocentino's excellent Certified Kubernetes Administrator (CKA): Using kubadm to Install a Basic Cluster training course, which is part of the official Certified Kubernetes Administrator (CKA) path on Pluralsight.

⭐ Shout-out: Anthony is a fantastic trainer! His course uses Ubuntu 22.04 as the base OS. I adapted his approach to work on RHEL 10, adding some additional considerations specific to Red Hat's ecosystem.

One intentional decision in this setup: I deployed Kubernetes v1.35 and CRI-O v1.35, which wasn't the latest version available at installation time.

This was purposeful. Anthony's course includes a dedicated section on upgrading clusters, and using a slightly older baseline makes that learning path clearer.

The upgrade procedures (not covered here) are what really solidify your understanding of cluster lifecycle management.

Lab Infrastructure Overview

Nodes Configuration

Node	Role	RAM	vCPUs	IP Address
rh-cp1	Control Plane	12 GiB	2	192.168.110.120
rh-node1	Worker	6 GiB	2	192.168.110.121
rh-node2	Worker	6 GiB	2	192.168.110.122
rh-node3	Worker	6 GiB	2	192.168.110.123

Note: The IP address schema is just an example and what was more convenient for me.

Supporting Infrastructure

A dedicated utilities VM (also RHEL 10) provides essential services:

DNS (BIND/named)
NTP (chrony)
HTTP (Apache/httpd)
DHCP (Kea)

This centralized infrastructure simplifies name resolution across all cluster nodes. But this is not essential for this project. You can, instead, ensure the nodes are able to reach each other updating the file /etc/hosts on all nodes.

Prerequisites & OS Preparation

Before diving into Kubernetes, we need consistent node preparation across all machines.

1. System Registration and Updates

$ sudo subscription-manager register --username <username> --password <password>
$ sudo dnf update redhat-release
$ sudo dnf upgrade
$ sudo reboot

2. Disable Swap (Required by Kubernetes)

Edit /etc/fstab to comment out swap entries:

UUID=xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxxx none swap defaults 0 0
# ^ Comment this line out

Verify:

$ sudo swapoff -a
$ free

3. Disable Firewalld

Disable firewalld, as indicated in the Calico System requirements for Kubernetes:

$ sudo systemctl stop firewalld
$ sudo systemctl disable firewalld
$ sudo systemctl mask firewalld

⚠️ Production Note: Use Calico to maintaining security and enforce network policies later.

4. Load Kernel Modules and Enable IP Forwarding

$ cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

$ sudo modprobe overlay
$ sudo modprobe br_netfilter

Configure sysctl parameters:

$ cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

$ sudo sysctl --system

Verify the modules loaded correctly:

$ lsmod | grep overlay
$ lsmod | grep br_netfilter

Installing Kubernetes Components

Setting Version Variables

$ KUBERNETES_VERSION=v1.35
$ CRIO_VERSION=v1.35

Adding Repositories

Create the Kubernetes repo:

$ cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/rpm/repodata/repomd.xml.key
EOF

Create the CRI-O repo:

$ cat <<EOF | sudo tee /etc/yum.repos.d/cri-o.repo
[cri-o]
name=CRI-O
baseurl=https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/rpm/
enabled=1
gpgcheck=1
gpgkey=https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/rpm/repodata/repomd.xml.key
EOF

Installing Packages

$ sudo dnf install -y kubelet kubeadm kubectl cri-o container-selinux

Configuring CRI-O

Create a cgroup manager configuration file:

$ cat <<EOF | sudo tee /etc/crio/crio.conf.d/02-cgroup-manager.conf
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
EOF

Enable and start services:

$ sudo systemctl enable --now crio kubelet
$ sudo systemctl restart crio

Version Locking

To prevent accidental upgrades:

$ sudo dnf install 'dnf-command(versionlock)'
$ sudo dnf versionlock add kubeadm-1.35.4 kubelet-1.35.4 kubectl-1.35.4 cri-o-1.35.2

Note: Review the output from the installation of the packages kubeadm, kubelet, kubectl and cri-o, and update the versions to lock in the command above.

Initializing the Control Plane

On rh-cp1, download and configure Calico networking. To know the current lastest version, check Tigera documentation, in the Manifest tab:

$ wget https://raw.githubusercontent.com/projectcalico/calico/v3.32.0/manifests/calico.yaml

Edit the CALICO_IPV4POOL_CIDR value to match your pod network plan:

- name: CALICO_IPV4POOL_CIDR
  value: "10.244.0.0/16"

Initialize the cluster, to use the same subnet:

$ sudo kubeadm init \
  --kubernetes-version v1.35.4 \
  --pod-network-cidr=10.244.0.0/16 \
  --cri-socket unix:///var/run/crio/crio.sock \
  --upload-certs

Once successful, save the join commands that appear at the end of the output—you'll need these for worker nodes!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.110.120:6443 --token xxxxxx.xxxxxxxxxxxxxxxx \
 --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  
$

Your Kubernetes control-plane has initialized successfully!

Configuring kubectl

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

Deploy Calico Network

$ kubectl apply -f calico.yaml

Wait a few minutes and verify pods are running:

$ kubectl get pods --all-namespaces
$ kubectl get nodes

Expected output:

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-6b4b6457d5-p98c2   1/1     Running   0          2m47s
kube-system   calico-node-5vjrr                          1/1     Running   0          2m47s
kube-system   coredns-7d764666f9-r4vqp                   1/1     Running   0          4m9s
kube-system   coredns-7d764666f9-vh7df                   1/1     Running   0          4m9s
kube-system   etcd-rh-cp1                                1/1     Running   0          4m28s
kube-system   kube-apiserver-rh-cp1                      1/1     Running   0          4m28s
kube-system   kube-controller-manager-rh-cp1             1/1     Running   0          4m27s
kube-system   kube-proxy-4r6h8                           1/1     Running   0          4m10s
kube-system   kube-scheduler-rh-cp1                      1/1     Running   0          4m28s
$ kubectl get nodes
NAME     STATUS   ROLES           AGE     VERSION
rh-cp1   Ready    control-plane   4m40s   v1.35.4
$

Joining Worker Nodes

On each worker node (rh-node1, rh-node2, rh-node3), run the join command saved during kubeadm init:

$ sudo kubeadm join 192.168.110.120:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

Verify the cluster health from the control plane:

$ kubectl get nodes

All nodes should show Ready status.

$ kubectl get nodes
NAME       STATUS   ROLES           AGE     VERSION
rh-cp1     Ready    control-plane   10m     v1.35.4
rh-node1   Ready    <none>          2m11s   v1.35.4
rh-node2   Ready    <none>          113s    v1.35.4
rh-node3   Ready    <none>          102s    v1.35.4
$

Install bash completion for kubectl:

$ sudo dnf install bash-completion
$ echo "source <(kubectl completion bash)" >> ~/.bashrc
$ source ~/.bashrc

Testing the Deployment

Deploy a test application:

$ kubectl create deployment hello-world --image=psk8s.azurecr.io/hello-app:1.0
$ kubectl get pods -o wide

Expose it via a service:

$ kubectl expose deployment hello-world --port=80 --target-port=8080
$ kubectl get service hello-world

For example:

$ kubectl get service hello-world
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
hello-world   ClusterIP   10.99.168.218   <none>        80/TCP    8s
$

Then, test it. You should see a response from your running container!

$ curl http://10.99.168.218:80
Hello, world!
Version: 1.0.0
hello-world-b5b7f67cc-d26dt
$

Clean up after testing:

$ kubectl delete service hello-world
$ kubectl delete deployment hello-world

Key Considerations When Moving from Ubuntu to RHEL

Here are the main differences I encountered adapting Anthony's tutorial:

Aspect	Ubuntu Approach	RHEL 10 Adaptation
Package Manager	apt/dpkg	dnf/rpm
Firewall Management	ufw/firewalld optional	firewalld disabled (use Calico policies)
Subscription	N/A	subscription-manager required
SELinux	Permissive mode default	Need to handle SELinux context
CRI Runtime	containerd	CRI-O

What's Next?

This setup provides a solid foundation for learning Kubernetes administration. From here, you could explore:

Cluster upgrades (covered extensively in Anthony's course)
Network policy enforcement with Calico
High availability with multiple control plane nodes
Storage classes and persistent volumes
Monitoring stack with Prometheus/Grafana

If you found this walkthrough helpful, I'd highly recommend checking out the original Pluralsight course. Anthony's explanations are crystal clear, and adapting them to different distributions is an excellent way to deepen your understanding of what happens under the hood.

Resources

Pluralsight: Certified Kubernetes Administrator Certification Path
Official Kubernetes Documentation
Calico Project GitHub

Thanks for reading! Feel free to share your own experiences with Kubernetes on RHEL in the comments below.

Complete Guide: Setting Up XWiki 17 on Premises

Ana Villar — Fri, 12 Jun 2026 19:04:27 +0000

This guide walks through deploying XWiki 17.10.8 on Red Hat Enterprise Linux 10.2 with Apache Tomcat and PostgreSQL. Total setup time: ~45 minutes. Requires minimum 8GB RAM and 4 vCPUs for acceptable performance.

If you're looking to deploy a self-hosted wiki solution with enterprise-grade features, XWiki is an excellent choice. Unlike some alternatives, it offers powerful permission management, structured data, and extensibility through extensions. However, the on-premises setup can be intimidating due to multiple moving parts.

This guide details setting up XWiki 17 on Red Hat Linux Server 10.2 with 16GB RAM and 4 vCPUs. I initially validated these steps in a Mac-hosted VM before deploying them to my production environment on a Dell OptiPlex 7050 Micro.

What You'll Need

Hardware Requirements

Resource	Minimum	Recommended
CPU	2 cores	4+ cores
RAM	4 GB	16 GB
Storage	20 GB	100 GB

Note: During my initial setup on a 2GB RAM old laptop, XWiki was functional but painfully slow. The jump to 16GB made a night-and-day difference in responsiveness.

Software Stack

Operating System: Red Hat Enterprise Linux 10.2 or Fedora Server
Servlet Container: Apache Tomcat 10.1.x (Jetty is also supported)
Database: PostgreSQL 16.x
Java: OpenJDK 21
XWiki Platform: 17.10.8 WAR package

Comments:

As Operating System, you can use other Linux Distributions, including Ubuntu, Windows Server and Docker Engine.
As Servlet Container, Jetty is also a supported option.
Other supported databases are HyperSQL, MariaDB, MySQL, or Oracle.
For more information, review XWiki prerequisites.

Time Investment

Installation: ~30 minutes
Configuration: ~15 minutes
Testing: ~10 minutes

Preparation Steps

Install Your Base OS

For this guide, I'm using Red Hat Enterprise Linux, but most steps work equally well on Fedora Server if you don't have RHEL subscriptions.

Download from Red Hat Developer Program or Fedora Server.

Once installed, register (if using RHEL), update, and reboot:

~$ sudo subscription-manager register --username <username> --password <password>
~$ sudo dnf upgrade -y
~$ reboot

Installing Dependencies

Install and configure Apache Tomcat

Tomcat serves as our servlet container for hosting XWiki:

~$ sudo dnf install tomcat -y

This command pulls in Java 21 along with necessary dependencies automatically. Review the installation output to confirm java-21-openjdk-headless was included.

Architecture Note:
Package names vary by architecture:

x86_64: java-21-openjdk-headless.x86_64
aarch64: java-21-openjdk-headless.aarch64

If it seems to be missing:

~$ sudo dnf install java-21-openjdk-headless.x86_64 -y

~$ sudo dnf install java-21-openjdk-headless.aarch64 -y

Configure Firewall

Allow HTTP traffic on port 8080 (Tomcat's default):

~$ sudo firewall-cmd --permanent --add-port=8080/tcp
~$ sudo firewall-cmd --reload

Verify it's open:

~$ sudo firewall-cmd --list-all

Configure Tomcat Memory Settings

By default, Tomcat won't allocate enough memory for XWiki to perform well. Create a custom setenv.sh file:

~$ sudo mkdir -p /var/lib/tomcat/bin
~$ sudo chown tomcat:tomcat -R /var/lib/tomcat
~$ sudo nano /var/lib/tomcat/bin/setenv.sh

Add this configuration:

#!/bin/sh
export JAVA_OPTS="${JAVA_OPTS} -Djava.awt.headless=true"
export CATALINA_OPTS="-server -Xms1080m -Xmx1600m -Dfile.encoding=utf-8 \
-Djava.awt.headless=true \
--add-opens java.base/java.lang=ALL-UNNAMED \
--add-opens java.base/java.io=ALL-UNNAMED \
--add-opens java.base/java.util=ALL-UNNAMED \
--add-opens java.base/java.util.concurrent=ALL-UNNAMED"

Memory Explanation:

Setting	Value	Purpose
-Xms	1080MB	Initial heap size (prevents startup allocation spikes)
-Xmx	1600MB	Maximum heap size (prevents runaway memory consumption)
--add-opens	N/A	Required for Java 17+ compatibility with certain libraries

Set ownership and test:

~$ sudo chown tomcat:tomcat /var/lib/tomcat/bin/setenv.sh
~$ sudo systemctl enable --now tomcat
~$ sudo systemctl status tomcat

Test from another machine by visiting http://your-server-name:8080. You should see the Tomcat welcome page. Once confirmed, stop the service — we'll restart after XWiki deployment:

~$ sudo systemctl stop tomcat

Database Configuration (PostgreSQL)

Install PostgreSQL

~$ sudo dnf install postgresql-server postgresql-contrib -y

Initialize and Start PostgreSQL

~$ sudo postgresql-setup --initdb
~$ sudo systemctl enable --now postgresql
~$ sudo systemctl status postgresql

Create XWiki User and Database

Switch to the postgres user:

~$ sudo su postgres
bash-5.2$ psql

Then run these SQL commands:

CREATE USER xwiki PASSWORD 'xwikipassword';
CREATE DATABASE xwiki WITH OWNER=xwiki;
GRANT ALL ON SCHEMA public TO xwiki;
\q

⚠️ Security Warning: Replace 'xwikipassword' with a strong, unique password. Never use default credentials in production. Consider using environment variables or secret management tools like HashiCorp Vault for sensitive data.

Configure PostgreSQL Authentication

Find the authentication config file:

~$ sudo su postgres
bash-5.2$ psql -c "SHOW hba_file;"

By default, the file and location is /var/lib/pgsql/data/pg_hba.conf

Edit the pg_hba.conf file to change authentication method:

~$ sudo nano /var/lib/pgsql/data/pg_hba.conf

Replace these lines:

# OLD (insecure)
host    all             all             127.0.0.1/32            ident
host    all             all             ::1/128                 ident

# NEW (secure)
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256

Reload PostgreSQL to apply changes:

~$ sudo systemctl reload postgresql

Verify Database Connection:

~$ psql postgresql://xwiki:xwikipassword@localhost
xwiki=> \l  # Should list databases including 'xwiki'
xwiki=> \q  # Exit psql
~$

Deploying XWiki

Download Required Files

Get these two files from official sources:

XWiki WAR Package: Production Installation → Select "WAR Package for Servlet Container"
PostgreSQL JDBC Driver: Official Downloads

Place them in a download directory:

~$ mkdir ~/downloads
~$ cd ~/downloads
# wget the links here from browser or CLI
~$ ls downloads/
postgresql-42.7.11.jar  xwiki-platform-distribution-war-17.10.8.jar
~$

Deploy the WAR Package

Copy and extract the XWiki WAR:

~$ sudo cp ~/downloads/xwiki-platform-distribution-war-17.10.8.jar /var/lib/tomcat/webapps/
~$ cd /var/lib/tomcat/webapps
~$ sudo unzip xwiki-platform-distribution-war-17.10.8.jar
~$ sudo mkdir xwiki
~$ sudo mv META-INF redirect resources skins templates WEB-INF xwiki/
~$ sudo rm xwiki-platform-distribution-war-17.10.8.jar
~$ sudo chown -R tomcat:tomcat xwiki/

Common Pitfall: If you get an error about moving files into themselves, ensure you're not inside the extracted directory when creating the target folder.

Add PostgreSQL JDBC Driver

~$ cd /var/lib/tomcat/webapps/xwiki/WEB-INF/lib
~$ sudo cp ~/downloads/postgresql-42.7.11.jar .
~$ sudo chown tomcat:tomcat *.jar

Configure Hibernate for PostgreSQL

Edit the Hibernate configuration:

~$ cd /var/lib/tomcat/webapps/xwiki/WEB-INF
~$ sudo nano hibernate.cfg.xml

Find and comment out the default database section:

    <!--
    <property name="hibernate.connection.url">jdbc:hsqldb:file:${environment.permanentDirectory}/database/xwiki_db;shutdown=true</property>
    <property name="hibernate.connection.username">sa</property>
    <property name="hibernate.connection.password"></property>
    <property name="hibernate.connection.driver_class">org.hsqldb.jdbcDriver</property>
    -->

Find and uncomment the PostgreSQL section:

    <!-- PostgreSQL configuration.
         Uncomment if you want to use PostgreSQL and comment out other database configurations.
         Notes:
           - "hibernate.jdbc.use_streams_for_binary" needs to be set to "false",
             see https://community.jboss.org/wiki/HibernateCoreMigrationGuide36
           - "xwiki.virtual_mode" can be set to either "schema" or "database". Note that currently the database mode
             doesn't support database creation (see https://jira.xwiki.org/browse/XWIKI-8753)
           - if you want the main wiki database to be different than "xwiki" (or "public" in schema mode)
             you will also have to set the property xwiki.db in xwiki.cfg file
    -->

    <property name="hibernate.connection.url">jdbc:postgresql://localhost:5432/xwiki</property>
    <property name="hibernate.connection.username">xwiki</property>
    <property name="hibernate.connection.password">**xwikipassword**</property>
    <property name="hibernate.connection.driver_class">org.postgresql.Driver</property>
    <property name="hibernate.jdbc.use_streams_for_binary">false</property>
    <property name="xwiki.virtual_mode">schema</property>

    <property name="hibernate.connection.charSet">UTF-8</property>
    <property name="hibernate.connection.useUnicode">true</property>
    <property name="hibernate.connection.characterEncoding">utf8</property>

    <mapping resource="xwiki.postgresql.hbm.xml"/>
    <mapping resource="feeds.hbm.xml"/>
    <mapping resource="instance.hbm.xml"/>
    <mapping resource="notification-filter-preferences.hbm.xml"/>
    <mapping resource="mailsender.hbm.xml"/>


    <!-- Oracle configuration.
...

⚠️ Password Reminder: Update the password value to match what you set earlier!

Configure Permanent Directory

Create a dedicated directory for XWiki data:

~$ sudo mkdir -p /var/lib/xwiki/data
~$ sudo chown -R tomcat:tomcat /var/lib/xwiki

Edit the properties file:

~$ nano /var/lib/tomcat/webapps/xwiki/WEB-INF/xwiki.properties

Uncomment and verify this line:

environment.permanentDirectory = /var/lib/xwiki/data/

Starting the Application

~$ sudo systemctl start tomcat

Wait 3-5 minutes for Tomcat to fully initialize XWiki (it compiles resources on first boot). Monitor logs:

~$ sudo tail -f /var/log/tomcat/catalina.out

Look for messages like XWiki context has been initialized successfully.

XWiki Configuration Wizard

Running the Configuration Wizard

Navigate to your server: http://your-server-name:8080/xwiki.

You'll see an initialization banner briefly, then the wizard will appear.

Wizard Steps

Press Continue to begin

Create Administrator Account: Set a strong admin password (save this securely!).

Press Register and Login.

Press Continue

Install Standard Flavor: Select "XWiki Standard Flavor" from the dropdown—this includes useful built-in applications

Press Install this flavor: Wait 2-5 minutes depending on hardware

Press Install

Once you see it has been Installed, Press Continue to completion.

After finalization, press Continue and you'll be redirected to your XWiki home page with example documentation.

Your XWiki server is ready!

Post-Installation Checklist

Security Hardening

Action	Priority	Command/File
Change default PostgreSQL password	High	psql ALTER USER command
Update Tomcat manager passwords	High	tomcat-users.xml
Enable HTTPS via reverse proxy	High	nginx/Apache configuration
Restrict database access	Medium	pg_hba.conf network rules
Regular backups	High	XWiki GUI + cron jobs + pg_dump

Performance Tuning

With 16GB RAM, you may want to increase XWiki's maximum heap:

# Edit setenv.sh
CATALINA_OPTS="-Xmx2048m ..."  # Increase if needed

Enable query caching in xwiki.properties:

cache.default.maxSize = 5000

Backup Strategy

Using XWiki GUI

Go to Administer Wiki:

Select Content:

And select Export:

You can select what pages to export/backup.

Database:

pg_dump -U xwiki xwiki > xwiki_backup_$(date +%Y%m%d).sql

File Data:

tar czf xwiki_files_$(date +%Y%m%d).tar.gz /var/lib/xwiki/data/

Schedule these as cron jobs for automated backups.

Troubleshooting Common Issues

Issue: XWiki Won't Load After Startup

Symptoms: Browser shows blank page or timeout at /xwiki

Solutions:

Check logs: tail -f /var/log/tomcat/catalina.out
Verify database connection is active
Ensure hibernate.cfg.xml has correct credentials
Restart Tomcat completely

Issue: Slow Page Loading

Symptoms: Pages take 5+ seconds to load

Solutions:

Increase JVM heap in setenv.sh
Check available RAM with free -h
Disable unnecessary extensions in XWiki admin panel
Consider upgrading to SSD storage

Issue: Database Connection Error

Symptoms: "Cannot connect to database" during wizard

Solutions:

Verify PostgreSQL is running: sudo systemctl status postgresql
Test connectivity: psql -U xwiki -d xwiki
Check pg_hba.conf has scram-sha-256 authentication
Ensure firewall allows localhost PostgreSQL connections (port 5432)

Why On-Premises Over Cloud?

You might wonder why choose self-hosted instead of XWiki Cloud. Here are compelling reasons:

Factor	On-Premises	Cloud
Data Control	Full	Limited by provider
Customization	Unlimited	Restricted
Cost (Long-term)	Lower	Subscription-based
Offline Access	Yes	Requires internet
Integration	Direct system access	API-only

For organizations handling sensitive data or requiring deep integration, on-premises deployment provides the flexibility you need.

Final Thoughts

Setting up XWiki on-premises involves coordinating several components, but once configured, you have a powerful, self-contained knowledge management platform. The setup I've outlined balances security, performance, and maintainability.

Got questions or encountered different errors? Drop a comment below — I'm happy to help troubleshoot!

Further Resources

Hello, DEV Community! 👋

Ana Villar — Sat, 30 May 2026 15:53:23 +0000

I'm Ana, and I'm excited to start sharing my technical journey here. This is a brief post to introduce myself and give you a heads-up on what's coming.

What to Expect

In upcoming posts, I'll be diving into hands-on, infrastructure-focused tutorials and walkthroughs, including:

Setting up a XWiki server on-premises — from installation to configuration, getting a collaborative wiki platform running in your own environment.
Deploying Kubernetes on RHEL 10 virtual machines — step-by-step guidance on building a Kubernetes cluster on Red Hat Enterprise Linux 10.
Deploying OpenShift as virtual machines on a RHEL 10 host — exploring how to run OpenShift on top of RHEL 10, combining the power of containers with VM-level control.

My goal is to keep things practical, clear, and rooted in real-world experience — the kind of content I wish I'd had when tackling these setups myself.

Why These Topics?

Because on-premises infrastructure is far from dead. Whether it's compliance requirements, performance needs, or simply wanting full control over your stack, there's still a strong case for running things yourself. And RHEL was my choice for certification purposes, and it's given me the flexibility to keep using hardware that other vendors have discontinued.

Stay tuned, and feel free to follow me so you don't miss the upcoming posts. If any of these topics spark your interest, I'd love to hear about it in the comments! 🚀