Recently I worked on getting our stream pipeline running on i-PRO’s ADAM camera framework — an embedded app platform built on top of Panasonic’s Amba V5X SoC. Here’s what that looked like and what made it interesting.

The Landscape: Embedded Cameras Aren’t Linux VMs

i-PRO cameras don’t run Debian. They run a real-time OS with the ADAM (Application Development and Management) framework — essentially a constrained app runtime with its own lifecycle, event model, and sandboxing. Think of it as the world’s most opinionated Docker for cameras, but without the networking stack or package manager.

The target hardware runs an ARM64 (aarch64) AmbaCV5XCEX SoC with ~180 MB of heap available to applications. That’s not a lot when your model weights are already in the hundreds of megabytes. The catch: i-PRO cameras come pre-installed with Python 3.7 under /usr/bin/python3, so you’re working with what’s there.

Architecture Overview

┌─────────────────────────────────────────────┐
│              i-PRO Camera                    │
│                                             │
│  ┌──────────────┐   ┌──────────────────┐   │
│  │   ADAM Core  │◄──►│  Platerecognizer │   │
│  │  (C/C++ API) │   │     Stream App    │   │
│  └──────┬───────┘   │                  │   │
│         │            │  main.cpp (host) │   │
│         │            │  pymain.py (logic)│   │
│         ▼            │                  │   │
│  ┌──────────────┐    └──────────────────┘   │
│  │  Python 3.7  │                           │
│  │  (bundled or │◄── appPrefs.json           │
│  │   camera-inst)│                           │
│  └──────────────┘    ┌──────────────────┐   │
│                      │  ONNX Runtime     │   │
│                      │  + OpenCV         │   │
│                      └──────────────────┘   │
└─────────────────────────────────────────────┘

The app splits into two layers:

The C++ Host (main.cpp)

This is the bridge between ADAM’s event loop and your Python logic. It handles:

• Camera lifecycle (start/stop/restart callbacks)
• App preferences passed from the i-PRO web UI (via appPrefs.json)
• Memory management for the Python GIL across threads
• Communication back to ADAM Core for frame data access

The C++ code embeds the Python interpreter using Py_Initialize() and PyRun_SimpleFile() — it reads a Python file from disk and executes it in-process. This is simpler than building a full Python-C API bridge, and perfectly adequate when your Python module is mostly stateless processing logic.

// Simplified embedding pattern from main.cpp
void initPython() {
  // Dynamic PYTHONPATH based on deployment target
  #if defined(ADAM_TARGET_PF_ipro_ambaCV5XCAZ_linux)
    std::string pythonPath = "/app/python";
  #else
    std::string pythonPath = ADAM_GetAppDataDirPath() + "/../python";
  #endif
  
  // Conditional PyEval_InitThreads for Python < 3.9 compatibility
  #if (PY_MAJOR_VERSION == 3) && (PY_MINOR_VERSION < 9)
    PyEval_InitThreads();
  #endif
  
  Py_Initialize();
  s_pAdamModule = PyImport_ImportModule("libAdamApiPython");
}

void executePython() {
  std::string pyFile = /* resolved path */ + "pymain.py";
  
  FILE* pFp = fopen(pyFile.c_str(), "r");
  PyGILStateLock _lock; // RAII GIL management
  int ret = PyRun_SimpleFile(pFp, pyFile.c_str());
  if (ret != 0) {
    PyErr_Print();
    ADAM_DEBUG_PRINT(ADAM_LV_ERR, "Python execution failed\n");
  }
}

The PyGILStateLock class is critical here — it’s a RAII guard that ensures the GIL is acquired before any Python C API calls and released when the scope exits. Without it, you get intermittent crashes that are nearly impossible to reproduce in testing.

The Python Runtime (pymain.py)

The actual plate recognition logic lives in Python. This is where the ONNX model runs, frames get processed through OpenCV, and results get formatted for the ADAM event system. Since i-PRO’s environment provides libAdamApiPython, you get access to:

• Camera frame data streams
• App preferences (license key, token, log level) from appPrefs.json
• HTTP networking to PlateRecognizer’s API (for cloud mode) or local detection models

{
  "preference": [
    { "prefName": "LICENSE_KEY", "prefType": "String" },
    { "prefName": "TOKEN",      "prefType": "String" },
    { "prefName": "LOGGING",    "prefType": "Enumeration",
      "enumerationList": ["10","20","30","40","50"] }
  ]
}

These preferences are what the camera’s web UI shows to end-users — no code change needed between a dev install and production deployment.

Building: Two Paths, Same Result

The project ships two Dockerfiles for different build scenarios:

Local Build (Dockerfile.ext)

For development and testing without i-PRO’s cloud toolchain:

ARG CADAMBUILDBASE_PATH
ARG CADAMAPPBASE_PATH
FROM ${CADAMBUILDBASE_PATH} AS build-env

WORKDIR /app
COPY . ./
WORKDIR /iprosdk
RUN chmod +x setup_env.sh
RUN /bin/bash -c "source setup_env.sh ambaCV5XCEXinternal && \
    cd /app && \
    make clean && \
    make"

FROM ${CADAMAPPBASE_PATH} AS aplbase
RUN useradd -ms /bin/bash moduleuser
WORKDIR /app
COPY --from=build-env /app/ /app/
USER moduleuser

This uses the camera SDK’s cross-compilation toolchain to produce a .ext package — i-PRO’s app bundle format. The Makefile is ADAM-specific and auto-generates build rules based on TARGET_FOR_ADAM.

Azure IoT Build (Dockerfile.azureIoT)

For production builds, i-PRO hosts the SDK in their private ACR:

FROM iprocamsdk.azurecr.io/sdk/containeradam/env/cdamenv:1.0.0 AS build-env

RUN mv /iprosdk/lib/aarch64-linux-gnu_CV5XCAZ/libForPython3.7/* \
    /iprosdk/lib/aarch64-linux-gnu_CV5XCAZ

RUN /bin/bash -c "source setup_env.sh ambaCV5XCAZipro && \
    cd /app && make clean && make"

FROM iprocamsdk.azurecr.io/sdk/containeradam/env/cdamappbase:1.0.0 AS aplbase
COPY --from=build-env /app/ /app/
CMD ["/usr/share/lib/cadamClient"]

The libForPython3.7 symlink dance is a known workaround — the SDK’s library layout changes between versions and the Python module loader needs to find .so files in a specific path.

Configuration at Runtime

The app’s configuration file tells ADAM everything about the binary:

APPLICATION     platerecognizerStream
APPVERSION      V1.2
ROMSIZE         1055920
RAMSIZE         300000
CPURATE         90
FUNCID          00002178

• RAMSIZE (300 KB) is the temporary allocation on top of the heap — not total memory
• CPURATE (90%) tells ADAM this app needs aggressive scheduling; higher values mean more CPU budget but less sharing with other apps on the same camera
• FUNCID is a licensing marker used by i-PRO’s app store for version tracking

The Installer: A Python CLI You’ll Actually Use

Since these cameras don’t have pip or a package manager, we built a small installer that talks to the camera’s ADAM CGI endpoints over HTTP Digest auth:

# installer.py uses requests-toolbelt for multipart uploads
# with tqdm progress bars — because watching a 15MB upload on a slow link
# deserves better than blank terminal output

def upload_adam_app(ext_file_path):
    file_size = os.path.getsize(ext_file_path)
    progress_bar = tqdm.tqdm(desc=f"Uploading [{ext_file_path}]",
                             total=file_size, unit="B", 
                             unit_scale=True, unit_divisor=1024)
    
    def progress_callback(monitor):
        progress_bar.update(monitor.bytes_read - progress_bar.n)
    
    encoder = MultipartEncoder(fields={
        "methodName": "installApplication",
        "applicationPackage": (os.path.basename(ext_file_path), fp, 
                               "application/octet-stream"),
    })
    monitor = MultipartEncoderMonitor(encoder, progress_callback)
    response = requests.post(url, data=monitor, auth=HTTPDigestAuth(user, pass))

It handles the full lifecycle: list → stop → uninstall → upload → start. No manual SSH needed.

What Made This Hard

1. Python GIL + Real-Time Scheduling

The ADAM framework runs the app’s main thread in a real-time event loop. Embedding Python means that loop competes with PyEval_InitThreads() for CPU time. The solution was using Py_UNBLOCK_THREADS before the ADAM event dispatch and Py_BLOCK_THREADS after — effectively telling the interpreter “this is safe to suspend.”

2. Memory Is Everything

The V5XCEX SoC has 1GB total RAM, but the camera firmware, video encoding, and network stack consume most of it. Your app gets ~180 MB heap plus a small scratch buffer. This means:

• No lazy model loading — everything initializes before the first frame
• OpenCV uses cv2.IMREAD_GRAYSCALE where possible to halve frame buffers
• ONNX models use the execution provider optimized for ARM NEON (not CUDA)

3. Cross-Compilation Is a Black Box

i-PRO’s toolchain isn’t standard Yocto or Buildroot — it’s vendor-supplied and opaque. You get setup_env.sh which sets compiler paths, sysroot, and flags. Breaking the build pipeline for new SDK versions is an annual maintenance task.

Debugging

i-PRO ships two tools worth knowing about:

• Resource Monitor — Docker container browser, live tail of container logs, and per-container resource usage.
• Adam Operations UI (Chrome extension) — start, stop, uninstall apps; useful when the web UI is unresponsive.

Remember: no SSH to the camera by default. No gdb attached to the process. The only debug output goes through ADAM’s logging infrastructure (ADAM_DEBUG_PRINT) which surfaces in the i-PRO web UI at a configurable log level — and even then, it’s line-buffered.

Installation Walkthrough

Here’s what deployment looks like in practice:

Supported models: CV52-series cameras with Docker capability — WV-X15300, WV-X15500, WV-X22300, WV-X22500 and the X25600/X22600/WV-X15700/WV-X22700/WV-X25700 lines. The older CV2/CV22/CV25m (ambaCV2X) chips are not supported.

Before you start:

• Upgrade to the latest firmware first — extract the .img file from i-PRO’s documentation database and install via Setup > Maintenance > Upgrade. Stream needs Docker support that only ships in recent firmwares.
• Enable “Ext. software mode” in the camera UI, then mount /mnt/sda/adamapp → /user-data for SD card storage. The flash has a write-cycle limit; without an SD card you’ll kill the camera’s NAND over time.
• You need ~700 MB free (Stream + models) and internet access from the camera for license validation.

Installing: The camera runs two AdamApps: the Docker extension module (prerequisite, installed from i-PRO’s docs first), then the Stream .ext bundle itself. You can use the camera web UI (Setup > Application > Extensions) or the Adam Operations UI Chrome extension. If the camera throws a ROM error during install, just retry — it works.

Configuring detection: Everything goes through the Plate Recognizer dashboard — add your camera with an RTSP URL from these patterns:

rtsp://<cam_ip>:554/mediainput/h264/stream_1
rtsp://<user:pass>@<cam_ip>:554/mediainput/h264/stream_1
# stream_2, stream_3, stream_4 for multi-stream cameras

Recommended feed: 1280×720 at 15fps, H.264.

For detection results, enable webhooks in the Plate Recognizer account and turn on caching if the camera’s internet is spotty — it queues results locally and flushes when connectivity returns.

The biggest win: the Python code is identical to what runs on Docker. Only the C++ host layer changes — the embedding glue that translates ADAM events into Python calls. Everything from frame processing through API submission stays in one pymain.py.

Open Questions

• Can we replace the Python host with a Rust binary that spawns Python as needed, reducing memory pressure?
• The ADAM framework doesn’t expose GPU acceleration — is there a path to NPU inference on newer i-PRO models?
• Would container-based deployment (Dockerfile.ext) eventually replace .ext packages for app distribution?

For now, it runs. And running on edge cameras that have never seen Docker is still one of the more satisfying engineering victories I’ve had this year.

This work is part of the deep-license-plate-recognition project at PlateRecognizer — specifically the stream/ipro-adam-app module for on-camera deployment.

Here’s how to implement SPKI pinning using requests and urllib3.

Why SPKI over Certificate Fingerprint?

A cert fingerprint breaks every time the certificate renews. The public key stays the same. With SPKI pinning you get:

• Rotatable certificates without client updates
• Same attack surface as cert pinning — still prevents rogue CAs
• Future-proofing if you ever move to a different CA or HSM

The Implementation

import hashlib
from typing import Any

import requests
import urllib3
from cryptography import x509
from cryptography.hazmat.primitives import serialization
from requests.adapters import HTTPAdapter
from urllib3.connection import HTTPSConnection
from urllib3.connectionpool import HTTPSConnectionPool
from urllib3.poolmanager import PoolManager, ProxyManager


PINNED_KEYS = {
    "btwo.danleyb2.dev": {
        "b41ccc8c89282902cc4dbcbfff32323e8ffb098b0afb707f5935e2d75c7ce11a"
    }
}

Step 1: The Connection Class

urllib3 lets us swap in a custom connection class. We override connect() to extract the peer certificate after the TLS handshake, pull its public key, and compare it against our pin:

class PinnedHTTPSConnection(HTTPSConnection):
    def connect(self):
        super().connect()
        hostname = getattr(self.sock, "server_hostname", None) or self.host

        cert_der = self.sock.getpeercert(binary_form=True)
        cert = x509.load_der_x509_certificate(cert_der)
        spki = cert.public_key().public_bytes(
            serialization.Encoding.DER,
            serialization.PublicFormat.SubjectPublicKeyInfo
        )
        actual = hashlib.sha256(spki).hexdigest()

        expected = PINNED_KEYS.get(hostname)
        if expected is None:
            self.sock.close()
            raise requests.exceptions.SSLError(f"No SPKI pin configured: {hostname}")

        if isinstance(expected, str):
            expected = {expected}

        if actual not in expected:
            self.sock.close()
            raise requests.exceptions.SSLError(
                f"SPKI pin mismatch for {hostname} (sha256={actual})"
            )

Step 2: Pool Classes

We wire the custom connection into urllib3’s pool hierarchy:

class PinnedHTTPSConnectionPool(HTTPSConnectionPool):
    ConnectionCls = PinnedHTTPSConnection


class PinnedPoolManager(PoolManager):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.pool_classes_by_scheme = {
            "http": urllib3.connectionpool.HTTPConnectionPool,
            "https": PinnedHTTPSConnectionPool,
        }


class PinnedProxyManager(ProxyManager):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.pool_classes_by_scheme = {
            "http": urllib3.connectionpool.HTTPConnectionPool,
            "https": PinnedHTTPSConnectionPool,
        }

Step 3: The Adapter

The adapter bridges urllib3’s pools with the requests Session interface:

class PinnedHTTPAdapter(HTTPAdapter):
    def init_poolmanager(self, connections: int, maxsize: int, block: bool = False, **pool_kwargs):
        self._pool_connections = connections
        self._pool_maxsize = maxsize
        self._pool_block = block
        self.poolmanager = PinnedPoolManager(
            num_pools=connections, maxsize=maxsize, block=block, **pool_kwargs
        )

    def proxy_manager_for(self, proxy, **proxy_kwargs):
        proxy_str = proxy.url if hasattr(proxy, 'url') else proxy
        if proxy_str not in self.proxy_manager:
            manager = PinnedProxyManager(
                proxy_url=proxy_str,
                num_pools=self._pool_connections,
                maxsize=self._pool_maxsize,
                block=self._pool_block,
                **proxy_kwargs
            )
            self.proxy_manager[proxy_str] = manager
        return self.proxy_manager[proxy_str]

Step 4: Usage

if __name__ == '__main__':
    session = requests.Session()
    session.mount("https://", PinnedHTTPAdapter())

    # Optional — blocks proxies that do TLS inspection (MITM)
    session.proxies.update({
        "http": "http://0.0.0.0:8087",
        "https": "http://0.0.0.0:8087",
    })

    res = session.get("https://btwo.danleyb2.dev/api/v1/secure")
    res.raise_for_status()
    print(res)

Getting Your SPKI Pin

You can extract the pin from any server that’s already running:

import ssl, hashlib
from cryptography import x509

context = ssl.create_default_context()
conn = context.wrap_socket(ssl.socket(), server_hostname="btwo.danleyb2.dev")
conn.connect()

spki = conn.getpeercert(binary_form=True)
cert = x509.load_der_x509_certificate(spki)
pin = hashlib.sha256(
    cert.public_key().public_bytes(
        serialization.Encoding.DER,
        serialization.PublicFormat.SubjectPublicKeyInfo
    )
).hexdigest()
print(pin)  # your sha256 SPKI fingerprint

Caveats

• This pins to the leaf cert’s public key, not the full chain. If you have intermediate CAs with different keys, that doesn’t matter — only the server’s key matters for pinning.
• Never skip the pin in production. The code above raises on mismatch, which is correct. A verify=False approach defeats the entire purpose.
• You’ll want a fallback pin in your config so you can rotate without downtime — just add more entries to PINNED_KEYS[hostname].

Dependencies

cryptography >= 41.0.0
requests >= 2.31.0
urllib3 >= 2.0.0

The full working example is in my spki-pinning repo. Questions or improvements? Drop a comment below.

While taking a Bachelor’s in Electrical and Electronics Engineering from The Technical University of Kenya (graduating 2018), I realized something: I loved building things far more than analyzing circuits. The coursework gave me a technical foundation into Microprocessor systems, programming and simulation, internet database programming.

I pivoted. Hard. In the years leading up to graduation, what followed were marathon coding sessions on hobby projects in Java 7 and Python 2.7.

InterIntel Technologies (2016–2020)

My first real dive into professional development started at InterIntel Technologies in Nairobi as an Implementations Lead. The role was wide-open — there wasn’t one stack, so I learned them all.

• Built and maintained a progressive web application that processed payloads to render dynamic interfaces (the frontend to the company’s site generator, the core of InterIntel)
• Developed Native Android apps alongside Polymer-based web apps, both backed by Django DRF APIs running on CentOS 7
• Led the transition across two major versions of the frontend framework, and eventually drove the migration away from deprecated frameworks entirely — no framework at all, just vanilla
• Spearheaded the company’s tech stack setup on a new client’s on-premise datacenter (nginx, EMV processing, USSD systems)
• Pushed the team’s first Android app to the Google Play Store
• Championed better DevOps workflows: Git branching models, CI pipelines, documentation standards

The stack? Java, Python/Django, JavaScript, Polymer, Android, nginx, CentOS 7, USSD protocols, SQL. A true full-stack playground.

ParkPow / Plate Recognizer (2020–Present)

A contract role turned into something bigger — joining ParkPow (now part of Plate Recognizer) in California as a Software Quality Assurance Tester, working with Vision AI models and building integrations around them.

This is where I got deep into:

• Computer Vision & AI: Working with license plate recognition models (ALPR/ANPR), creating APIs and integrations
• Docker & DevOps: Built a PyInstaller-to-Docker extension for Docker Desktop, bridging desktop apps into the container ecosystem
• Integration development: Building sites, scripts, and APIs around vision AI models
• Contributing to the deep-license-plate-recognition codebase

Freelance & Parallel Work (2017–Present)

Running parallel to ParkPow, I’ve been a freelance developer taking on projects end-to-end:

• Salesleadgen — A leads generation web application I built and still maintain. Built with Python/Django, it scrapes LinkedIn and Sales Navigator data for lead prospecting.
• AMZ Top 16 — Tools for tracking Amazon best seller rankings across products
• Inventory Tracker — A Discord bot that monitors price drops on German shoe retailers and alerts users via Discord
• ABS R Android — An Android app tracking Amazon BSR (Best Seller Rank) for specific products
• EAD (Email Attachments Downloader) — An Android app that periodically downloads email attachments to a chosen directory
• Tumblr Poster — A Java Spring Boot desktop app with Selenium WebDriver to automate posting across multiple Tumblr blogs

Open Source Contributions

I believe in giving back. Here are some of my notable open-source projects:

And I’ve contributed to projects like Home Assistant integrations (EcoFlow Cloud, KPLC), Music Assistant documentation, Chiaki (PlayStation remote play client), and many others.

What I Build With Today

After nearly a decade in the trenches, these are my core tools and technologies:

• Languages: Python, JavaScript/TypeScript, Java, PHP
• Backend: Django, DRF, Express.js, Node.js
• Frontend: LitElement/WebComponents, Polymer, Vuetify, Materialize
• Mobile: Android (Java/Kotlin)
• DevOps: Docker, nginx, CentOS 7, CI/CD pipelines, Git workflows
• AI/ML: Computer Vision (ALPR), Vision AI model integrations
• Databases: PostgreSQL, MySQL, MongoDB, Realm DB
• Infrastructure: Linux, Kubernetes, Helm charts, Proxmox, Home Assistant

The Pattern

I’m also drawn to projects at the intersection of domains — automation + AI, mobile + web, DevOps + developer tooling. The interesting work lives in those overlap zones.

What’s Next

I’m continuing to work on Plate Recognizer’s vision AI integrations and exploring where Home Assistant, automation, and AI converge. There’s a lot more to build.

Enter Docker Desktop Extensions.

They let you build desktop-quality GUIs using modern web tech (React, Vue, whatever), run the heavy lifting in containers, and distribute them through Docker’s official ecosystem. No compilers, no cross-platform headaches, just docker compose up under the hood.

Why This Matters for Python Tooling

Many of the tools we build are CLI-first by nature. Plate recognition pipelines, data processing workflows, monitoring dashboards — they’re all perfectly fine from a terminal. But when you hand them to non-technical stakeholders, or try to demo them at a conference, “run this script” is not enough.

The traditional path:

1. Wrap the CLI in Gooey or tkinter
2. Install dependencies into a clean venv
3. Run pyinstaller --onefile and pray
4. Test on Windows, macOS, Linux separately
5. Maintain three installer chains forever

Here’s what that traditional path actually looks like:

# detect.py - A simple plate recognition CLI wrapped in Gooey
from gooey import Gooey, GooeyParser
import subprocess
import os

@Gooey(
    program_name="Plate Recognizer",
    description="Upload an image and get license plate data back"
)
def main():
    parser = GooeyParser()
    parser.add_argument("image", widget="FileDialog", help="Input image file")
    args = parser.parse_args()

    result = subprocess.run(
        ["python", "recognize.py", args.image],
        capture_output=True, text=True
    )
    print(result.stdout)

if __name__ == "__main__":
    main()

Then build it:

pip install gooey pyinstaller
pyinstaller --onefile --windowed detect.py

That’s the whole process. One command for the GUI, one command for the binary.

What works about this:

• Gooey auto-generates a window with file pickers, text outputs, etc. from your function signature
• PyInstaller bundles everything into a single .exe on Windows or a binary on macOS/Linux
• Works offline, no Docker required

What doesn’t work about this:

• The generated EXE is ~40-80MB even for trivial scripts (all of Python + stdlib bundled)
• Windows antivirus will flag it as suspicious 70% of the time
• macOS Gatekeeper rejects unsigned binaries instantly
• Linux requires matching glibc versions or it won’t run at all
• Every dependency update means rebuilding on every platform
• No built-in way to handle large models (onnx, torch, etc.) — they have to fit in your binary

Compare that to the Docker path: your Python tool stays in a lean container image (~300MB for heavy ML workloads due to pre-packaged runtimes), runs identically everywhere Docker is installed. For lightweight tools the container can be under 50MB.

The traditional installers ship every time you update; containers only need to pull delta layers.

The Docker Extensions path:

1. Build a web-based GUI
2. Wrap the CLI in a container
3. Publish to Docker Hub
4. Users run docker extension install yourname/app

One codebase. One binary. Every platform that runs Docker.

Docker Desktop Extension Architecture

A Docker Desktop Extension is deceptively simple. It’s composed of two main parts:

The UI (Companion App)

A web app — typically React, Vue, or Svelte — that renders inside a dedicated browser window in Docker Desktop. It communicates with the backend through Docker’s extension SDK, which exposes a JavaScript API for container management, CLI execution, and state sharing.

The Backend

A container (or docker-compose stack) that runs your actual tooling. For Python workloads, this is where PyInstaller binaries live, where heavy ML models are loaded, where Docker-in-Docker pipelines execute. The UI is just the window; the backend does the work.

The extension manifests tie them together:

{
  "desktop": {
    "companion": {
      "start": ["docker", "compose", "-f", "docker-compose.yml", "up"],
      "stop": ["docker", "compose", "-f", "docker-compose.yml", "down"]
    },
    "windows": [
      {
        "title": "My Tool",
        "startCommands": ["docker compose -f docker-compose.yml up ui"],
        "frontend": { "port": 3000, "path": "/" }
      }
    ]
  },
  "integration": {
    "cli": {
      "exec": {
        "name": "mytool",
        "command": "docker exec mytool-app mytool-cli"
      }
    }
  }
}

This gives you:

• Auto-lifecycle: Docker starts/stops your backend when the extension launches
• CLI injection: Your tool becomes available in any terminal as mytool without installing anything globally
• State sharing: Backend writes to $HOME/.docker/desktop-ext/mytool/data/, accessible by the frontend via API

Building One: The Practical Flow

1. Backend — Containerize your Python tool

FROM python:3.12-slim
RUN pip install --no-cache-dir plate-recognition-sdk flask
COPY . /app
WORKDIR /app
ENTRYPOINT ["python", "app.py"]

No PyInstaller needed. The container is the runtime.

2. Frontend — Web UI with Docker SDK

Using the official Docker Desktop Extension SDK:

import { Client } from '@docker/extension-api-client'

const client = new Client()

async function runDetection(imagePath) {
  const result = await client.docker.exec.run({
    containerName: 'app-backend',
    cmd: ['python', 'detect.py', imagePath]
  })
  return JSON.parse(result.stdout)
}

The @docker/extension-api-client package is the bridge between your React/Vue UI and Docker Desktop’s internals.

3. Extension Manifest

Place extension.toml or docker-extension.json in the root of your project. This file declares what Docker Desktop sees when a user installs your extension — window titles, icons, CLI bindings, permissions.

4. Packaging & Publishing

# Build the extension bundle
docker buildx build -t myname/myextension:0.1.0 .

# Push to Docker Hub
docker push myname/myextension:0.1.0

# Local install for testing
docker extension install myname/myextension:0.1.0 --target docker-desktop

Users then install it from the command line or Docker Desktop’s Extensions marketplace. No websites, no click-through installer wizards, no antivirus flags on PyInstaller binaries.

When This Makes Sense (and When It Doesn’t)

Good fit:

• Python tools that need a GUI for demos, stakeholder access, or non-technical users
• Tools with ML models, heavy dependencies, or Docker-native workflows
• Distribution across macOS and Windows without managing native installers
• Internal team tooling where Docker Desktop is already installed

Not a fit if:

• You need system-level integrations (file watchers, kernel modules)
• Your audience won’t have Docker Desktop installed
• The tool is genuinely simple enough for Gooey + PyInstaller in an afternoon

Final Thoughts

PyInstaller isn’t going away — it works for what it does. But if you’re building Python tools that need a GUI and you’re already comfortable with containers, Docker Desktop Extensions save an enormous amount of pain. One build, every platform, real dependency isolation, and an installation process that doesn’t look like malware from 2014.

The advantage is ecosystem integration — your extension can appear in Docker Desktop’s sidebar, hook into container logs automatically, share state with other extensions, and get installed through the same mechanism as any other Docker tool.

The future of desktop Python tooling might not be native binaries at all — it might be docker run wearing a React face.