Sensing & deployment · E59 · Implementation

Make a read-only service small by construction

A minimal Python image copies only the bridge implementation. Dependency boundaries can reduce operational capability as well as image size.

ContainerfilePython / pipZeroMQ / MessagePack
A narrow dependency and source boundary keeps the deployment inspectable, while runtime access controls remain separate.
Figure 1. A narrow deployment boundary. A narrow dependency and source boundary keeps the deployment inspectable, while runtime access controls remain separate. Declared container layers. Original vector illustration.

Follow the information

From input to outcome

The build context narrows what is packaged. Runtime policy still governs access and resource use: a small container alone cannot enforce every operational permission.

The build context narrows what is packaged. Runtime policy still governs access and resource use: a small container alone cannot enforce every operational permission.
Figure 2. Information flow. Solid arrows carry observations, tensors or artifacts; other routes are explicitly labelled. Signal shapes, matrices and network icons are schematic, not measured samples or literal neuron counts. Open full-size SVG ↗ On narrow screens, scroll the diagram horizontally.

Read this alongside Figure 1: A narrow dependency and source boundary keeps the deployment inspectable, while runtime access controls remain separate. The module map and layer-level figures below expand the operations in this route.

Make a read-only service small by construction: architecturePinned transport packages: pyzmq + msgpack → Limited source tree: Bridge code only → Python module entry: Explicit module at runtime → Read-only transport role: No broker client packaged → External runtime policy: Limits / credentials / network. A high-level module map; comparison branches and training details are explained in the article.SENSING & DEPLOYMENT / E59 / MODULE MAP01 INPUTPinned transport packagespyzmq + msgpack02 MODULELimited source treeBridge code only03 MODULEPython module entryExplicit module at runtime04 MODULERead-only transport roleNo broker client packaged05 OUTPUTExternal runtime policyLimits / credentials / network
Source-grounded module map. Boxes summarize operations, not individual neurons; comparison arms and training paths are detailed below. On a small screen, scroll the diagram horizontally.
Pinned transport packages — pyzmq + msgpack

The architecture in context

The system we are building

The Containerfile builds a narrow transport image rather than copying the entire application repository. It starts from a slim Python base, installs two explicitly versioned packages and copies only the bridge subtree. The intended read-only role is supported by excluding unrelated broker-client and execution code from the image.

Who does what in the stack

Containerfile
Defines a deliberately narrow build context.
Python / pip
Provides the module runtime and pinned direct packages.
ZeroMQ / MessagePack
Supply transport and serialization dependencies.

The project-specific contribution is the packaging boundary and module-entry convention. This is not a custom container runtime. A small image is easier to inspect and can help prevent accidental coupling between an observer and an action-capable service.

Framework responsibility map. Each row maps a library or custom component to its job; rows are not a sequential inference graph.
Framework responsibility map. Each row maps a library or custom component to its job; rows are not a sequential inference graph. Open full-size SVG ↗

Open up the implementation

Freeze the application boundary, not just pip names

A concrete operation-level view of this implementation; no unobserved neural architecture is implied.
A concrete operation-level view of this implementation; no unobserved neural architecture is implied. Open full-size SVG ↗

The container copies a narrow bridge module rather than the entire research workspace. This is a useful separation: a transport process should not require every notebook, dataset and training dependency to run. The module entry point defines the process boundary but does not establish live connectivity or production correctness.

The mathematical contract

reproducibleimage=basedigest+dependencyresolution+sourcerevision\mathrm{reproducible image}=\mathrm{base digest}+\mathrm{dependency resolution}+\mathrm{source revision}

Pinned top-level packages improve repeatability while leaving the base image and transitive resolution as additional sources of change. Model weights, feature schemas and endpoint configuration should be explicit external artifacts, not accidental files copied from a developer machine.

Implementation and resource card

Capacity / budget
Declared Python 3.12-slim, pyzmq 26.2.0 and msgpack 1.1.0. The base image tag is not pinned by digest.
Execution evidence
This revision inspects and explains the archived implementation. It does not rerun the original workload. No unrecorded convergence time, throughput or accelerator result is supplied.
Current reproduction context
Current workstation, supplied by the author: Apple M4, 128 GB unified RAM, 40 GPU cores and 16 CPU cores. This is context for prospective reproduction, not attribution of every archived run. Python and framework versions are not fully locked for these historical sources; declarations, when available, are identified separately.

From explanation to a reproducible check

Inspect the build context and image contents for unintended files, then test a local serialization round-trip without external endpoints. No container build, service deployment or broker connection is performed by this article.

Preserve input identities, configuration and failure records with the result. A successful numerical check only establishes the operation it exercises: it does not certify an entire dataset, model or deployed system. Reproduce the interface on a small deterministic input before optimizing throughput or increasing workload size.

A closer look at the implementation

The code that carries the idea

The excerpt pins pyzmq and msgpack versions, sets a working directory and uses an ENTRYPOINT of python -m. The runtime must supply the intended module name. The base tag is not a content digest, so the build is not fully immutable merely because the Python dependencies are pinned.

Containerfile · file · lines 3–12
FROM docker.io/library/python:3.12-slim

RUN pip install --no-cache-dir pyzmq==26.2.0 msgpack==1.1.0

WORKDIR /app
COPY src/bridge/ /app/src/bridge/
RUN touch /app/src/__init__.py /app/src/bridge/__init__.py 2>/dev/null || true

# Neither entrypoint can place an order: there is no code here that could.
ENTRYPOINT ["python", "-m"]

Verbatim archive excerpt from Containerfile.bridge. Context-dependent historical code, not a standalone runnable program. Comments retain their original wording; the article distinguishes implemented behavior from stale or overbroad comments.

The boundary that matters

Excluding action code does not prove a complete security boundary. Runtime mounts, credentials, network access, user privileges and the bridge code itself still matter. No image was built, service launched or production configuration changed for this article.

Keep building

Other posts of interest