Containerize .NET applications
around IBM i

Q: Is containerization suitable for existing IBM i business applications, or only for new .NET projects?

Both approaches are possible. Existing business applications remain on IBM i and can be progressively exposed via containerized .NET services, while preserving RPG and CLP programs or legacy S/36 applications. New projects can, on the other hand, be developed directly in .NET, with application logic independent of IBM i.

Q: How are configuration and sensitive information handled in a containerized .NET application and connected to IBM i?

Configuration and sensitive information are handled at the application level, through standard .NET and container mechanisms such as environment variables or configuration files. No IBM i-side configuration is required.

Q: Can multiple containerized .NET applications run alongside the same IBM i system?

Yes. Each application runs in its own container, with its own lifecycle and resources. This approach makes it possible to run multiple workloads around the same IBM i without creating cross-application dependencies.

Q: Is .NET containerization around IBM i compatible with strict security and compliance requirements?

Yes. IBM i remains isolated, not exposed, and retains all of its native security mechanisms. The .NET applications run in an environment where security is enforced by the hosting infrastructure, without modifying or bypassing IBM i security rules.

Q: Can a .NET application that uses ODBC or OLE DB to access IBM i be containerized?

Technically, yes, but with significant constraints. ODBC and OLE DB providers rely on drivers that are dependent on the operating system and hardware architecture. In a modern, containerized .NET environment, this significantly complicates portability, maintenance, and multi-environment deployments. NTi relies exclusively on the .NET runtime (CLR) to access IBM i. The application remains 100 % .NET and runs in its own containerized environment, while natively and directly accessing IBM i resources. The same application code is used, with container images built for each target platform (Windows, Linux, ARM, Power, etc.).

Keep IBM i as the system of record
With NTi, deploy containerized .NET applications that are portable, reproducible and runnable across all infrastructures.

IBM i preserved, never exposed
Predictable application behavior
Risk-free evolution

Try NTi for free

View documentation

What is a container ?

A container packages your application with everything it needs to run. It provides an isolated, standardized environment independent of the host system.

Virtual machine

Your application

Full operating system

Hypervisor

Includes a complete OS, often often gigabytes of overhead for a small application.

Container

Your application

Dependencies only Runtime, libraries, configuration…

Contains only your code and its dependencies

Portable Reproducible Lightweight

By embedding the runtime and dependencies with the application, the container eliminates differences between environments. What works in development works identically in test and production.

.NET Cloud Ready

A platform designed to build, deploy and run applications across different environments.

Cross-platform runtime

.NET runs on Windows, Linux and macOS, as well as on x86, ARM and Power architectures. The same application can run across different environments without modification.

Self-contained application

Everything the application needs is included in the image: .NET runtime, libraries, configuration. The host runtime simply starts the container, with no prior installation.

Official container images

Microsoft provides maintained and supported base images. They allow you to build and run containerized .NET applications without worrying about the underlying environment.

Standardized deployment

A .NET application is built once, then deployed identically across each environment: development, test and production.

Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/runtime:8.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Containerization .NET / IBM i

With NTi, the .NET application communicates with IBM i regardless of the target architecture, allowing .NET workloads to run independently of the hosting environment.

DB2 for i access

Query and update DB2 for i directly from standard .NET code.

RPG / CL

Execute CL commands and call RPG programs from a containerized .NET application.

No IBM i installation

All IBM i access management is handled on the application side by NTi. No dependency on the runtime platform, no component to install on IBM i.

A single IBM i access layer, regardless of the environment

Linux Containerized .NET application

ARM Containerized .NET application

Power Containerized .NET application

Cloud deployment No architectural constraints

IBM i Central system

Single multi-platform image

Same code everywhere

Standard .NET development

News & Tutorials

How it works in practice

A process based on .NET standards

Develop a standard .NET application

Build your application using familiar .NET tools and patterns. Web API, service or console application: all project types are supported.

Access IBM i with NTi

Add the NTi NuGet package and connect to your IBM i. DB2 access, program calls and CL commands via standard .NET code.

Build the container image

Use a standard Dockerfile to package the application. The image contains the application and its runtime environment.

Multi-environment deployment

The same image runs as a container on the infrastructure of your choice (Linux, ARM, Power, cloud or on-premises). Access to IBM i works in exactly the same way everywhere.

Key benefits

The reference standard for building, deploying, and evolving applications.

Controlled application decoupling

.NET applications run outside IBM i. Changes, incidents or scaling never impact the central system.

Portability and reproducibility

An application built once runs everywhere. Same image, same runtime, same behavior across all environments.

Controlled scalability

.NET applications scale horizontally by duplicating containers. The load is handled on the .NET side, without putting any strain on IBM i.

Resource optimization

Containers are lightweight and consume minimal CPU and memory. No heavy VM per application, better density and higher efficiency.

Security through isolation

Each application runs in its own container. IBM i is never exposed and retains all its native security mechanisms.

Standardized skills

Development and deployment rely on standard .NET tools: Visual Studio, Git, CI/CD. Less dependency on IBM i skills.

.NET / IBM i use cases
In containerized environments

Concrete, real-world scenarios deployable today with standard tools.

Containerized .NET API as an IBM i access layer

Context

Expose IBM i data and business logic without directly exposing the system to the Internet.

Implementation

A .NET API runs in a container and accesses DB2 for i, CL commands and RPG programs via NTi.

External clients

↓

.NET API
Running in a container

↓

IBM i
DB2 / RPG / CL
Not exposed to the Internet

IBM i remains the system of record
Application workload is handled outside IBM i
IBM i is never directly exposed

Modern web frontends connected to IBM i

Context

Build modern user interfaces while keeping IBM i as the backend.

Implementation

A containerized web frontend consumes a containerized .NET API. The same .NET application can access DB2 for i and other databases.

Web frontend
Container

↓

.NET API
Container
Single .NET codebase

↓

DB2 for i

Other databases

Modern interfaces without RPG rewrites
Independent scalability of frontend and backend
Multi-database access from a single .NET codebase

High-performance Linux containers on IBM Power

Context

Leverage an IBM Power infrastructure with high performance and low-latency requirements.

Implementation

.NET applications run in Docker containers on a Linux on Power partition, connected to IBM i through the internal PowerVM network.

Linux on IBM Power
.NET containers

→

IBM i
Internal PowerVM network
Low latency

Very low latency and high throughput
IBM i is not exposed to external networks
IBM Power infrastructure fully leveraged

CI/CD and reproducible environments

Context

Ensure strictly identical behavior across development, test and production environments.

Implementation

A single Docker image is built and deployed through standard .NET CI/CD pipelines. Configuration relies exclusively on environment variables.

Source
code

→

Docker
image

→

Dev·Test·Prod
Same image everywhere

Identical behavior across all environments
Automated deployments and simple rollbacks
No impact on IBM i configuration

Containerize .NET applications
around IBM i