The most important recent changes are grouped here so you can quickly see what has changed in Dockge-Enhanced.

🆕 October 2026

Updates without service interruption : Enhanced starts and checks the new container before switching traffic and retiring the old one. Optional, disabled by default; requires an application that can safely run two copies temporarily, spare CPU/RAM, and Traefik or the proposed TCP relay. Initial setup, restarts, Recreate and rollback can interrupt access. Setup and precautions · Wowu/docker-rollout.

Native OIDC sign-in: Sign in with an OpenID Connect provider such as Pocket ID, Authentik, Keycloak or Google, without a reverse proxy and alongside local accounts and 2FA. Configuration uses DOCKGE_OIDC_* environment variables and the Authorization Code flow with PKCE. New OIDC users are restricted accounts with no access until an administrator grants it, unless they are listed in DOCKGE_OIDC_ADMIN_USERS or belong to DOCKGE_OIDC_ADMIN_GROUPS; with admin groups, the role follows group membership at every login. There is no implicit “first user becomes admin” rule: on a new installation, create the first administrator first or configure an admin mapping. Existing local accounts are linked only with DOCKGE_OIDC_LINK_EXISTING=true. OIDC logins do not ask for the local TOTP code, and OIDC is ignored in disabled and trusted-proxy modes. If you set DOCKGE_OIDC_DISABLE_LOCAL_LOGIN=true, keep the recovery procedure at hand. Guide.

Default Compose filename : COMPOSE_FILENAME selects compose.yaml (default), compose.yml, docker-compose.yaml or docker-compose.yml for new stacks only. Existing and adopted stacks keep their filenames. Other names and paths are rejected.

Socket.IO default ports : Browser origins using the implicit HTTP/HTTPS port now match an explicit :80/:443 Host header, including IPv6. Different hosts and non-default ports remain rejected; forwarded headers do not override this check.

CPU/RAM limits per service : Optional CPU/RAM limits per service in the administrator Compose editor. Existing aliases stay consistent; other resource settings and restricted-account permissions are preserved. Apply to the draft, then save and deploy explicitly. Inspired by Isurupro7 (Dockge #1006). A low RAM limit can cause an out-of-memory stop. CPU is throttled. Removing a limit does not reserve resources. Existing expressions are preserved until edited. Other resource settings stay unchanged. Overrides, extends or included files may still supply limits: review the final Compose. A prominent RAM warning requires acknowledgement before applying a new or changed memory limit.

Ignored images are respected: ImageWatcher rechecks Ignore after the registry check, before downloading and again just before recreating containers, including scheduled updates that were already selected and the managed Dozzle container. Stale manual-batch candidates are blocked too. A download already started may finish, but no recreation follows; a Docker recreation already running is not interrupted.

Restricted local accounts: In Settings → Security → Users and permissions, create restricted accounts and choose view, logs, start, stop, restart, update and recreate permissions separately for each local or linked stack. No selection means no access. Existing accounts remain administrators. The dedicated workspace exposes no Compose/.env, terminal, files, deletion, backups or settings. Update both ends of linked instances, including reverse agents; older agents have no bypass. Grants use the instance/stack-name pair: review them when reusing a name. Revocation disconnects sessions but does not cancel Docker operations already underway. Logs may contain secrets. Local authentication, with optional per-service grants covering all replicas across recreations. Restricted users manage their own password, TOTP and recovery codes; administrators can reset 2FA or delete only the account. Service actions that would affect network-namespace dependants are refused; delegated starts do not start dependencies. With trusted-proxy authentication, each proxy identity uses the local account with the same name; an unknown identity is created as a restricted account without grants, except the first user of a fresh installation and identities listed in DOCKGE_AUTH_PROXY_ADMIN_USERS. Technical details.

Compose defaults and remote agents: Named HTTP/HTTPS links, a configurable default .env template, persistent agent tags and tag filtering, plus optional reverse agent connections with per-node tokens and automatic attachment after local account setup. Reverse agents belong to their hub; inter-server data transfers still require direct federation. An existing local administrator account is sufficient; no new account is needed. Documentation.

Port links: Choose Hostname or IP address for container port links in Settings → General. Each linked instance keeps its own choice; the existing default is preserved. Hostname mode prioritizes Primary Hostname, falling back to the browser/agent address. IP mode supports automatic IP selection or an explicit reachable IPv4/IPv6. If no IP is known, the badge remains visible without a link, with an explanatory tooltip. Configure each hosting instance separately and update both sides to use this preference through federation; older agents retain their previous behavior. Docker port bindings, DNS and stored hostnames are unchanged.

TLS security and security updates: Update image trust stores and TLS components following the eMudhra incident. Checks cover the compromised chains, including both No CT cases, and a valid HTTPS connection. Running images remain unchanged: schedule their replacement after validation. The image also moves to Node.js 26.12.1 for the October 2026 Node.js security releases, and follow-redirects and the bundled Restic build receive dependency security fixes. Incident details · TLS checks

Compose checks and Home Assistant: Advisory port-conflict checks before saving/deploying, including resolved variables, overrides and ranges; running-image reference comparison with a reviewable YAML correction. Optional Home Assistant custom integration with state sensors and permission-scoped start/stop/restart controls. Guide.

Instance / Global: Home: local statistics first, then global totals independent of stack filters. Expand each summary card for per-instance values and direct menu links. Offline or older instances are marked unavailable; backup coverage distinguishes disabled instances.

Service status for discovered stacks: Discovered but unadopted Compose projects such as DDEV no longer trigger repeated spawn docker ENOENT errors when their directory is absent from the stacks root. Adopted external stacks use their registered directory, project name and Compose files for service status.

Optional TOTP two-factor authentication: Enable Settings → Security → 2FA Settings with your current password, scan the QR code and confirm an authenticator code. Save the ten single-use recovery codes; they are shown only once. Activation is off by default and applies to local sign-in, not trusted-proxy authentication or federation tokens. Linked instances must use federation tokens before enabling 2FA; password-only connections will no longer work.

Keep the entire /app/data directory in backups, including two-factor.key. A database-only restore cannot decrypt the authenticator secret without this key. If both the authenticator and recovery codes are lost, an administrator with container access can run ./node_modules/.bin/tsx ./extra/reset-two-factor.ts --username ACCOUNT --confirm from /app, then restart Enhanced; the password remains unchanged.

CPU/RAM history by Compose service: Enable recording in Monitoring, then open Resource usage in a stack's actions. The compact charts show the stack total and one history per Compose service, including unmanaged Compose projects. Updates and container recreations remain in the same service history; simultaneous replicas are summed at each sample before averages and maxima are calculated. Existing measurements are preserved without a reset. Ranges: 24 hours, 7 days, 1 month, 1 year or all recorded data. Recording is disabled by default and samples every 5 minutes without an open browser. CPU: 100% = one core; Linux RAM excludes reclaimable cache. Gaps remain visible and peaks between samples can be missed. Stack totals exclude native host processes and containers outside Compose. CPU/RAM sorting remains available in the stack list.

Zerobyte backups: connect an existing instance or install a dedicated Compose instance from Backups → Zerobyte. Use it alongside native Restic backups or for your scheduled backups, with separate repositories. Guided setup, protected application stop/restart workflows, storage checks, dedicated test restores and read-only multi-server status are available. If network storage is unavailable, backups stop without a local fallback. Setup and recovery guide.

Prevent Restic from backing up its own repository: when a local repository is inside a selected backup folder, Enhanced warns you and excludes it automatically. For example, /app/data can remain selected with a repository at /app/data/backups. Selecting the repository itself or one of its subfolders as a source is refused. Existing paths, passwords and retention settings are preserved.

Optional per-service healthcheck assistant: Click Configure healthcheck on a service when viewing an existing stack or creating a new one. The assistant proposes a local HTTP URL or TCP-port check based on its internal Compose ports. Review or change the target and exact command before adding it to the YAML; existing healthchecks are never replaced automatically. Docker runs the check inside the image, which must provide /bin/sh and curl/wget or nc. Verify the health status after deployment; a successful TCP connection does not prove application readiness.

In Compose edit mode, Healthchecks is also available in the stack action bar. Choose a service if the stack has several.

Updates and ImageWatcher

Scheduling timezone and optional container TZ: Choose the Scheduling timezone in Settings → General. It controls this instance’s stack start/stop schedules, image-update times, self-update windows, native Restic and security-scan crons. Without an explicit choice, the existing runtime timezone is preserved; saved clock times are not rewritten. Linked instances and external backup tools such as Zerobyte keep their own settings. Relative intervals, pause deadlines and retention are unchanged. DST follows the selected zone: a missing local hour is not guaranteed to execute, and a repeated hour may occur twice; prefer a time outside the transition, such as 04:00.

In a stack’s edit actions, Container timezone offers an option off by default to add TZ to the Compose draft and override. Existing values (including inherited values or env_file/extends) require confirmation. Review the YAML, save and recreate/deploy to apply it. Images must support TZ; source .env/env_file files are not changed, and future global timezone changes do not automatically rewrite or recreate stacks.

Image update notifications: Discord and Apprise announce a pending image update only once per stack, image and remote digest, including updates waiting for a scheduled window. This tracking survives Enhanced restarts. A new digest is announced again; automatic update results still generate their own notification. Failed deliveries are retried on subsequent checks independently for each Discord webhook and the configured Apprise destination.

Stopped services stay stopped: automatic image updates are deferred when any targeted Compose service (including a required network-namespace companion) is stopped or absent. ImageWatcher checks again after pulling, before recreation, and retries on a later check. It does not use compose up to wake a stopped service.

Image check intervals: In Watcher > Images, the full scan covers all images every 6 hours by default. Immediate-mode images also receive separate targeted checks every 5 minutes by default. You can set that targeted interval in minutes or hours (5 minutes to 24 hours), or disable only those periodic targeted checks; the full scan remains active. The selected Immediate policy can still trigger a one-off targeted check.

Host bind preparation on macOS

Before starting or updating a stack, Enhanced asks Docker to prepare each directory bind source directly. This also works with paths shared by Docker Desktop on macOS, such as /Users/..., without assuming that the helper can see the macOS filesystem through a bind mount of /. File binds such as /etc/localtime are not created as directories. If Docker cannot access a source path, the update stops with Docker's actual error; check that the directory is shared with Docker Desktop.

Self-update disk space and old image retention

Before backup or pull, self-update checks free space on the Docker daemon's storage filesystem. Automatic updates are deferred if the check fails or space is insufficient; manual updates stop with an explanation. A vanished updater is detected at any stage, while a target-image pull still running after 20 minutes is flagged for inspection without pretending it has stopped. After a successful update, unused Enhanced images pulled by digest are checked daily and may be removed once they are at least 48 hours old. Active, rollback, recovery and explicitly excluded images remain protected; this does not enable general image auto-prune.

Safer coordination between ImageWatcher and Self-Update

Read-only registry and DNS checks no longer delay Dockge-Enhanced self-updates. Image updates, rollbacks and rollback-tag cleanup that change Docker now share an exclusive reservation with Self-Update, so conflicting operations are deferred instead of overlapping. A scheduled self-update does not block image updates unnecessarily; persisted self-update state continues protecting the detached updater after restart. The Updates panel prioritizes an active self-update over a stale availability check.

Bulk automatic image policies for a stack

A stack page now supports applying Off, Immediate, or Scheduled policies to all eligible images at once. A preview lists changes; users choose to preserve individual exceptions (the default) or replace them. Services excluded through dockge.imageupdates.check=false remain protected, shared images are deduplicated, and linked instances use the same server-side validation. Future images are not automatically affected.

ImageWatcher: faster and more reliable immediate updates

For images set to Immediate, ImageWatcher performs a targeted check when the setting is enabled and then every 5 minutes, without increasing the global scan frequency. When several stacks share the same :latest image, Enhanced checks the image actually running in each container, rather than just the local tag: a service still running an older version is no longer incorrectly marked up to date. Registry requests for identical images are shared, HTTP 429 rate limits trigger a cooldown, and targeted checks are summarized in the logs. Pauses, maintenance windows, and rollback safeguards still apply.

Per-service status and image-update exclusions

The visual Compose editor can add dockge.status.ignore: "true" so an optional service no longer degrades the overall stack status after deployment, while its own state remains visible. It can also add dockge.imageupdates.check: "false" to exclude a service from ImageWatcher checks and automatic or batch image updates. An explicit service update remains available. Existing service labels and YAML label syntax are preserved. Inspired by hamphh/dockge.

Update all available container images

The Updates page can update detected images one at a time using the existing Compose update and rollback path. It shows progress, stops on the first failure and leaves Dockge-Enhanced self-update separate.

ImageWatcher diagnostics and metadata (#493–#495)

The Images view can sort errors first. Transiently unreachable targets are preserved, manifest timeouts use bounded retries, registry/authentication/digest errors are clearer, and stack timestamps change only after a confirmed applied update.

Stack update controls and image action buttons (#489–#490)

The stack-wide automatic update policy now opens from the stack action bar in a modal; individual container controls remain unchanged. Image update, ignore, pause and rollback actions use compact buttons with accessible labels.

Optional DNS fallback for registry checks

Under Watcher > Images > Fallback DNS, you can enable application-scoped DNS fallback (disabled by default), add/edit/remove IPv4 or IPv6 resolvers, and test A and AAAA queries with response times and diagnostics. System DNS is always tried first; fallback is used only for DNS resolution failures in supported ImageWatcher HTTP registry/token requests. The initial examples are Quad9 (9.9.9.9, 2620:fe::fe) and Cloudflare (1.1.1.1, 2606:4700:4700::1111), and are fully customizable. Existing saved settings are preserved. No host or Docker Engine DNS setting is changed; Docker Engine pulls and self-updates are outside this fallback.

Self-update through Docker Socket Proxy

The self-update checker and updater sidecar follow the Docker endpoint actually used by Enhanced: a Unix socket (including DOCKGE_DOCKER_SOCKET) or DOCKER_HOST=tcp://… behind a trusted Docker Socket Proxy. In TCP mode no placeholder socket is mounted; the sidecar is attached to the instance's Docker networks before it consumes the signed plan. See the protected update workflow for the permissions the proxy must allow.

Backups, cleanup and reliability

Faster, race-safe Docker image cleanup

Bulk image cleanup now scans the Docker inventory once, then revalidates only the target image immediately before each docker rmi. The Resources page no longer runs a giant docker image inspect just to display the image list, image inspection is bounded in batches and tolerates an image disappearing during a concurrent cleanup, and expired rollback cleanup uses the same Docker-cleanup lock. Existing container, rollback/recovery and grace-period protections remain in place.

Cleanup now uses Docker's real image references

Unused-image cleanup no longer assumes that the Repository:Tag shown by docker images is an attached, removable reference. It uses the inspected RepoTags and RepoDigests, removes every required reference, then safely falls back to the Image ID when necessary and verifies that the physical image disappeared. Container use, exclusions, active Enhanced, recovery, rollback and grace-period protections remain enforced.

Prune reports now match Docker's observed state

When a batch inspection does not return an image, cleanup now checks that Image ID directly before calling it absent. Every deletion is checked again, then a final lightweight Docker inventory verifies the reported result. Resources now shows Docker usage separately from prune state: an unused image may still be active Enhanced, protected for recovery or rollback, too recent, or excluded. Untagged images are described neutrally as Untagged image, not as old images. The workflow remains bounded to one initial inventory, targeted checks, and one final light verification.

Reliable cleanup of old Dockge-Enhanced images

Old ghcr.io/aerya/dockge-enhanced: images are now selected from Docker's image inventory instead of depending on RepoDigests metadata that may be missing after retagging. Images older than the 48-hour self-update safety floor can therefore be pruned reliably, while the active image and recovery-protected images remain untouched. Unused-image summaries also stop counting ordinary container-used images as protected cleanup candidates.

Unused repository: images are now actually pruned

Docker may keep an image repository name while its tag becomes . Those images previously fell between the dangling (:) and tagged-unused cleanup paths, so buttons and scheduled cleanup could leave them behind indefinitely. They are now handled as unused images by Image ID, while container use, exclusions, rollback/recovery protection and cleanup grace periods are still enforced. Old Dockge-Enhanced images keep their additional 48-hour self-update safety floor.

Per-image cleanup age for old Dockge-Enhanced builds

Old ghcr.io/aerya/dockge-enhanced: images pulled by digest now age out independently. A new successful self-update no longer resets the 48-hour cleanup clock for every older Enhanced image: each stale image is evaluated from its own creation time, while the active image and recovery snapshots remain protected. If unified Docker cleanup uses a longer grace period, that larger value still takes precedence.

Unified Docker cleanup and exact catch-up scheduling

Docker Resources shares one Image-ID inventory between the Images page, cleanup preview and pruning. The same grace period applies to manual and automatic cleanup, multiple tags for one physical image count only once, and images that disappear concurrently are treated as already absent rather than as cleanup failures. Stopped-container images and rollback/recovery assets remain protected. Images, networks, volumes and build cache can be selected independently, results are recorded per category, and due jobs are checked every 15 minutes with one catch-up after sleep or restart. Enabling unified cleanup suspends the legacy image schedules without erasing them.

Restic setup feedback and safer initialization (#491)

Backup settings, run-now and maintenance actions are separated; repository state and retention help are clearer, and initialization uses safer safeguards.

English backend messages (#477)

Restic password errors, prune audit summaries and automatic update messages are no longer incorrectly displayed in French in an English installation.

Healthcheck with an HTTP proxy configured

The built-in container healthcheck ignores proxy variables and queries 127.0.0.1 directly, so a configured or unreachable proxy no longer marks Enhanced unhealthy. Other network access keeps using the configured proxy.

Monitoring and integrations

Optional PowerWatch electrical monitoring

PowerWatch can now be connected in External mode, which only reads an existing local container or HTTP(S) endpoint and never controls it, or deployed in Managed mode as a real Compose stack. Managed installation detects the host's RAPL, MSR and NVIDIA capabilities, enables only the required access, never uses privileged: true, and keeps history and settings in a persistent volume when stopped or disabled.

Current whole-machine power, confidence and a direct WebUI link appear in Monitoring, the system status bar and compact linked-instance summaries through the existing federation channel. The status bar and instance cards display only the watts next to the electrical icon; the tooltip identifies PowerWatch and its measured or estimated confidence. PowerWatch measures or estimates consumption according to the available sensors.

Optional monitoring services: Kula, Dozzle, PowerWatch and Hub

In Monitoring (/watcher/monitoring), the four optional third-party services appear in separate, consistent cards, with brief descriptions and links to their GitHub repositories. PowerWatch and its Hub each offer independent external/managed modes, installation, start, restart, stop and connectivity test. Managed Hub uses the PowerWatch image's powerwatch-hub binary, defaults to 127.0.0.1:3065, and stores its data in a dedicated persistent Docker volume.

A Hub can run without a locally managed PowerWatch. Instances reachable only through an individual host's 127.0.0.1 are not automatically accessible from the Hub's Docker container; configure a reachable, protected endpoint for federation. PowerWatch now offers optional native authentication, disabled by default, with read-only Bearer API tokens. Enhanced now supports these read-only Bearer API tokens for querying protected PowerWatch instances. Enter the token in Monitoring → PowerWatch → Read-only API token. The saved token stays masked and is never forwarded to the Hub. The Hub separately supports an optional token for administrative operations. Never expose an unprotected interface publicly.

To connect an existing PowerWatch, enter the usual WebUI address (for example http://192.168.0.64:3064) in the PowerWatch URL field: Enhanced automatically requests /api/snapshot on the same origin. A separate WebUI address is only needed for unusual reverse-proxy setups and remains available in advanced settings. An existing Hub likewise needs only its WebUI address; Enhanced calls /api/hub/snapshot automatically.

Optional host CPU/RAM history

Monitoring can record one lightweight host CPU/RAM sample every 5 minutes, independently of browser sessions. The responsive SVG graph offers 24-hour, 7-day, monthly and custom ranges; the selected display range can be saved and restored on the next visit. Long ranges are downsampled server-side and downtime remains visible as gaps. Recording is disabled by default and low-power mode does not stop it when explicitly enabled.

The optional CPU/RAM history keeps its real sampling gaps but uses a more compact PowerWatch-inspired chart with lighter grid lines and subtle filled areas.

Stacks, interface and usability

Directly accessible stack actions

Every stack action is available directly in the action bar, without submenus, in visually separated groups that wrap to the available width. Icons-only and icons-and-text modes keep their tooltips; commands, availability conditions and confirmations are unchanged.

German interface

The interface and release news are available in German, with German README and changelog. Discord and Apprise notifications fall back to English when German is selected.

Container counters on the home page

The home page shows running, stopped and paused containers, including reachable linked instances. Stack and container counters follow the instance filter of the stack list.

Safer stack starts and immediate image checks

Enhanced prepares missing absolute host bind directories before start/deploy/recreate operations when the mount is clearly directory-like. This is especially useful on NAS hosts such as Synology where Docker refuses a bind source that does not exist yet. File-like bind sources are never auto-created as directories. Per-image Immediate auto-update now starts a targeted image check as soon as the policy is saved. Successful stack restarts also refresh the real stack state and hide stale Compose progress output.

Cleaner Compose volumes and logs

Mounted volumes and actual containers use compact rows instead of full-width clickable bars. The Logs panel stacks its three filters, groups its actions and places search last; filter names remain available to assistive technology. Appearance settings can enable log timestamps by default for this browser.

Day and night color palettes

Appearance settings now offer separate palettes for light and dark mode: four day choices and eight night choices, including the original themes. Catppuccin, Nord, Solarized, Dracula, Gruvbox, Tokyo Night and Rosé Pine recolor the page, header, panels and controls; the selected palettes are remembered in the browser, and Auto still follows the system theme.

Reliable linked-instance connections

Adding or changing a linked instance now refreshes browser sessions without disconnecting federation sockets. Both instances remain connected after mesh synchronization and after a restart.

Password managers

Account setup now labels the username and new-password fields for browser password managers.

Stack controls and Compose creation

Stack pause/resume freezes containers without removing volumes. Automatic image updates wait while a stack is paused; pause/resume is blocked during Restic backup or restore, and pause is unavailable for Enhanced's own stack or stacks using stop/hook backup policies. General settings now provide a validated default Compose template for new stacks only. The stack README.md opens from an action button instead of a full-width bar, and container action icons have explanatory tooltips. Existing tmpfs octal-value protection and Compose variable highlighting remain unchanged.

Clearer stack actions

Stack buttons now explain what they run. A help panel shows the actual Docker Compose commands for the selected stack, including its project and Compose-file options, with links to Docker's documentation. The former “Stop & Inactive” button is now “Take down stack”: it runs docker compose down after confirmation, removing containers and Compose networks but not named volumes, bind-mounted data, Compose files or images. Anonymous volumes may not be reattached on the next up.

Display names for stacks

Give a stack a WebUI display name from its stack page. Its technical name, Compose project, backup selection and restore path remain unchanged; the technical name stays visible beside the alias.

Real container view

Each Compose service now lists its actual containers separately, including replicas. Open one to see its state, health, image, ports, resource usage and recent logs, or start, stop and restart that exact container. Service-wide actions remain unchanged. Inspired by Lorwell/dockge.

Optional host file manager

An opt-in Files page can browse a dedicated host directory, edit small UTF-8 files, transfer files and follow file-based logs, locally or through a linked Enhanced instance. It is separate from the per-stack volume browser and cannot access paths outside its configured root.

Mount only the directory you intend to expose at the same path inside Enhanced and set DOCKGE_FILE_MANAGER_ROOT to that container path. For example, add - /srv/shared:/managed-files under volumes: and DOCKGE_FILE_MANAGER_ROOT: /managed-files under environment:. Without this setting, the manager stays disabled; do not mount / or a broad host directory. It also refuses operations when authentication is disabled. The optional DOCKGE_FILE_MANAGER_MAX_FILE_SIZE limits transfers (default: 100 MiB); online text editing is limited to 1 MiB. Each linked instance needs its own explicit mount and setting.

Copy and paste in container terminals

Right-click now opens the terminal’s native Copy/Paste menu. Pasting also works with keyboard shortcuts on local HTTP addresses, without requiring access to the browser Clipboard API.

README.md for managed stacks

The stack page can display and edit a Markdown README.md stored beside its Compose file. This file is distinct from the short stack note and follows a stack copied or moved to another Dockge-Enhanced instance. External stacks are not edited by this feature.

🆕 September 2026

Reliable automatic image cleanup

Automatic cleanup no longer skips the next scheduled slot when a previous run finished a few seconds late. Tagged images referenced by any container, including stopped containers, and rollback images are preserved. Old Dockge-Enhanced images pulled by digest become eligible at the next cleanup at least 48 hours after a successful self-update; the active image and recovery images are kept. Docker errors from the most recent cleanup are shown in Docker Resources.

Federation availability alerts without overnight spam

Circuit-breaker availability notifications are now tied to a continuous outage episode: each linked instance sends at most one alert while a peer remains offline, and the alert is re-armed only after that peer successfully authenticates online again. Each remote instance can also be marked locally as Intermittent machine — do not alert when unavailable. This is intended for desktops, laptops and other peers that are routinely powered off or suspended; automatic reconnects, backoff and circuit-breaker protection remain active. Because the preference is local, mark the intermittent peer on every always-on Dockge instance from which you do not want availability alerts.

Process-wide federation transport

Federation now uses one shared outbound transport per Dockge-Enhanced process instead of one connection set per WebUI socket. Linked instances are loaded from SQLite and connected automatically when the server starts listening. Opening several WebUIs no longer multiplies remote sockets, closing the last browser no longer disconnects linked instances, and the circuit-breaker retry continues after about 5 minutes even with no WebUI open. Credential changes, mesh repair and peer removal immediately resynchronize the shared transport.

Federation reconnect-storm hardening

Federated sockets now use a lightweight authentication path and no longer execute the WebUI stack/agent bootstrap. Socket.IO reconnects are explicitly bounded with exponential backoff, jitter and a 5-minute circuit breaker. Excessive inbound federation handshakes are rejected before authentication and simultaneous inbound federation sockets are capped. If a reconnect guard trips or SQLite/Knex contention is detected, the existing Discord/Apprise configuration emits a rate-limited alert without querying SQLite.

Network namespace-safe targeted updates

Targeted image updates, service recreations and image rollbacks now resolve the complete Compose model before replacing a container. When other services share its network namespace through network_mode: service: or network_mode: container:, every direct and transitive consumer is force-recreated with the provider in one targeted Compose operation. Unrelated services are left untouched, while VPN, Gluetun and sidecar stacks no longer retain a removed container's stale network namespace.

External stacks (Beta)

Enhanced can detect existing Docker Compose projects, adopt them without moving their Compose/.env or data, and then manage them from the normal stack UI. If a source path is not yet available inside Enhanced, protected one-click authorization patches Enhanced's own Compose automatically. Adopted stacks keep their project name without a redundant external- prefix and are marked External; source-file deletion requires an additional explicit confirmation. The scanner also maps Enhanced's stacks directory to its host-side bind mount, so stacks already managed by the instance are excluded even when Docker Compose labels contain host paths.

When permanent source deletion is selected, Enhanced now removes the source bind and allowlist entry from its own Compose through the protected helper, recreates only its own container, and then deletes the host folder. This avoids EBUSY failures caused by trying to remove a directory that is still one of Enhanced's mount points.

A supported example is Gluetun-Companion: it may recreate an Enhanced-managed Gluetun stack from a bind-mounted /compose path. Enhanced now resolves this kind of Compose path alias back to the managed stack and does not offer it for external adoption.

Anonymous installation count

To get an approximate number of active Dockge-Enhanced installations without running a separate analytics service, Enhanced downloads a tiny technical asset from a dedicated GitHub release at most once per month. GitHub's public download_count for that monthly asset is the only aggregate used for the count.

No installation identifier is generated or sent for this count. The request contains no hostname, instance name, stack, container, Docker image, configuration, path, GitHub account, email, architecture or build identifier. As with any GitHub asset download, the connection itself is handled by GitHub; Dockge-Enhanced does not receive or store installation IP addresses.

The already-counted month is stored only in the local data directory so the same installation downloads the asset at most once per month. Counting is enabled by default and can be disabled with DOCKGE_USAGE_COUNT=false. Recreating or deleting the data directory can make the same installation count again for the current month, so the figure is intentionally approximate.

The mechanism is fully public: Enhanced-side code, GitHub workflow that creates the monthly assets, and aggregate monthly counters.

Repository owners can add an Actions secret named USAGE_COUNT_DISCORD_WEBHOOK to receive a provisional count every Monday and the final count for the previous month on the first day of each month. The workflow can also be run manually to send the current count immediately. The webhook value remains encrypted by GitHub and is never committed to the repository.

Global multi-instance search V2 (Ctrl+K)

The global palette now supports fuzzy matching for small typing mistakes and assisted operators such as type:, stack:, image:, port:, instance: and operational filters including is:update, is:stopped, is:vulnerable, is:critical and is:backup-failed. Operator chips are displayed directly in the palette so the syntax does not need to be memorized. Compose and .env results open the matching stack and scroll CodeMirror directly to the matching line. Recent searches and pinned searches are stored locally in the browser.

Historical configuration search in recent Restic snapshots can be enabled explicitly from the palette; it is bounded to 5 recent snapshots and 80 Compose/.env files per instance to protect remote repositories. Searching inside .env values is also an explicit opt-in: values are used only for matching, are never returned/displayed, and while this sensitive mode is active the query is never stored in recent or pinned searches. Linked instances use the V2 agent protocol when available, with a V1 fallback for simple searches on older linked instances.

Automatic self-update protection while editing Compose/.env

When a compose, override or .env file has unsaved changes in the WebUI, the owning Dockge-Enhanced instance temporarily blocks its automatic self-update — including edits opened from another linked WebUI. The editor keeps a short-lived heartbeat lease so stale browser sessions expire automatically. If an update becomes ready while unsaved work is present, the user gets a dialog to save and update, defer for 30 minutes, defer for 1 hour, or keep working. The backend re-checks blockers again before preparing and launching the updater sidecar so an edit started during backup/verification cannot be interrupted by the restart.

Linked-instance overview on the home page

The existing agent panel on the home page now doubles as a compact infrastructure overview. Each linked Dockge-Enhanced instance shows its stack totals and states, host CPU/RAM usage, uptime and pinned-stack count while keeping the existing rename, reauthentication, removal and add-agent controls. Clicking an instance summary filters the stack list on the left to that server; clicking it again restores the all-servers view.

Per-stack CPU/RAM stats across linked instances

The Show CPU / RAM statistics per stack option is now owned by each Dockge-Enhanced instance. When enabled on a server, that server collects its own Docker statistics and exposes them through the existing linked-instance channel. Every linked WebUI displaying that server shows the same CPU/RAM badges for its stacks and containers. Hiding the server hides its statistics; disabling the option on the owning instance stops collection and exposure for that instance.

Server-persisted pinned stacks across linked instances

Pinned stacks are now owned by the Dockge-Enhanced instance that hosts them instead of by one browser's localStorage. Pinning a stack on Garuda, DockerLab or LincStation stores that preference on the corresponding server. Any linked WebUI that displays that server sees the same pinned stack; hiding that server hides its pins without deleting them. Pins therefore survive logout/login, browser changes and Dockge-Enhanced updates. Existing browser-local pins are migrated automatically when their owning instances are reachable.

Dedicated self-update backup retention

Mandatory Restic snapshots created before protected Dockge-Enhanced self-updates now use a dedicated retention policy. After the new snapshot has been created and verified, Dockge-Enhanced keeps the 2 latest self-update snapshots for this installation and prunes older generations before launching the updater sidecar. A stable installation-specific tag prevents cleanup from touching another Dockge-Enhanced instance sharing the same Restic repository. Normal backup retention (keepLast, daily, weekly, monthly) is unchanged. If this dedicated pruning fails, the verified backup is kept and the update may continue; the cleanup error is logged and a later self-update will try again.

Docker Compose project-name reconciliation

Managed stacks whose directory name contains dots or uppercase characters are now reconciled with Docker Compose using the actual ConfigFiles path instead of relying only on Docker's sanitized project name. This prevents duplicate “managed/stopped” and “external/running” entries for the same stack.

Compose long port syntax support

Container cards now support both short and long Compose port syntax. Definitions using published, target, protocol, mode or host_ip no longer trigger split is not a function and no longer make the container card disappear. IPv6 host_ip values are also formatted correctly in generated links.

Compose YAML repair and formatter

The stack editor includes a Fix / format YAML action for compose.yaml. Valid documents are normalized to 2-space indentation. When YAML is invalid because of common Compose indentation mistakes, Dockge-Enhanced attempts to realign service keys and lists (services, service options, environment, ports, volumes, healthcheck.test, etc.), validates the repaired document, then formats it. Comments and leading-zero tmpfs.mode permissions are preserved. If a safe repair cannot be produced, the original content is left untouched and the error is shown.

tmpfs permission modes preserved by the Compose editor

The visual Compose editor now preserves leading-zero octal values such as tmpfs.mode: 01777 when it regenerates YAML. Editing another field no longer silently rewrites that permission value as 1777.

Stack path traversal hardening

Stack names supplied to backend operations are now validated before any path is resolved, including code paths that intentionally skip filesystem discovery. Crafted names such as ../outside can no longer escape the managed stacks directory to access another application's Compose or .env files.

Protected Dockge-Enhanced self-updates

Dockge-Enhanced can now update itself through a d

... (README truncated for length)