A rootless Quadlet path for .NET 10 services on RHEL for IBM Power

IBM has published a concrete path for running a .NET 10 ASP.NET Core service on Red Hat Enterprise Linux for IBM Power without writing a Dockerfile or operating the container as root. The pattern uses the .NET SDK to build an OCI image, Podman to run it and a Quadlet file to generate a user-level systemd service.

The useful part for platform teams is not the sample endpoint. It is the handoff between application packaging and host operations: the application reports readiness through Microsoft.Extensions.Hosting.Systemd, while systemd owns startup, restart and journal collection.

Check the Power and RHEL baseline first

IBM’s tested prerequisites are specific: RHEL 9.7 or later or RHEL 10.1 or later on ppc64le, a valid RHEL subscription, Podman 4.4 or later, cgroup v2, access to registry.access.redhat.com and NuGet, and an available host port for the service. The walkthrough installs dotnet-sdk-10.0 and Podman from RHEL repositories and tells operators to verify both the machine architecture and Podman’s reported cgroup version before proceeding.

The project pins Microsoft.Extensions.Hosting.Systemd 10.0.10 and selects Red Hat’s .NET 10 ASP.NET base image. dotnet publish /t:PublishContainer then creates localhost/systemd-demo-service:latest for the rhel.9-ppc64le runtime identifier. That local tag is convenient for the demonstration, but a production pipeline should replace latest with an immutable version or digest and decide how images are promoted to each Power host.

Put the service in the user systemd boundary

For rootless operation, the Quadlet file lives under ~/.config/containers/systemd/. Its container section maps port 8080, sets the ASP.NET listener and enables Notify=true; its service section uses Restart=always, a five-second restart delay and a 900-second startup timeout. Reloading the user systemd manager generates and starts the corresponding .service unit.

The boot boundary matters. A rootless user service normally starts only after that user logs in. IBM therefore enables systemd lingering with loginctl, allowing the user manager and service to start during boot without an interactive session. That is an administrative policy choice: platform teams should create a dedicated service account, control who may enable lingering and manage the unit through that identity rather than a developer’s personal account.

Treat persistence and resilience separately

The sample persists the Quadlet definition and retains logs in the user journal, but it declares no Podman volume. Any application state written only inside the container is therefore outside the demonstrated persistence model. Stateful services need explicit host or named-volume mounts, ownership and SELinux-label decisions, plus backup and restore procedures.

The restart test proves host-local process recovery: killing the container causes systemd to recreate it. It does not provide node failover, replica management, rolling deployment or traffic health routing. The /health endpoint is checked manually; the supplied unit does not use it to decide whether a running but unhealthy process should restart. For a single RHEL-on-Power host, that may be an intentionally small operational footprint. For a shared platform or higher availability target, the same image should move behind a registry and an orchestrated deployment model with declared storage, probes and rollout policy.