Wise Wren
In design · nothing to install yet

Up to date.
Without surprises.

Wise Wren will keep the Docker containers on your servers up to date. It checks for new versions on a schedule you choose, tells you about them, and updates only what you approve. Every update gets a snapshot first, a health check after, and a rollback if it fails.

Wren never changes anything you haven’t allowed.

Follow on GitHub Read the design

MIT licensedBuilt in RustSibling of Vigilant Vole

Concept illustration with made-up data. Wren has no interface yet; it will follow the family design system.

Updates shouldn’t be a daily chore.

Keeping a home server current means checking every container, every day, and hoping each update goes well. Wren is being built to do the checking, ask before it acts, and clean up after itself when something breaks.

  • A manual check, every day

    Open the Unraid web UI, look for updates, press the button, check it came back. Nothing tells you when a new version is out.

  • The button doesn’t cover it all

    Unraid’s update button handles containers made from its templates. Compose stacks and stacks updated by a vendor’s own script are left to you.

  • Other tools pick an extreme

    Some only notify, like Diun and What’s Up Docker. Others update blindly, like Watchtower. None of them pause your monitoring, take a snapshot, check health and roll back.

Wren never changes anything you haven’t allowed. With automatic updates off, which is the default, Wren updates nothing on its own: not a container, not a stack, not a “small” dependency. A production server updated behind your back is the worst outcome, so Wren is designed around avoiding it.

Safe updates

Every update, the same careful steps.

Whether you press the button, schedule it for tonight or let it run on its own, an update will go through the same steps, and each one is written to the target’s history.

  1. Preflight

    The server is reachable, there’s room for a snapshot, and the new image is pulled before anything stops.

  2. Maintenance window

    A window opens in Vigilant Vole for the linked monitors, so a planned restart doesn’t alert anyone.

  3. Stop

    The container or stack is stopped gracefully, so its databases are consistent.

  4. Snapshot

    The service’s data is saved as a local rollback point. If there isn’t room, the update is refused rather than filling the disk.

  5. Update

    Pull and recreate the container, bring the Compose stack up again, or run the vendor’s update script.

  6. Health check

    The containers are running and healthy, and the linked monitors stay up for a stable few minutes.

  7. Roll back if it fails

    The previous image or Compose files and the snapshot come back, and the health check runs again. If even that fails, Wren stops and tells you it needs you.

    Only on failure

  8. Close and report

    The maintenance window closes, and you get one notification with the result.

Nothing waits forever Every step has a time limit, and a run can be cancelled until the moment the service is stopped.

Snapshots are not backups They are short-lived rollback points on the same server, kept only while there’s room. Your own backups stay your offsite copy.

Modes and schedules

You decide how much Wren may do.

Each server has a default mode, and each container or stack can override it. Checking for new versions never changes anything; only updating does.

  • Notify only

    Wren tells you a new version is out, with release notes when it can find them. Nothing else happens.

  • Default

    Approve

    One click runs the update now, or at a time you choose. You can also skip a version or snooze it. An approval is for that one version, never the next.

  • Off unless you turn it on

    Automatic

    Updates run on their own, but only inside a window you set, such as 03:00 to 05:00 at night. Any container or stack can be excluded.

Approve now, update tonight.

Approve an update during the day and pick when it runs. A scheduled update shows up as planned maintenance in Vigilant Vole ahead of time, so the people who use the service can see it coming.

Wren checks for new versions on an interval you choose for each server, every six hours unless you say otherwise, and sends one notification per new version, with a digest if you prefer. Notifications go through the same ~40 channels as the rest of the family, from ntfy on your phone to email and Discord.

What it updates

Three kinds of targets.

A target is one thing Wren updates as a unit. Containers and Compose stacks are found on their own; script stacks you add by hand.

  • Containers

    Single containers, including the ones Unraid creates from its templates. The aim is to recreate those the way Unraid does, so its web UI stays in step.

    New version: the image in the registry has changed, or a newer tag matches the range you follow.

  • Compose stacks

    Docker Compose projects, found from Compose’s own labels. The stack is pulled and brought up again as one unit.

    New version: any of the stack’s images has changed.

  • Script stacks

    Apps such as Fluxer that update with the vendor’s own installer. Wren runs a script you defined on that server, and only by name.

    New version: a source such as GitHub releases reports a newer version than the one installed.

One Wren, several servers.

One central Wren keeps the list, the policies and the history. A small agent on each server does the work there.

Checks

  • Docker Hub · GHCR · Quay
  • Any OCI registry
  • GitHub releases
wren one Rust binary · SQLite
  1. Check
  2. Approve
  3. Update
wren-agent On your production server
wren-agent On your test server

Out

  • Web interface
  • REST API · MCP
  • ~40 notification channels
  • Vigilant Vole
Diagram: Wren checks Docker Hub, GHCR, Quay, any OCI registry and GitHub releases for new versions. One Wren server checks, takes approvals and runs updates through a small agent on each server, for example a production server and a test server. Out come the web interface, a REST API and MCP tools, notifications to about 40 channels, and maintenance windows in Vigilant Vole.

The agents connect out to Wren, so your servers open no ports, and they only run scripts defined in their own local config. Wren is designed so that it can never become a remote shell on your servers.

Better together

Works with Vigilant Vole.

Wren and Vigilant Vole are siblings. Connect them, and an update stops looking like an outage.

  • A maintenance window opens before anything stops, so a planned restart doesn’t page you.
  • A scheduled update shows as planned maintenance on your status pages ahead of time.
  • Your monitors become part of the health check: the service has to stay up for a few minutes before the update counts as done.
  • Without Vigilant Vole, Wren checks the containers themselves, and says so.

Where it stands.

Wren is in design, and nothing is built yet. It will be built in phases, riskiest part first. There are no dates: each step is done when it works, and the phase table in the design says what “works” means.

  1. Now

    Design

    What Wren is for, its goals and anti-goals, and the safe update flow, written down and being finalised.

  2. Next

    Spike: the risky parts first

    A throwaway test on a real Unraid server: recreate a template container the way Unraid does, run a vendor’s update script from an agent, compare snapshots with copies, and check registries without hitting their rate limits.

  3. Then

    Skeleton on vole-kit

    Sign-in, users, settings and translations from the family’s shared foundation, and servers with agents that show as online.

  4. Then

    Finding versions

    Containers, Unraid templates, Compose stacks and script stacks, with release notes and one notification per new version.

  5. Then

    Safe update runs

    Approvals, snapshots, health checks, rollback and history. Done when a deliberately broken update rolls back on its own.

  6. Then

    Vigilant Vole and schedules

    Maintenance windows, planned maintenance, health checks from your monitors, and automatic mode with windows and exclusions.

  7. Then

    v0.1

    The REST API and MCP tools, hardening, docs and Unraid templates: the first release.

Later: an iOS app to see available updates and approve them, with push notifications. Wren’s API is being designed to cover everything the app will need.

Questions.

  • When can I use it?

    Not yet. Wren is in design, and there is nothing to install. The roadmap shows what comes first. Watch or star the repository to hear about the first release.

  • Is it open source?

    Yes, under the MIT license, like Vigilant Vole, Nimble Newt and Keen Kestrel. No paid tier, no account.

  • Does it work outside Unraid?

    Unraid first, any Docker host planned. Wren starts where its maker runs his own containers, including the ones Unraid creates from its templates. Plain containers and Compose stacks on any Linux server with Docker are part of the plan.

  • Will it ever update without asking?

    No, unless you turn on automatic updates for that container or stack. Automatic mode is off by default for every server and every target.

    Even when it’s on, updates only run inside the window you set, and you can exclude anything you’d rather update yourself. In approve mode, an approval covers one version: if a newer one appears before the update runs, Wren asks again.

  • Will there be an iOS app?

    Yes, later. It is planned after v1: an app to see available updates and approve them, with push notifications. Until then, notifications reach your phone through ntfy or any of the other channels.

  • Is it a backup tool?

    No. Wren’s snapshots are short-lived rollback points on the same server, there to undo one update. Keep your own backups, ideally somewhere else.

  • How can I help?

    Read the design and open an issue with questions or objections. Stories about how you update Compose stacks or script-updated apps today are especially welcome.