Skip to main content
Run the IBM i MCP Server as a container using the official pre-built images from GitHub Container Registry. Supports amd64, arm64, and ppc64le architectures.

Quick Start

Pull and run the server in under a minute:
Verify the server is running:
Replace the DB2i_* values with your actual IBM i credentials. Never commit credentials to source control.

Available Images

Images are published to GitHub Container Registry on each release:
ArchitectureImage TagPlatform
x86-64ghcr.io/ibm/ibmi-mcp-server:amd64-v0.3.1Standard servers, cloud VMs
ARM 64-bitghcr.io/ibm/ibmi-mcp-server:arm64-v0.3.1Apple Silicon, ARM cloud instances
Power (LE)ghcr.io/ibm/ibmi-mcp-server:ppc64le-v0.3.1IBM Power Systems
Running on IBM Power Systems? Use the ppc64le image to run the MCP server natively on the same hardware as your IBM i partition — no emulation overhead.

Using an Environment File

For easier management, store your configuration in a .env file:
Then run with the env file:

Mounting Custom SQL Tools

To use your own YAML tool configurations, mount them into the container:
The :ro flag mounts the directory as read-only inside the container, which is a security best practice.

Docker Compose

For a more complete setup, use Docker Compose to run the MCP server alongside supporting services.

Standalone Server

Create a docker-compose.yml:
Start the service:

With MCP Context Forge Gateway

The repository includes a full-stack Docker Compose configuration with MCP Context Forge — a gateway that provides tool federation, authentication, rate limiting, and an admin UI.
This starts the following services:
ServicePortDescription
MCP Context Forge4444Gateway with admin UI, tool federation, auth
IBM i MCP Server3010SQL tools MCP server
PostgreSQLGateway metadata storage (internal)
Redis6379Session cache
pgAdmin5050Database admin UI
Redis Insight5540Cache admin UI
The MCP Context Forge Gateway image must be built locally before starting the stack. See the MCP Context Forge docs for build instructions.

Container Management

Viewing Logs

Stopping and Removing

Health Checks

The server exposes a health endpoint at /healthz:

Building from Source

If you need to build the image locally instead of pulling from GHCR:
The Dockerfile uses a multi-stage build:
  1. deps — Installs production Node.js dependencies
  2. builder — Installs all dependencies and compiles TypeScript
  3. runner — Final minimal image with only production deps and compiled output
The image runs as a non-root user (appuser) for security. Port 3010 is exposed by default.

Troubleshooting

Check the container logs for error details:
Common causes:
  • Missing or incorrect DB2i_* environment variables
  • Mapepire not running on the IBM i system
  • Network connectivity issues to IBM i host
Verify the container can reach your IBM i system:
If using Docker Desktop on macOS/Windows, ensure the IBM i host is reachable from within the VM.
If port 3010 is already in use, map to a different host port:
The container runs as a non-root user. Ensure mounted files are readable:
On SELinux-enabled systems (RHEL/Fedora), add the :z flag: