Skip to content

Diun vs Portwing

Diun (Docker Image Update Notifier) polls container registries for new tags and fires notifications to 20+ channels. It is a monitoring/notification agent, not a remote Docker control agent — an adjacent product, not a direct general-purpose agent peer. Portwing is a remote access agent — it gives the Drydock controller a secure authenticated foothold on a Docker host. These tools are complementary: run Diun for registry monitoring and Portwing for remote Docker control from Drydock.

Diun — ActivePortwing — Supported pre-v1

Feature Comparison

Here's how we compare on the features that matter most.

FeatureDiunPortwing
Image update notificationsYes (multi-registry polling + 20+ notifiers)No (Drydock notifies; Portwing is the access agent)
Remote Docker API proxyNo (monitoring only, no remote control)Yes (full Docker API proxy with auth)
Auth for remote accessNo (local only)Yes (Ed25519 per-request signing)
Structured audit logNoYes (JSON, built-in)
Release artifact verificationNot evaluatedCosign signatures + CycloneDX SBOM + SLSA provenance
Default-deny socket filterNoYes (with sockguard)
Prometheus metricsYesYes
MCP server (AI-native, read-only)NoYes
Edge / NAT outbound tunnelNoYes (Drydock v1.6.0-rc.11+)
Single lightweight Go binaryYesYes (~10 MB)
LicenseMITAGPL-3.0

Key Differentiators

What we built that Diun doesn't cover.

Remote Auth (Ed25519)

Diun has no remote access model — it runs locally and pushes notifications outward. Portwing exposes the Docker API over authenticated HTTP with Ed25519 per-request signing so each client gets a revocable key pair.

Default-Deny Socket Filter

Portwing pairs with Sockguard to constrain Docker API calls at the socket layer. Diun can discover images through several providers, so its exact Docker socket exposure depends on deployment.

Structured Audit Log

Portwing logs every Docker API call it proxies as structured JSON for export to immutable storage. Diun has no audit trail beyond its own notification records.

Portwing Release Evidence

Portwing's own releases ship Cosign signatures, CycloneDX SBOMs, and SLSA provenance. This verifies Portwing artifacts; workload image policy remains a controller or admission-control responsibility.

MCP Server (AI-Native)

Portwing ships five read-only MCP tools for container and host inspection. Diun has no documented MCP support.

Complementary, Not Competing

Diun and Portwing solve different problems and run happily side-by-side. Diun monitors registries and notifies; Portwing gives Drydock secure remote control. You likely want both.

Using Diun today?

Diun and Portwing are designed to coexist. Deploy Portwing on any host where you want Drydock to have remote access; keep Diun running alongside it for registry polling and notifications. They mount the same Docker socket independently and don't conflict.

Quick start
$ docker run -d \
  --name portwing \
  --read-only --cap-drop=ALL \
  --security-opt no-new-privileges:true \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -e TOKEN_HASH="$PORTWING_TOKEN_HASH" \
  -p 3000:3000 \
  ghcr.io/codeswhat/portwing:latest

Ready to try Portwing?

Security-first, AGPL-3.0, no SaaS required. Drop a secure foothold on any Docker host in minutes.