APAC Container Image Tooling Guide 2026: Podman, Buildah, and Skopeo for Daemonless Enterprise Builds

Why APAC Enterprise Engineering Teams Are Replacing Docker

Docker transformed container adoption for APAC engineering teams — but the Docker Desktop licensing change, the security implications of Docker's root-privileged daemon, and the operational complexity of running Docker-in-Docker (DinD) in CI/CD have driven APAC platform engineering teams to evaluate daemonless alternatives.

The replacement stack that has emerged from the CNCF and Red Hat ecosystem is a three-tool combination: Podman for rootless container runtime, Buildah for daemonless OCI image construction, and Skopeo for registry operations. Together, these three tools cover the full container image lifecycle — local development, CI/CD builds, and cross-registry image management — without requiring a Docker daemon, root privileges, or a Docker Desktop commercial licence.

This guide covers how APAC mid-market enterprises (Singapore FSI, Japanese manufacturing, South Korean e-commerce, Southeast Asian tech) are adopting the Podman/Buildah/Skopeo stack as their primary container toolchain in 2026, and the APAC-specific considerations (licensing compliance, data sovereignty, air-gapped environments, Kubernetes-native CI/CD) that are accelerating adoption.

The Docker Desktop Licensing Problem for APAC Enterprises

Docker Desktop requires a paid subscription for commercial use in organisations with more than 250 employees or more than USD $10 million in annual revenue. For APAC mid-market enterprises that fall into this bracket, Docker Desktop licences across a development team of 100 engineers cost between USD $2,100 and $21,000 annually depending on subscription tier — creating a licence compliance obligation that many APAC procurement and legal teams had not anticipated when Docker shifted its licensing model.

Beyond the direct licence cost, the Docker Desktop licence audit risk — where APAC organisations using Docker Desktop for commercial purposes without a paid subscription face retroactive licensing claims — has driven APAC legal and compliance teams at Singapore FSI firms, Japanese enterprise vendors, and South Korean conglomerates to mandate Docker Desktop alternatives as a risk management measure.

Podman Desktop is the direct Docker Desktop replacement: a free, open-source (Apache 2.0) container management GUI for macOS and Windows that provides the same container lifecycle management interface as Docker Desktop without the commercial licence requirement. Combined with Buildah for image building and Skopeo for registry operations, the Podman stack provides a complete Docker Desktop replacement that is cost-free for APAC commercial use.

Podman: The Container Runtime Layer

Architecture: why rootless matters for APAC security

Docker's architecture runs a dockerd daemon as root. Every Docker operation — starting a container, building an image, pulling from a registry — routes through this root-privileged daemon. If an APAC CI/CD pipeline step or a developer container is compromised, the attacker has access to the root-privileged Docker daemon and through it to the APAC host's full container runtime, other containers, and Docker socket.

Podman runs containers as Linux processes owned by the invoking user — no daemon, no root privilege. An APAC developer running podman run -it ubuntu bash runs the container as their own Linux user, using Linux user namespaces to map container root to the developer's unprivileged UID on the APAC host. Compromising the container grants the attacker the developer's unprivileged Linux user access — not root on the APAC host.

For APAC enterprise security teams implementing least-privilege policies, Podman's rootless model is a significant security improvement over Docker without requiring a change in container workflow.

Podman Desktop for APAC developer adoption

APAC engineer adoption of Docker Desktop alternatives depends on GUI parity. Command-line-comfortable APAC platform engineers can migrate to Podman CLI in an afternoon with alias docker=podman. APAC developers who rely on Docker Desktop's GUI for container management, log inspection, and volume browsing require Podman Desktop.

Podman Desktop provides:

• Container lifecycle management (start, stop, restart, remove)
• Real-time container log streaming
• Volume inspection and mounting
• Image registry browsing and pull
• Kubernetes integration (deploy to local k8s, generate YAML)
• Extension ecosystem for additional APAC tooling integrations

For APAC technology teams with a mix of platform engineers and application developers, Podman Desktop reduces the Docker Desktop migration friction for the non-CLI-native portion of the team.

Using Podman for Kubernetes development

APAC platform engineers frequently develop Kubernetes workloads locally before deploying to EKS, GKE, or AKS clusters. Podman's pod model bridges the gap:

# Start an APAC application pod locally with Podman
podman pod create --name apac-app-pod -p 8080:8080 -p 5432:5432
podman run -d --pod apac-app-pod --name apac-postgres postgres:16
podman run -d --pod apac-app-pod --name apac-app myregistry.apac.example.com/app:v1.2.0

# Generate Kubernetes YAML from the running Podman pod
podman generate kube apac-app-pod > apac-app-pod.yaml

# The generated YAML is valid Kubernetes Pod spec — deploy to APAC cluster
kubectl apply -f apac-app-pod.yaml

This workflow enables APAC developers to iterate on multi-container application configurations locally with Podman and export valid Kubernetes manifests for cluster deployment — without running a local Kubernetes cluster (minikube, kind) or deploying to a remote APAC development cluster for every iteration.

Podman systemd integration for APAC on-premise servers

APAC enterprise organisations running containerised workloads on on-premise Linux servers (common in Japanese manufacturing, South Korean government-adjacent sectors, and APAC financial services with data residency requirements) can use Podman's systemd integration to manage container lifecycles as system services:

# Generate systemd unit file from running APAC container
podman generate systemd --new --name apac-app > ~/.config/systemd/user/apac-app.service

# Enable container to start at boot and restart on failure
systemctl --user enable apac-app.service
systemctl --user start apac-app.service

# Container now managed by systemd: auto-restart, journald logging, boot-time start
journalctl --user -u apac-app.service -f

For APAC on-premise deployments where Kubernetes is unavailable or over-engineered for the workload, Podman with systemd provides container lifecycle management with the reliability guarantees of systemd service management.

Buildah: The Container Image Build Layer

Why DinD creates APAC security risks

Docker-in-Docker (DinD) — running a Docker daemon inside a container for CI/CD builds — requires the inner Docker container to run in privileged mode (--privileged). A privileged container in Kubernetes has near-complete access to the APAC host's kernel, can mount the host filesystem, and can escape container isolation. APAC security teams that have reviewed DinD deployments in Kubernetes CI/CD pipelines consistently flag this as an unacceptable container escape risk.

Docker socket mounting — an alternative to DinD where the APAC Kubernetes CI/CD pod mounts /var/run/docker.sock from the host — is equally risky. The Docker socket provides root-equivalent access to the APAC host's entire container runtime. A malicious or compromised CI/CD pipeline step with socket access can read other containers' filesystems, access their environment variables (containing APAC secrets), and control the APAC host's container runtime.

Buildah builds OCI images inside unprivileged Kubernetes pods without requiring --privileged or Docker socket mounting. Buildah uses Linux user namespace mapping and fuse-overlayfs (or VFS storage fallback) to assemble container image layers inside an unprivileged APAC Kubernetes pod, producing valid OCI images that Skopeo can push to the APAC container registry.

Rootless Buildah in a Tekton Task

For APAC platform teams using Tekton for Kubernetes-native CI/CD, Buildah is the recommended container image builder for APAC Tekton Tasks:

# Tekton Task: apac-buildah-build
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: apac-buildah-build
spec:
  params:
    - name: image-url
    - name: dockerfile
      default: "Dockerfile"
    - name: context
      default: "."
  workspaces:
    - name: source
  results:
    - name: image-digest
  steps:
    - name: build-and-push
      image: quay.io/buildah/stable:latest
      securityContext:
        runAsUser: 1000        # non-root APAC user
        runAsGroup: 1000
      env:
        - name: BUILDAH_ISOLATION
          value: chroot
        - name: STORAGE_DRIVER
          value: vfs            # rootless storage, no overlay kernel feature needed
      script: |
        #!/bin/bash
        buildah bud \
          -f $(params.dockerfile) \
          -t $(params.image-url) \
          $(workspaces.source.path)/$(params.context)

        buildah push \
          --digestfile /tmp/digest \
          $(params.image-url) \
          docker://$(params.image-url)

        echo -n "$(cat /tmp/digest)" | tee $(results.image-digest.path)

This Tekton Task builds the APAC container image and outputs the image digest as a Tekton Task result — which downstream Tekton Pipeline Tasks (deploy, sign, attest) consume to reference the specific immutable APAC image digest rather than a mutable tag.

Scripted image construction beyond Dockerfile

Buildah's scripted image construction model enables APAC engineering teams to build container images with dynamic logic that Dockerfile's static format cannot express:

#!/bin/bash
# Scripted APAC container image build with dynamic configuration

CONTAINER=$(buildah from ubi9-minimal)

# Install APAC-specific packages from internal mirror
buildah run $CONTAINER -- microdnf install -y java-21-openjdk-headless tzdata-asia

# Set APAC timezone
buildah run $CONTAINER -- ln -sf /usr/share/zoneinfo/Asia/Singapore /etc/localtime

# Copy APAC application artifacts
buildah copy $CONTAINER ./target/apac-app.jar /opt/app/app.jar
buildah copy $CONTAINER ./config/apac-production.yml /opt/app/config.yml

# Set image labels from CI environment (dynamic — impossible in static Dockerfile)
buildah config \
  --label build.git-sha=${GIT_SHA} \
  --label build.branch=${BRANCH} \
  --label build.timestamp=$(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --label build.pipeline=${PIPELINE_ID} \
  --env JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC" \
  --cmd "/opt/app/app.jar" \
  $CONTAINER

# Commit APAC image
buildah commit $CONTAINER apac-registry.example.com/apac-app:${GIT_SHA}
buildah push apac-registry.example.com/apac-app:${GIT_SHA}

# Clean up
buildah rm $CONTAINER

This script assembles the APAC container image with dynamic labels (Git SHA, branch, timestamp, pipeline ID) that would require complex ARG/ENV combinations in Dockerfile and cannot be set at build time without ARG declarations in the Dockerfile itself — which requires modifying the Dockerfile for every new metadata field.

Skopeo: The Registry Operations Layer

Image promotion without disk I/O

Container image promotion — moving an image from a development registry to a staging registry, and from staging to production — is a standard CI/CD operation that Skopeo implements without pulling image layers to disk.

The traditional Docker approach:

# Traditional Docker image promotion (pulls 500MB to agent disk)
docker pull dev-registry.apac.example.com/app:v1.2.3
docker tag dev-registry.apac.example.com/app:v1.2.3 prod-registry.apac.example.com/app:v1.2.3
docker push prod-registry.apac.example.com/app:v1.2.3
docker rmi dev-registry.apac.example.com/app:v1.2.3 prod-registry.apac.example.com/app:v1.2.3

The Skopeo approach:

# Skopeo image promotion (zero disk I/O — direct registry-to-registry transfer)
skopeo copy \
  --src-creds dev-user:${DEV_TOKEN} \
  --dest-creds prod-user:${PROD_TOKEN} \
  docker://dev-registry.apac.example.com/app:v1.2.3 \
  docker://prod-registry.apac.example.com/app:v1.2.3

Skopeo transfers the image manifest and layer blobs directly between registries without writing any layer data to the APAC CI/CD agent filesystem. For APAC engineering teams promoting 1-2GB container images (common for JVM application images with full JDK layers) across multiple pipeline stages daily, the elimination of disk I/O reduces CI/CD agent storage requirements and pipeline execution time.

Air-gap registry population for APAC on-premise environments

APAC financial services, defence-adjacent, and government-sector organisations frequently require air-gapped Kubernetes deployments — clusters that cannot reach the public internet for container image pulls. Skopeo's sync command provides the standard tool for populating air-gapped APAC registries:

# Phase 1: Download images from internet-connected build environment to directory
skopeo sync \
  --src docker \
  --dest dir \
  --all \
  registry.apac.example.com/apac-app \
  /airgap-bundle/images/

# Transfer /airgap-bundle/images/ to air-gapped APAC environment via approved channel

# Phase 2: Upload images from directory to air-gapped internal registry
skopeo sync \
  --src dir \
  --dest docker \
  --all \
  /airgap-bundle/images/ \
  internal-registry.apac.example.com/

This two-phase workflow — download to directory in connected environment, transfer via approved channel (encrypted USB, secure file transfer), upload to air-gapped registry — is the standard pattern for APAC organisations with MAS TRMG, HKMA SCR, or FSA FISC requirements mandating air-gapped production environments.

Digest pinning for APAC Kubernetes manifests

Kubernetes deployments referencing image tags (:latest, :v1.2.3) are non-deterministic — the tag may point to different image digests on different APAC registry replicas or after a registry image overwrite. APAC organisations with compliance requirements for reproducible deployments should pin Kubernetes image references to digest:

# Use Skopeo to extract current digest for APAC image tag
DIGEST=$(skopeo inspect \
  docker://registry.apac.example.com/app:v1.2.3 \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['Digest'])")

echo "Image digest: $DIGEST"
# sha256:a1b2c3d4e5f6...

# Substitute digest in APAC Kubernetes manifest
sed -i "s|image: registry.apac.example.com/app:v1.2.3|image: registry.apac.example.com/app@${DIGEST}|" k8s/deployment.yaml

This Skopeo inspect pattern — extracting the immutable digest from a tag reference — enables APAC CI/CD pipelines to pin Kubernetes manifests to the exact image SHA that was validated in CI, preventing APAC production deployments from accidentally running a different image than the tested artifact due to tag mutation.

Integrating the Three Tools: APAC Build Pipeline Architecture

The Podman/Buildah/Skopeo stack covers three distinct lifecycle phases for APAC container images:

A complete APAC container image pipeline using all three tools flows:

1. APAC developer runs podman run locally to test the application in containers
2. Git push triggers Tekton EventListener or Buildkite webhook
3. Tekton Task / Buildkite step calls Buildah to build and push the image to the dev registry with the Git SHA tag
4. Skopeo inspect extracts the image digest from the dev registry and records it in the pipeline artifact store
5. Security scan runs Trivy against the image digest in the dev registry
6. Skopeo copy promotes the digest-pinned image from dev registry to staging registry (direct, no disk I/O)
7. Staging deployment references the digest-pinned image in Kubernetes manifests
8. Staging validation runs integration tests against the staging environment
9. Skopeo copy promotes validated image from staging to production registry with release tag
10. Production deployment applies digest-pinned Kubernetes manifests to APAC production clusters

This pipeline satisfies APAC enterprise requirements for immutable image promotion (no image mutation after validation), APAC data sovereignty (all operations within APAC network boundaries), and CI/CD security (no Docker daemon, no privileged containers).

APAC Migration Path: From Docker Desktop to Podman/Buildah/Skopeo

APAC enterprise engineering organisations transitioning from Docker can follow this phased approach:

Phase 1 (Week 1–2): Developer workstation migration Install Podman Desktop on developer macOS and Windows workstations. Add alias docker=podman and alias docker-compose=podman-compose to developer shell profiles. Identify any APAC applications that use Docker-specific features (Docker Desktop Kubernetes, Docker BuildKit cache mounts) that require Buildah or configuration adjustments. The majority of APAC development workflows using standard docker run, docker build, and docker-compose commands migrate without modification.

Phase 2 (Week 3–4): CI/CD image build migration Replace Docker-in-Docker or Docker socket mounting in APAC CI/CD pipelines with Buildah. For Tekton-based APAC CI/CD, deploy the apac-buildah-build Task from Tekton Hub or the custom task above. For Buildkite-based APAC CI/CD, install Buildah on APAC build agents and update pipeline YAML to use buildah bud and buildah push instead of docker build and docker push.

Phase 3 (Week 5–6): Registry operations migration Install Skopeo on APAC CI/CD agents and add Skopeo-based image promotion steps to pipelines. Replace docker pull → docker tag → docker push promotion sequences with skopeo copy. Implement Skopeo digest pinning for APAC Kubernetes deployment manifests in production promotion steps.

Phase 4 (Week 7–8): Validation and rollback documentation Run APAC production pipelines on the Podman/Buildah/Skopeo stack with Docker as a fallback for one release cycle. Document APAC-specific edge cases discovered during migration. Remove Docker Desktop licences after successful validation.

APAC Compliance and Security Considerations

Data sovereignty

All three tools — Podman, Buildah, and Skopeo — are self-hosted open-source tools that run entirely within APAC infrastructure. No APAC container images, source code, credentials, or build metadata are sent to Red Hat or any third-party service during normal operation. APAC organisations with MAS, HKMA, or FSA data sovereignty requirements can deploy the full stack without data egress concerns beyond the APAC container registries they explicitly configure.

Container image signing

The Podman/Buildah/Skopeo stack integrates with Cosign (from the Sigstore project) for container image signing. APAC platform engineering teams can sign container images after Buildah builds and before Skopeo promotes them, with Kubernetes admission controllers (Kyverno, OPA Gatekeeper) verifying signatures on APAC production deployments:

# Sign APAC container image with Cosign after Buildah push
cosign sign --key cosign.key registry.apac.example.com/app@${DIGEST}

# Skopeo copy preserves the attached Cosign signature to destination registry
skopeo copy \
  docker://dev-registry.apac.example.com/app@${DIGEST} \
  docker://prod-registry.apac.example.com/app@${DIGEST}

Related APAC Platform Engineering Guides

For the CI/CD pipeline tooling that builds and promotes container images, see the APAC CI/CD platform engineering guide covering Tekton, Buildkite, and Gradle.

For the Kubernetes deployment and GitOps tooling that runs the containers built by this stack, see the APAC Kubernetes GitOps deployment guide covering Argo CD, Argo Rollouts, and Velero.

For the data ingestion and pipeline tooling that feeds APAC ML and analytics workloads running in these containers, see the APAC data ingestion and ELT guide covering Airbyte, Apache NiFi, and Stitch.