Building applications is fast. Deploying them into heavily regulated production environments is not.
Industry reports, such as the 2025 Stack Overflow Developer Survey, show that local environments like Windows Subsystem for Linux (WSL) and upstream community Linux distributions enable quick coding for Linux Developers. The initial development stage moves quickly on these accessible platforms.
However, moving from a local environment to a production cloud instance introduces significant infrastructure challenges. Security teams require secure operating system layers. Operations teams need a lifecycle management strategy. The application's value often gets obscured by the overhead of host operating system configuration.
The disconnect between code and cloud
The traditional approach to moving from code to cloud environments is disjointed. An application is developed inside a container, but if you're in a traditional Linux environment, operations run that container on a separate, traditional, RPM-based host operating system.
Managing containers requires one set of tools, and managing hosts requires another. This separation creates overhead, introduces deployment delays, and often causes code that runs perfectly during development to behave differently in the cloud.
Bridging the divide with a unified workflow
The fundamental power of image mode for Red Hat Enterprise Linux (RHEL) is not just technical, it's cultural. For years, development teams spoke the language of containers (Containerfile, Podman, registry) while operations teams spoke the language of hosts (Kickstart, RPMs, patching). This dual taxonomy is the root of the silo.
Image mode for RHEL, powered by bootc, unifies this practice. It replaces the complex, imperative process of host provisioning with a simple, declarative Containerfile. Everyone, from the local developer building their application to the cloud operations engineer deploying the server, uses the same toolset, the same artifacts, and the same mental model: The container is the operating system. This shared framework eliminates a major source of friction and allows teams to finally speak the same technical language, accelerating the entire pipeline.
Enter bootable containers
Image mode for RHEL fundamentally changes application delivery. RHEL can now be treated as a containerized application, simplifying the infrastructure.
Using standard bootc tooling, you can define an entire bootable operating system using a standard Containerfile. It is built using familiar container tools.
Instead of writing a complex Kickstart file to provision a server, the operating system is defined in a few lines of code:
# Start with a bootable RHEL base image
FROM registry.redhat.io/rhel9/rhel-bootc:latest
# Install your required system packages
RUN dnf -y install python3-pip python3-devel gcc && \
dnf clean all
# Copy your application code into the image
COPY ./my-ai-app /opt/app
WORKDIR /opt/app
# Install application-level dependencies
RUN pip3 install -r requirements.txt
# Copy your systemd unit file
COPY my-app.service /etc/systemd/system/
# Enable your application as a systemd service
RUN systemctl enable my-app.serviceThis operating system is built exactly like a standard application container:
$ podman build -t my-custom-rhel-os:latest .This delivers a unified, production-ready container containing the application, runtime dependencies, and a secure foundation, all in a single artifact. For a deeper dive into the mechanics of this workflow, I highly recommend reading How to build, deploy, and manage image mode for RHEL.
The systemd advantage: Declarative control of workloads
To understand why this approach works, consider systemd. In a standard container, the application itself is process ID (PID) 1. If the application fails, the container stops. Background worker processes require complex entrypoint scripts.
Bootable containers eliminate this limitation. When building with RHEL image mode, systemd acts as PID 1.
The container behaves like a full operating system. It provides native service dependency management, handles automatic service restarts, and provides unified logging through journald. You deploy the application exactly as a system administrator would deploy a service on bare metal, but entirely within a container build process.
Note: If you want to master running containerized workloads natively within systemd, check out our detailed guide on Containerizing workloads on image mode for RHEL, which covers Podman Quadlets in depth.
Managing subscriptions: Test vs. production
A practical technical challenge is subscription management. Building a RHEL image locally requires developer credentials, and transferring those credentials to a production registry poses a significant security risk.
The solution is decoupling build-time entitlements from runtime entitlements.
Local testing
For local development, use Podman Desktop with the Red Hat Account Extension. Running podman build automatically and securely mounts no-cost developer credentials into the build environment. The dnf install command pulls packages from protected RHEL repositories. These credentials exist only during the build. When the final my-custom-rhel-os:latest image is saved, it is clean, containing compiled applications and RHEL binaries, but zero subscription keys.
Crucially, these keys are only mounted during the build. When the final my-custom-rhel-os:latest image is saved, it is entirely clean. It contains your compiled application and RHEL binaries, but zero subscription keys.
Test this yourself by following our Learning Path for Podman Desktop.
Production runtime
Push this unsubscribed image to a production registry. Image mode systems can easily be registered using the standard insights or subscription-manager tools just like with package mode. All of the same methods are available including manual registration, activation keys using kickstart or cloud-init or standard fleet management tools like Red Hat Satellite are available to users. The secure base image remains clean and fully portable and deployed systems will be fully registered.
Simplify the pipeline
The journey from a local laptop to a production cloud instance should be a seamless, single pipeline. All components are infrastructure agnostic making this adaptable to virtually all environments. To help jumpstart pipelines, take a look at this Git repo. We provide templates for GitHub Actions, GitLab CI, Tekton, Ansible Automation Platform, and Jenkins.
Standardizing on RHEL image mode integrates enterprise security earlier, into the local development phase. You push bootable containers to a standard registry, and the cloud provider boots them directly.
Infrastructure becomes just another container artifact. This allows the enterprise architect to focus on modernization and application velocity, rather than host management complexity.
Try it now
You do not have to download anything to try this out. You can test this entire code-to-cloud process right now, directly in your browser:
- First, join the Red Hat Developer Program at developers.redhat.com, which gives you access to labs, no-cost subscriptions to RHEL for business and personal use, cheat sheets, sandboxes, and ebooks.
- Next, jump directly into an Interactive Lab for RHEL Image Mode.
- Try out our GitHub repo of examples to help you start introducing image mode for RHEL into your CICD pipelines. In the lab, you get hands-on experience building, deploying, and managing a bootable container. It takes less than 20 minutes to see exactly how systemd and bootc turn a standard Containerfile into a production-ready operating system.
Stop managing servers. Start building bootable containers today.
