SOA Suite on Docker – the Apple Silicon Edition

Following my blog post series on running Oracle SOA Suite in Docker and the recent 14c edition update on the Broadpin Techblog, here is the next instalment: getting SOA Suite 14c running natively on an Apple Silicon (ARM) Mac. No emulation, no 30-minute cold starts.

The Problem with the Obvious Approach

The quickest way to run Docker on a Mac is Colima, which you can install with a single Homebrew command:

brew install colima docker
colima start --arch aarch64 --memory 16 --cpu 4

The --arch aarch64 flag tells Colima to run the VM in ARM mode, which matches the Apple Silicon chip. So far so good. However, all official SOA Suite images on the Oracle Container Registry are built for linux/amd64 only. When you pull and run one of them on an ARM host, Docker transparently translates x86_64 instructions to ARM via QEMU emulation – and you will notice. A server that starts in under 3 minutes on native ARM takes roughly 20 minutes under QEMU emulation. For a dev/test environment you restart many times a day, that is simply not acceptable.

The fix is to build a native linux/arm64 image using the Oracle WebLogic Image Tool (imagetool). As a bonus, building your own image also means you can apply patches as soon as they drop — something that matters right now, since the April 2026 CPU is not yet reflected in any image on the Oracle Container Registry.

Prerequisites

• Colima + Docker (see above)

• JDK 21 installed on the Mac (typically at /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home)

• An Oracle Support account (needed to download patches)

• The following installer JARs downloaded from My Oracle Support / edelivery: fmw_14.1.2.0.0_infrastructure.jar fmw_14.1.2.0.0_soa.jar jdk-21_linux-aarch64_bin.tar.gz (important: this must be the aarch64 Linux JDK, not the x64 one – it gets installed inside the ARM container)

• The container-scripts from the oracle/docker-images GitHub repository (OracleSOASuite/dockerfiles/14.1.2.0/container-scripts)

The first step is to get the weblogic imagetool that allows creating customized Docker Images for Fusion Middlware products.

curl -m 120 -fL \
  https://github.com/oracle/weblogic-image-tool/releases/latest/download/imagetool.zip \
  -o ./imagetool.zip
unzip imagetool.zip
cd imagetool/bin 

Before building, imagetool needs to know where your installer files are. Register them in the local cache:

./imagetool.sh cache addInstaller \
  -t fmw \
  -p /Users/jmichler/imagetool/installers/fmw_14.1.2.0.0_infrastructure.jar \
  -v 14.1.2.0.0

./imagetool.sh cache addInstaller \
  -t soa \
  -p /Users/jmichler/imagetool/installers/fmw_14.1.2.0.0_soa.jar \
  -v 14.1.2.0.0

./imagetool.sh cache addInstaller \
  -t jdk \
  -p /Users/jmichler/imagetool/installers/jdk-21_linux-aarch64_bin.tar.gz \
  -v 21u11 

Issue 1: --latestPSU Does Not Work for SOA 14c

You might expect to run imagetool with --latestPSU or --recommendedPatches to automatically pull the latest patches. Unfortunately this currently fails with a PatchObject constructor error when the SOA Stack Patch Bundle (SPB) is involved (see weblogic-image-tool #567). The workaround is to specify patches explicitly via --patches, as shown in the final command below.

Issue 2: UMS and FMW Control Patches Fail Validation

When including patches for Oracle UMS (Unified Messaging Service) or FMW Control, imagetool rejects them with Invalid ARU data found in patch product ID: 16612. This is a bug in imagetool's product registry – UMS (product ID 16612) and FMW Control (48949) are not listed as valid SOA sub-components in AruProduct.java (see weblogic-image-tool #568).

The fix is a one-line addition per missing product in the imagetool source. Until Oracle ships a fixed release, the workaround is to rebuild imagetool after adding the two entries to AruProduct.java:

UMS("16612", "Oracle Service Delivery Platform"),
FMW_CONTROL("48949", "Oracle Fusion Middleware Control") 

With the cache populated and the issues above accounted for, the full build command is:

JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home ./imagetool.sh create \
  --jdkVersion=21u11 \
  --pull \
  --type=SOA \
  --tag my_soa14:arm \
  --version=14.1.2.0.0 \
  --user your.name@yourcompany.com \
  --password \
  --opatchBugNumber=28186730_13.9.4.2.23 \
  --patches 39164253,39051778,38887889,39043853,39175119,38974223,38879142,38976275,39096850,38566996,38391376,38637356 \
  --fromImage ghcr.io/oracle/oraclelinux:9-slim \
  --additionalBuildFiles /Users/jmichler/soa-ops/oracle-docker-images/container-scripts/ \
  --additionalBuildCommands /Users/jmichler/soa-ops/oracle-docker-images/additionalBuildCmds.txt \
  --platform linux/arm64 

The patch list above reflects the April 2026 CPU. The current recommended patch set for any given release can be looked up in My Oracle Support Knowledge Base article Doc ID 2806740.2 / KB175772.

The key flag here is --platform linux/arm64. This instructs Docker buildx (which imagetool uses under the hood) to produce a native ARM image. The --fromImage points to an ARM-compatible Oracle Linux 9 slim base from the GitHub Container Registry.

The --password flag without a value will prompt you interactively, which avoids storing credentials in shell history or scripts.

The --additionalBuildCommands file injects the SOA-specific configuration on top of the base FMW install. Here is the file used:

[package-manager-packages]
libaio hostname perl

[final-build-commands]
ENV    VOLUME_DIR=/u01/oracle/user_projects \
    SCRIPT_FILE=/u01/oracle/container-scripts/* \
    HEALTH_SCRIPT_FILE=/u01/oracle/container-scripts/get_healthcheck_url.sh \
    JAVA_OPTIONS="-Doracle.jdbc.fanEnabled=false -Dweblogic.StdoutDebugEnabled=false" \
    OPATCH_NO_FUSER=true

# Healthcheck
HEALTHCHECK --interval=60s --start-period=300s \
    CMD curl -k -s --fail `$HEALTH_SCRIPT_FILE` || exit 1

RUN mkdir -p /u01/oracle/user_projects/domains \
    && chown -R oracle:oracle /u01/oracle/user_projects

# Default command
CMD ["/u01/oracle/container-scripts/createDomainAndStart.sh"]
COPY --chown=oracle:oracle files/container-scripts /u01/oracle/container-scripts 

The container-scripts referenced here are taken directly from the official oracle/docker-images repository (OracleSOASuite/dockerfiles/14.1.2.0/container-scripts) – no customisation needed.

Once the image is built, starting a SOA Suite environment with it is identical to what I described in the 14c edition post – same env files, same docker run commands.

The difference is the numbers:

• with the linux/amd64 image via QEMU on Apple Silicon the "cold" startup time (including creation of the domain) is ~26 minutes. A re-start of an existing domain takes 14 minutes.

• With this Native linux/arm64 image the "cold" creation of an environment lasts 3.5 minutes; bringing the environment up again takes 2.5 minutes.

That is roughly a 7x-10x improvement just from removing the emulation layer. For a local dev or demo environment that you might restart several times a day, this makes a real difference. The performance improvement is not only visible during startup but also while navigating the UI or deploying SOA Suite composites.

Note: This includes the startup of an Oracle Database for the SOA Suite Repository; since the container registry has native arm64 images there those don't require the translation to x86 in both scenarios though.

Running Oracle SOA Suite on Apple Silicon is perfectly viable in 2026, but only if you take the time to build a native ARM image rather than relying on QEMU emulation. The Oracle WebLogic Image Tool makes this straightforward. You also get an immediate side benefit: the April 2026 CPU is already included in the patch list above, whereas the Oracle Container Registry has not been updated yet — so the self-built image is actually more up-to-date than the official one at this point.

Two known rough edges to watch out for (those will be fixed in the next release after 1.16.3):

• --latestPSU currently does not work for SOA 14c – use explicit --patches instead (#567)

• UMS and FMW Control patches require a small source patch to imagetool until Oracle ships a fix (#568)

Both issues have been reported upstream. Hopefully a fixed imagetool release will land soon and simplify this further.

This post is part of an ongoing series on running Oracle SOA Suite in Docker.