The best way to develop a Red Hat Enterprise Linux (RHEL) application is from within a Red Hat environment, which you can easily obtain at no cost for software development as an individual or business developer. In theory of course, you can create cross-platform (“write once, run anywhere”) applications on a non-target operating environment. For example, you could build a Python application on Windows and just expect it to work on RHEL because you’re using the same version of Python, but inevitably it leads to “write once, …
The best way to develop a Red Hat Enterprise Linux (RHEL) application is from within a Red Hat environment, which you can easily obtain at no cost for software development as an individual or business developer. In theory of course, you can create cross-platform (“write once, run anywhere”) applications on a non-target operating environment. For example, you could build a Python application on Windows and just expect it to work on RHEL because you’re using the same version of Python, but inevitably it leads to “write once, test everywhere”. But with modern development platforms, this doesn’t mean you have to learn a new desktop environment just to target RHEL as your enterprise application platform.
Two of the most common desktop environments for Linux developers are Microsoft Windows and Linux itself. If you’re using a major Linux distribution or Windows, you can run RHEL in that environment easily by leveraging container technologies. The key to success in either ecosystem is the technology used to create the RHEL environment. On modern Linux, this is Toolbx, a command-line utility built on Podman containers. On Windows, it’s the Windows Subsystem for Linux (WSL). Each of these technologies presents a powerful approach to solving the same problem, and both use container technology.
The Linux Toolbx approach: A native Linux workflow
Toolbx is a utility that creates a containerized command-line environment that’s deeply integrated with the Linux host. Its goal is to create an interactive space that feels native. It is currently supported on both RHEL and Fedora, as well as Arch Linux and Ubuntu. The usage model is simple: Open a terminal and run the environment you want.
Do you want to run RHEL 10, but you’re developing applications for RHEL 8 or RHEL 9? Or maybe you want to develop RHEL apps on Fedora or Ubuntu? This is exactly what Toolbx makes possible.
To create a RHEL 10 environment (called rhel10-dev, in this example), you use the toolbox command:
toolbox create --image registry.redhat.io/ubi10/ubi rhel10-dev
Enter your new rhel10-dev toolbox:
toolbox enter rhel10-dev
Upon entering the shell where the underlying operating system (OS) is RHEL 10, your home directory, user identity, and network settings are all shared.
Two key advantages to the Toolbx approach are:
- Automatic handling of Podman flags for mounting volumes and sharing system resources, resulting in a container that acts like an extension of your host system. This means you can run native Linux tools in the graphical environment of your choice even if that environment isn’t supported natively for RHEL. For example, if you’re running the Plasma Desktop, you can edit files with KDevelop and compile natively in your RHEL-based toolbox. Alternatively, Builder (the integrated development environment for GNOME) is specifically designed to build, run, and test applications against the development tools and software development kits installed inside a specified Toolbx container.
- Toolbx also improves runtime compatibility. Suppose you’re running a RHEL user space on a Linux host, as in the example above. System calls and file system interactions and even SELinux policies (where applicable) are much more likely to behave as they would in production, minimizing the chance of “write-once, test everywhere” issues.
The WSL approach: Bridging two worlds
WSL2 runs a fully open source Linux kernel, maintained by Microsoft, in a lightweight, virtual machine inside Windows. It allows you to install and run a complete Linux distribution, including RHEL (available from developers.redhat.com) and provides a robust environment for developers who must work on a Windows desktop.
When using RHEL for WSL, the workflow is similar to Toolbx. When you launch WSL, you are dropped into a full-featured terminal and Bash shell. Some key features of RHEL for WSL include:
- A best of both worlds experience. For example, edit your source files with VS Code and then compile that code using the Remote - WSL extension, making the boundary between the two operating systems nearly invisible in your development environment.
- Microsoft Windows is a corporate standard on the desktop in many large enterprises. WSL is Microsoft’s official, supported solution for enabling Linux development on their platform, making it the path of least resistance for many developers.
Toolbx and WSL compared
The following table compares the two approaches to developing in a RHEL environment:
| Feature | RHEL on Linux with Toolbx | RHEL on Windows with WSL |
|---|---|---|
| Fidelity to RHEL | Extremely High. It’s a RHEL-derived container running on a Linux host, with a more modern kernel for compatible system call and file system behavior. | High. It’s a real Linux kernel, but subtle differences in networking and cross-OS file system mounts can introduce edge cases. |
| Performance | Near-native across the board. The container adds minimal overhead, and all file I/O is native to the Linux file system. | Excellent for CPU tasks. File I/O across the Windows/Linux boundary (/mnt/c) can be a bottleneck compared to native Linux. |
| Workflow | A purely Linux-native experience. Best for developers who live in a Linux-centric toolchain. Toolbx containers are easily managed through Podman Desktop if a graphical container management experience is preferred. | A hybrid experience. Supports workflows that require mixing Windows-native apps with Linux tools. |
| Simplicity | Built-in and simple. The commands are minimal, and the integration is automatic, requiring almost no setup. | Easy to add on. Requires enabling a Windows feature and installing a distro, but the process is well-documented and simple. |
Choose the tooling and environment that makes the most sense
Both Toolbx and WSL solve the local RHEL development problem effectively. The best choice depends on the preferred desktop ecosystem and corporate constraints. Bottom line:
- Choose to develop RHEL applications with Linux and Toolbx if you want a pure, top-to-bottom Linux experience. If your workflow is centered around Linux tools, and you prioritize the highest possible fidelity in your production RHEL environment with the least overhead this is the way to go.
- Develop your RHEL applications on WSL if your work requires you to use both Windows and Linux applications. WSL is the clear winner if your company mandates a Windows desktop, because it provides a powerful and deeply integrated Linux environment without needing a separate machine or a full VM.
As someone who values a fully native Linux stack, my own personal workstation is Fedora running a RHEL toolbox. For me, that simplicity and direct alignment are unbeatable. However, the power of WSL is undeniable, and for Linux developers who run Windows, it’s an absolutely essential tool for modern enterprise development.
Toolbx does come with a complete manual that covers each command and the configuration file. The Toolbx website also provides a rich assortment of interesting information that’s worth going through for both newcomers and seasoned practitioners alike. If you’re looking to run Toolbx native on RHEL to target builds of older distributions, or even to build apps for other distributions, check out this article, which introduces official support for Toolbx on RHEL.
To learn more about RHEL for WSL, read Getting started with RHEL on WSL for more detail. There’s also a cheat sheet that lists common commands that can help you get started working in a RHEL for WSL environment.