OCI-first
OCI is the portable artifact contract. Docker, Podman, containerd, Kubernetes and OpenShift consume the same Lens artifact rather than requiring different product builds.
Hexjack Lens · Deployment
Your infrastructure. Your boundary.
Hexjack Lens is a deliberately small Go application with an OCI-first deployment baseline and supported native builds as a secondary path. Organisation-specific configuration and credentials remain outside the application artifact.
Deployment baseline
A small, independently deployable runtime.
The same Lens source revision produces the primary OCI artifact and supported native binaries. The OCI runtime is digest-pinned, uses exact Git and CA package versions, runs as a non-root user, keeps customer topology and credentials external, exposes local health/readiness/version checks and is verified under a read-only root filesystem with explicit writable cache state. PR and release workflows vulnerability-scan the built image.
External secrets
Lens resolves logical credential references at runtime, keeping credential material separate from both the application artifact and non-secret topology.
Native option
The controlled pipeline builds supported native Go binaries from the same exact source revision as the OCI artifact, with checksums, vulnerability evidence, signing and provenance.
One application
A portable deployment boundary.
The same Lens source and application boundary feeds OCI and native build paths. Customer-specific values do not require customer-specific application builds.
A container is packaging and runtime isolation, not a security claim by itself. Host, identity, network, secrets and orchestration controls remain part of the deployment security model.
Restricted environments
No mandatory Digital Unity callback is required to start or validate Lens.
CI proves local health, version, readiness and network-plan generation with networking disabled. Lens derives approved remote HTTPS destinations from trusted topology and rejects unconfigured HTTP targets before network I/O, giving operators a concrete plan for customer-controlled firewalls, proxies or equivalent egress policy. Local document sources and Unix analysis providers can require no remote TCP destination at all.
Standalone product
Lens is the gateway, not a Hexjack component.
Any compatible MCP client can use an independently deployed Lens instance. Direct source retrieval, optional local repository caching and delegated investigation are separate capabilities selected by configuration and deployment needs.
A Lens deployment does not require Hexjack Agent Control or a local Hexjack MCP. Optional Digital Unity workstation commands may wrap published Lens runtime checks for operator convenience, but the dependency never runs from Lens back into Hexjack.
Deployment choices
Keep control where it belongs.
Lens can fit customer-managed or managed-installation models while retaining the same fundamental separation between software, customer configuration and credentials. A hosted service would require its own explicit architecture for tenant isolation, credential custody and service operation rather than weakening those boundaries.
Operational boundary
Predictable runtime behaviour without creating a secondary data platform.
Operational audit is metadata-only, runtime work is bounded and cancellation-aware, and optional repository mirrors are disposable caches rather than authoritative stores. Credentials remain external runtime material and can be rotated without rebuilding the Lens artifact.
Local health, readiness, configuration and network-plan commands support operational verification without a mandatory Digital Unity callback or unrestricted Internet access.
Release verification
Verify the exact artifact before it enters the estate.
Official releases identify the OCI image by immutable digest and pair native artifacts with checksums, Sigstore verification bundles, CycloneDX SBOMs and signed provenance. The customer verification path supports connected environments as well as controlled transfer into restricted or offline estates.
Verification establishes artifact identity and controlled-build origin. Runtime IAM, network policy, secrets custody and host controls remain part of the customer's deployment boundary.