v0.4.1 docker-api-notifier release

Fixed

• DNS-only deployments no longer flood the log with a "Service Tracker
  Dashboard not enabled" line on every container, every refresh cycle.
  When STD_URL or STD_API_TOKEN is missing, the notifier now logs a
  single line at startup that STD integration is disabled, skips the
  periodic refresh loop entirely (it only ever served STD), and does
  not attempt STD dispatch on subsequent events.

Added

• New env var HOST_NAME_OVERRIDE. Sets the host name used as the DNS
  CNAME target (<host>.<dockerdomain>), overriding the auto-detected
  hostname. Useful in WSL or other environments where the host's
  hostname differs from the name your DNS entries should point at
  (e.g. Docker Desktop reports the LinuxKit/WSL VM name rather than the
  real host). Unset preserves the existing auto-detection behavior.

v0.4.0 Release

[0.4.0] — 2026-05-14

Added

• YAML interpreter mechanism (v0.4.0). The notifier now reads small
  YAML files that teach it how to interpret labels written by
  third-party tools (Traefik, Dockflare, ...) and forward them to STD
  as structured exposure observations on a new
  exposure_observations field. Two interpreters ship baked into the
  image (traefik.yml, dockflare.yml) and fire automatically for
  any container reported to STD — no opt-in label required. Operators
  who want to extend or override the built-ins mount a directory of
  their own YAMLs at /app/interpreters/user/; a user file whose
  name: matches a builtin overrides the builtin. Bad YAMLs log a
  warning and are skipped; the notifier continues with whatever
  loaded successfully. A new docs/community-interpreters/ directory
  holds contributed reference YAMLs (PRs welcome — they are examples,
  not curated products). Full format reference is in docs/PRD.md
  §11. Requires STD v0.6.0 or later; earlier STD versions reject
  the unknown exposure_observations key.
• Debug-only env var INTERPRETER_RELOAD_ON_EACH_EVENT. When truthy,
  re-reads the YAML interpreter directories on every dispatch instead
  of once at startup. For iterating on a YAML; not for production
  use.
• New env var STD_REPORT_ALL_CONTAINERS. When set to a truthy value
  (true, 1, yes — case-insensitive), the notifier reports every
  running container on the host to STD, regardless of whether the
  container has the dockernotifier.notifiers=service-tracker-dashboard
  opt-in label. Default off — existing per-container opt-in behavior
  is unchanged for operators who don't set the variable. Only STD
  dispatch is affected: the DNS notifier still requires explicit
  per-container opt-in via labels, because DNS records are an external
  side effect that shouldn't fire for containers that didn't ask.
  Unrecognized values (e.g. maybe) log a warning at startup and are
  treated as off. The wire payload to STD is identical whether the
  trigger came from a label or from this env var.
• STD payloads now include networks, exposed_ports, and
  published_ports read directly from the Docker API. networks is a
  list of {"name", "aliases"} objects, one per Docker network the
  container is on. exposed_ports is a list of "<port>/<proto>"
  strings from the container's ExposedPorts config. published_ports
  is a list of {"container_port", "protocol", "host_ip", "host_port"}
  objects, one per port binding. Empty values are emitted as explicit
  empty lists so STD can distinguish "nothing to report" from "not yet
  reported". No new env vars or labels — capture is automatic for every
  container reported to STD. Requires STD v0.6.0 or later; STD
  v0.5.x's strict validator will reject payloads carrying these keys.

Changed

• Design principles softened (v0.4.0). Previously, PRD §1.3 stated
  "no state" and "all configuration is via environment variables.
  There is no config file." Both are now narrower. The notifier still
  holds no per-event state and still has no central config file, but
  it now loads YAML interpreter files at startup. Operators upgrading
  from v0.3.x do not need to take any action — the YAML loader works
  out of the box with the two baked-in interpreters, and the
  filesystem footprint is fully contained inside the notifier
  container.

Fixed

• Docker event loop no longer logs Failed to handle <action> event for None: Resource ID was not provided errors. The container ID is now
  read from event["Actor"]["ID"] (newer Docker daemons no longer
  populate the legacy top-level id field), non-container events
  (network/volume/service) are filtered out before lookup, and the
  expected NotFound raised when querying an already-removed container
  on a destroy event is swallowed silently.

v0.3.0 - lots o backend bug fixes

docker-api-notifier v0.3.0

A cleanup release that aligns the notifier with Service Tracker
Dashboard's new register contract, consolidates shared infrastructure
across notifier modules, and lays the foundation for adding new
downstream targets cleanly.

Requires STD v0.5.0 or later

This release posts to STD's /api/v1/register endpoint using STD's
canonical schema. STD versions earlier than v0.5.0 do not expose
that endpoint and will return 404. Upgrade STD first, then upgrade
the notifier.

If you do not run STD, none of the STD-related changes affect you;
the DNS path is independent.

What's new

Aligned with STD v0.5.0's canonical register contract

The STD notifier now emits canonical key names and posts to
/api/v1/register. Translation from label-derived keys
(dockernotifier.std.group, dockernotifier.std.icon, ...) to
canonical wire-format keys (group_name, image_icon, ...) happens
client-side. Unknown keys are dropped before sending so STD's strict
pydantic validator does not reject the request.

Container labels are unchanged. Operators continue to use the
same dockernotifier.std.* labels in their compose files. The wire
format conversion is internal to the notifier.

Type coercion at the boundary

Health-check booleans and sort-priority integers are now coerced from
their string label values before being sent:

• dockernotifier.std.internal.health and
  dockernotifier.std.external.health → real booleans on the wire
• dockernotifier.std.sort.priority → real integer on the wire

This means STD finally receives the types its schema expects, instead
of relying on the legacy compat shim to coerce them server-side.

Common kwargs contract for notifier modules

Every notifier module's register() function now receives a
documented base set of kwargs (container_name, container_id,
docker_host, docker_status, image_name, stack_name,
started_at, action). Notifier-specific extras layer on top.

The contract is documented in docs/PRD.md §3.3.
notifiers/_template.py ships as a reference implementation for
anyone adding a new downstream target (Slack, ntfy, webhook, etc.).
Adding a new notifier is now a copy-and-modify operation rather than
a read-both-existing-modules-and-guess one.

Shared logging and retry across all notifier modules

Logging configuration moves into a single logging_setup.py module
consumed by main.py and every notifier. The retry policy moves
into a single retry.py module exposing a with_retry decorator.

The practical effect: the DNS notifier inherits retry on transient
failures (it had none before), and the next person to add a notifier
module doesn't reinvent either piece.

Better stack-name handling

When a container has no com.docker.compose.project label, the
notifier now passes stack_name=None rather than splitting the
container's name on _. The old fallback broke for any container
named my_thing_app that wasn't actually in a compose stack — it
got reported under a phantom stack named my. Fixed.

Operator-visible changes worth knowing about

These are not breaking — defaults preserve current behavior — but if
you've customized either of these, you'll want to adjust:

Single log-to-stdout env var

DNS_LOG_TO_STDOUT and STD_LOG_TO_STDOUT are replaced by a single
NOTIFIER_LOG_TO_STDOUT (default 1, console output on). The old
variables are no longer recognized.

If you previously set DNS_LOG_TO_STDOUT=0 or STD_LOG_TO_STDOUT=0
to silence one notifier's console output, switch to
NOTIFIER_LOG_TO_STDOUT=0 and you'll silence both. There is no
per-notifier toggle in v0.3.0; if that becomes a real need, raise it
as an issue.

DNS notifier now raises on HTTP 4xx/5xx from Technitium

Previously, an HTTP error response from Technitium was logged as a
success (with the error body in the log line). The notifier now
calls raise_for_status() and treats 4xx/5xx as failures, which
trigger the shared retry policy.

If your Technitium server has been occasionally returning errors
that you didn't notice because they looked like successes, you'll
now see retry attempts and clearer failure logs. If retries
ultimately fail, the event is logged as a failure rather than
silently lost.

DNS notifier "triggered for" log line content

The log line that used to read:

DNS notifier triggered for "myservice" due to "event"

now reads, accurately:

DNS notifier triggered for "myservice" due to "start"
DNS notifier triggered for "myservice" due to "boot"

If you grep logs or have alerting that specifically matches
due to "event", update those rules.

Settings additions

None. v0.3.0 adds no new environment variables that operators must
configure.

The internal NOTIFIER_LOG_TO_STDOUT consolidation (above) replaces
two existing vars with one; it is not an addition.

Looking ahead

Notifier v0.3.0 targets /api/v1/register exclusively. STD v0.6.0
will remove the legacy /api/register endpoint, at which point any
notifier deployment still on v0.2.x stops working against that STD
release. If you upgrade STD to v0.6.0 in the future, ensure all
your notifier instances are on v0.3.0+ first.

The notifier module contract (PRD §3.3) and reference template
(notifiers/_template.py) make this a good time to add a new
notifier target if there's a downstream system you've been meaning
to integrate. The shape is documented; the shared logging and retry
infrastructure is in place; adding e.g. a Slack or ntfy notifier is
mechanical.

Upgrade

docker compose pull
docker compose up -d

No data migration. No configuration file changes required for the
default case. If you had DNS_LOG_TO_STDOUT or STD_LOG_TO_STDOUT
set in your compose env, switch to NOTIFIER_LOG_TO_STDOUT.

The image is multi-arch (linux/amd64 and linux/arm64) so the
same tag works on x86 hosts and ARM-based devices.

Full changelog

See [CHANGELOG.md](https://github.com/crzykidd/docker-api-notifier/blob/v0.3.0/CHANGELOG.md)
for the complete list of changes, fixes, and removals.

v0.2.3

What's Changed

• Change notifier for std by @crzykidd in #13

Full Changelog: v0.2.2...v0.2.3

v0.2.2 fixed docker image lookup

Sometimes docker image would return a sha256 entry. Needed to look up the image name elsewhere.
Full Changelog: v0.2.1...v0.2.2

v0.2.1: Merge pull request #11 from crzykidd/crzykidd-updates-to-api

Everything the first version should have been.

First real release

What's Changed

• added Raspi support by @crzykidd in #9

Full Changelog: v0.1.5...v0.2.0

v0.1.5

What's Changed

• Crzykidd update notifier by @crzykidd in #8
• added ability to send healthcheck to service tracker

Full Changelog: v0.1.4...v0.1.5

v0.1.4

What's Changed

• updated readme by @crzykidd in #5
• update by @crzykidd in #6
• Crzykidd update status by @crzykidd in #7
• Monitors for container events like kill, start, die, etc. now and reports the latest version to the api.

Full Changelog: v0.1.3...v0.1.4

v0.1.3

What's Changed

• update readme by @crzykidd in #3
• Service tracker dashboard notifier by @crzykidd in #4
• added scan all containers on startup

Full Changelog: v0.1.2...v0.1.3