- Quick Reference
- Supported tags and respective Dockerfile links
- Supported Architectures
- What is Open Integration Engine
- How to use this image
- License
Quick Reference ↑
- 🌐 Website: openintegrationengine.org
- 💬 Discord: Join our server
- 📂 GitHub Repo: github.com/OpenIntegrationEngine/engine
https://github.com/OpenIntegrationEngine/engine/issues
Please do your best to include the following information in your issue:
- The exact commit hash of the code you are using
- The commands you executed to build or run the image
- The output of the command you executed (Hint: add
--progress=plain
to yourdocker
command to see the full output) - Use Markdown to format your issue text, ESPECIALLY if you are including code snippets or command output. This will make it easier for us to read and understand your issue.
What is Open Integration Engine ↑
An open-source message integration engine focused on healthcare. For more information please visit openintegrationengine.org.
OpenIntegrationEngine is a community-driven project that continues the legacy of Mirth Connect, providing a flexible, open platform for managing healthcare interfaces. It supports a wide range of healthcare standards and protocols, enabling seamless integration between disparate systems.
OpenIntegrationEngine is designed to be vendor-neutral, allowing healthcare organizations to connect their systems without being locked into proprietary solutions. It offers a user-friendly interface for building, deploying, and managing interfaces, along with powerful features for real-time monitoring and alerting.
Supported Images ↑
All Open Integration Engine releases are packaged into the four following images:
latest
,latest-alpine
,latest-alpine-jre
4.5.2-tp.1-alpine
,4.5.2-tp.1-alpine-jre
latest-alpine-jdk
4.5.2-tp.1-alpine-jdk
latest-ubuntu
,latest-ubuntu-jre
4.5.2-tp.1-ubuntu
,4.5.2-tp.1-ubuntu-jre
latest-ubuntu-jdk
4.5.2-tp.1-ubuntu-jdk
Supported Architectures ↑
Docker images for OIE 4.5.2 and later versions support both linux/amd64
and linux/arm64
architectures. As an example, to pull the latest linux/arm64
image, use the command
docker pull --platform linux/arm64 openintegrationengine/engine:latest
How to use this image ↑
Start an OpenIntegrationEngine instance ↑
Quickly start OpenIntegration using embedded Derby database and all configuration defaults. At a minimum you will likely want to use the -p
option to expose the 8443 port so that you can log in with
the Administrator GUI or CLI:
docker run -p 8443:8443 openintegrationengine/engine
You can also use the --name
option to give your container a unique name, and the -d
option to detach the container and run it in the background:
docker run --name myengine -d -p 8443:8443 openintegrationengine/engine
To run a different base image, specify a tag at the end:
docker run --name myengine -d -p 8443:8443 openintegrationengine/engine:latest-alpine-jdk
To run using a specific architecture, specify it using the --platform
argument:
docker run --name myengine -d -p 8443:8443 --platform linux/arm64 openintegrationengine/engine
Look at the Environment Variables section for more available configuration options.
Using docker stack deploy
or docker compose
↑
With docker stack
or docker compose
you can easily set up and launch multiple related containers. For example, you might want to launch both Engine and a PostgreSQL database to run alongside it.
docker compose -f stack.yml up
Here's an example stack.yml
file you can use:
services:
engine:
image: openintegrationengine/engine
environment:
- DATABASE=postgres
- DATABASE_URL=jdbc:postgresql://db:5432/enginedb
- DATABASE_MAX_CONNECTIONS=20
- DATABASE_USERNAME=enginedb
- DATABASE_PASSWORD=enginedb
- DATABASE_MAX_RETRY=2
- DATABASE_RETRY_WAIT=10000
- KEYSTORE_STOREPASS=docker_storepass
- KEYSTORE_KEYPASS=docker_keypass
- VMOPTIONS=-Xmx512m
ports:
- "8080:8080/tcp"
- "8443:8443/tcp"
depends_on:
- db
db:
image: postgres
environment:
- POSTGRES_USER=enginedb
- POSTGRES_PASSWORD=enginedb
- POSTGRES_DB=enginedb
ports:
- "5432:5432/tcp"
Environment Variables ↑
You can use environment variables to configure the mirth.properties file or to add custom JVM options.
To set environment variables, use the -e
option for each variable on the command line:
docker run -e DATABASE='derby' -p 8443:8443 openintegrationengine/engine
You can also use a separate file containing all of your environment variables using the --env-file
option. For example let's say you create a file myenvfile.txt:
DATABASE=postgres
DATABASE_URL=jdbc:postgresql://serverip:5432/enginedb
DATABASE_USERNAME=postgres
DATABASE_PASSWORD=postgres
DATABASE_MAX_RETRY=2
DATABASE_RETRY_WAIT=10000
KEYSTORE_STOREPASS=changeme
KEYSTORE_KEYPASS=changeme
VMOPTIONS=-Xmx512m
docker run --env-file=myenvfile.txt -p 8443:8443 openintegrationengine/engine
Common mirth.properties options ↑
The database type to use for the Open Integration Engine backend database. Options:
- derby
- mysql
- postgres
- oracle
- sqlserver
The JDBC URL to use when connecting to the database. For example:
jdbc:postgresql://serverip:5432/enginedb
The username to use when connecting to the database. If you don't want to use an environment variable to store sensitive information like this, look at the Using Docker Secrets section below.
The password to use when connecting to the database. If you don't want to use an environment variable to store sensitive information like this, look at the Using Docker Secrets section below.
The maximum number of connections to use for the internal messaging engine connection pool.
On startup, if a database connection cannot be made for any reason, Engine will wait and attempt again this number of times. By default, will retry 2 times (so 3 total attempts).
The amount of time (in milliseconds) to wait between database connection attempts. By default, will wait 10 seconds between attempts.
The password for the keystore file itself. If you don't want to use an environment variable to store sensitive information like this, look at the Using Docker Secrets section below.
The password for the keys within the keystore, including the server certificate and the secret encryption key. If you don't want to use an environment variable to store sensitive information like this, look at the Using Docker Secrets section below.
The type of keystore.
If set to true, the web server sessions are stored in the database. This can be useful in situations where you have multiple Engine servers (connecting to the same database) clustered behind a load balancer.
A comma-separated list of JVM command-line options to place in the .vmoptions
file. For example to set the max heap size:
- -Xmx512m
This tells the entrypoint script to wait for a certain amount of time (in seconds). The entrypoint script will automatically use a command-line SQL client to check connectivity and wait until the database is up before starting Engine, but only when using PostgreSQL or MySQL. If you are using Oracle or SQL Server and the database is being started up at the same time as Engine, you may want to use this option to tell Engine to wait a bit to allow the database time to startup.
A URL location of a Engine keystore file. This file will be downloaded into the container and Engine will use it as its keystore.
A URL location of a zip file containing Engine extension zip files. The extensions will be installed on the Engine server.
A URL location of a zip file containing JAR files. The JAR files will be installed into the server-launcher-lib
folder on the Engine server, so they will be added to the server's classpath.
Allow insecure SSL connections when downloading files during startup. This applies to keystore downloads, plugin downloads, and server library downloads. By default, insecure connections are disabled,
but you can enable this option by setting ALLOW_INSECURE=true
.
Set the server.id
to a specific value. Use this to preserve or set the server ID across restarts and deployments. Using the env-var is preferred over storing appdata
persistently
Other mirth.properties options ↑
Other options in the mirth.properties file can also be changed. Any environment variable starting with the _MP_
prefix will set the corresponding value in mirth.properties. Replace .
with a single
underscore _
and -
with two underscores __
.
Examples:
-
Set the server TLS protocols to only allow TLSv1.2 and 1.3:
- In the mirth.properties file:
https.server.protocols = TLSv1.3,TLSv1.2
- As a Docker environment variable:
_MP_HTTPS_SERVER_PROTOCOLS='TLSv1.3,TLSv1.2'
- In the mirth.properties file:
-
Set the max connections for the read-only database connection pool:
- In the mirth.properties file:
database-readonly.max-connections = 20
- As a Docker environment variable:
_MP_DATABASE__READONLY_MAX__CONNECTIONS='20'
- In the mirth.properties file:
Using Docker Secrets ↑
For sensitive information such as the database/keystore credentials, instead of supplying them as environment variables you can use a Docker Secret. There are two secret names this image supports:
If present, any properties in this secret will be merged into the mirth.properties file.
If present, any JVM options in this secret will be appended onto the mcserver.vmoptions file.
Secrets are supported with Docker Swarm, but you can also use them with docker compose
.
For example let's say you wanted to set keystore.storepass
and keystore.keypass
in a secure way. You could create a new file, secret.properties:
keystore.storepass=changeme
keystore.keypass=changeme
Then in your compose.yaml
:
services:
engine:
image: openintegrationengine/engine
environment:
- VMOPTIONS=-Xmx512m
secrets:
- mirth_properties
ports:
- "8080:8080/tcp"
- "8443:8443/tcp"
secrets:
mirth_properties:
file: /local/path/to/secret.properties
The secrets section at the bottom specifies the local file location for each secret. Change /local/path/to/secret.properties
to the correct local path and filename.
Inside the configuration for the Engine container there is also a secrets section that lists the secrets you want to include for that container.
Using Volumes ↑
The appdata folder ↑
The application data directory (appdata) stores configuration files and temporary data created by Engine after starting up. This usually includes the keystore file and the server.id
file that stores
your server ID. If you are launching Engine as part of a stack/swarm, it's possible the container filesystem is already being preserved. But if not, you may want to consider mounting a volume to
preserve the appdata folder.
docker run -v /local/path/to/appdata:/opt/engine/appdata -p 8443:8443 openintegrationengine/engine
The -v
option makes a local directory from your filesystem available to the Docker container. Create a folder on your local filesystem, then change the /local/path/to/appdata
part in the example
above to the correct local path.
You can also configure volumes as part of your compose.yaml
:
services:
engine:
image: openintegrationengine/engine
volumes:
- ~/Documents/appdata:/opt/engine/appdata
Additional extensions ↑
The entrypoint script will automatically look for any .zip
files in the /opt/engine/custom-extensions
folder and unzip them into the extensions folder before Engine starts up.
So to launch Engine with any additional extensions not included in the base application, do this:
docker run -v /local/path/to/custom-extensions:/opt/engine/custom-extensions -p 8443:8443 openintegrationengine/engine:latest-ubuntu-jre
Create a folder on your local filesystem containing the ZIP files for your additional extensions. Then change the /local/path/to/custom-extensions
part in the example above to the correct local path.
As with the appdata example, you can also configure this volume as part of your compose.yaml
.
Currently, only the Debian flavored images support the newest authentication scheme in MySQL 8. All others (the Alpine based images) will need the following to force the MySQL database container to start using the old authentication scheme:
command: --default-authentication-plugin=mysql_native_password
Example:
db:
image: mysql
command: --default-authentication-plugin=mysql_native_password
environment:
...
To build the full set of four images (ubuntu-jre
, ubuntu-jdk
, alpine-jre
, and alpine-jdk
) run the following command in the deploy/
directory:
docker compose build --build-arg CREATED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
License ↑
The Dockerfiles, entrypoint script, and any other files used to build these Docker images are Copyright © NextGen Healthcare and OpenIntegrationEngine contributors. They are licensed under the Mozilla Public License 2.0.