EXTENSIONS

A declared fleet of base OCI images we keep security-patched. The whole job — what to patch (`source` = registry/repository/tag), how (`patch`, default: apply all pending security updates), where to publish (`destination` = repository/tag under a run-time `registry`), and what to assert (`expect`, optional version floor) — lives in the model instance's `globalArguments.images`, so a single `swamp model method run <instance> patch --input registry=<registry[/namespace]>` builds, verifies, and pushes every image. The destination registry is the `registry` arg (or `globalArguments.registry`), so one instance retargets to a different registry per run. No workflow. Verify is foreknowledge-free (asserts no security updates remain pending on every platform), which fits a scheduled cadence; an optional per-image `expect` adds a version floor. Composes the pure logic of @hivemq/oci/image/patch and the buildx wrapper of @hivemq/docker; it is the only one of the three that drives buildx. Motivated by PLT-941 (openssl CVE-2026-45447): own the patch cadence instead of waiting on upstream base rebuilds.

Google Cloud container infrastructure models

Build, run, and push container images via Docker, Podman, or Apple

Manage a Scaleway Container Registry namespace — sync state, create, update, and delete namespaces, and discover namespaces in a region, via the Registry API with X-Auth-Token auth.

Build, push, and inspect OCI container images. Registry-agnostic — works with ECR, GHCR, DockerHub, or any OCI-compliant registry. Supports docker, podman, nerdctl, and buildah. Produces typed, versioned build metadata.

Vaultwarden helper model for environment template discovery/rendering and HTTP health verification. Deployment and service management are handled by cfgmgmt extensions.

Take a single base OCI image identifier and emit its security-patched counterpart under the HiveMQ naming convention (<registry>/<namespace>/<flattened>:<tag>-hivemq-patched-<date>). A pure logic model (`plan` generates the security-upgrade Dockerfile + derives the re-homed target; `verify` asserts the expected fixed package versions) plus a bundled workflow that orchestrates a container CLI wrapper around it: plan, build the multi-arch image, verify the expected versions on every platform of it, then push. Two workflow variants ship: the Apple @hivemq/container engine (self-hosted macOS) and @hivemq/docker (standard Linux/GitHub-hosted runners). Motivated by PLT-941 (openssl CVE-2026-45447): own the patch cadence instead of waiting on upstream base rebuilds. Registry credentials are injected from a swamp vault at run time and never persisted in a committed instance.

Thin swamp wrapper around Apple's `container` CLI (a macOS container platform — Linux containers in lightweight VMs on Apple Silicon, no Docker daemon). Image-lifecycle subset: `build`, `run`, `image push`, `registry login` — each method mirrors a `container` subcommand so workflows can drive the build/run/publish lifecycle without bespoke shell steps. Verified against container CLI 1.0.0: no `manifest` subcommand, so a single multi-arch image is built with repeated `--arch` and pushed whole with `image push`.

Full minimega control via its command socket (or `minimega -e`), split into eight models — vm, vmconfig, namespace, network, cc, disk, mesh and host: VM lifecycle (launch/start/stop/kill, info, tags, net, screenshots), the launch config template, namespaces and the scheduler, networking (bridges, taps, VLANs, QoS, captures, router, dnsmasq), command-and-control (miniccc), disk images, the mesh/deploy fabric, and host/system ops (host, check, version, files, vnc, logging) plus a generic command passthrough.