What's Updawg? Not much. Your servers are up to date.
Renovate, but for the servers underneath.
Dependabot and Renovate keep your application dependencies current, with reviews, changelogs and automated merges. The machines they run on get patched by a cron job and hope. Updawg gives your fleet the same workflow.
For teams running roughly 10 to 2,000 Linux servers across mixed Ubuntu, Debian and RHEL-family distributions — too small or too mixed for Satellite or Landscape, and past the point where scripts are enough.
Nobody can say what is pending
Application dependencies are reviewed, changelogged and merged. The servers underneath are patched by unattended-upgrades, a cron job, or someone remembering to SSH in — and no two hosts are quite in the same state.
So nobody has a clear answer to what is pending, what was applied last Tuesday, which hosts are waiting on a reboot, or which machines are drifting toward a release that stops getting security updates. Dist-upgrades get postponed until they are emergencies.
A proposal is a pull request for your servers
Versions, changelogs, the CVEs it closes, whether it needs a reboot, which hosts it touches, and how it will be rolled out. Approve it, reject it, snooze it, or schedule it for the window when nobody is awake.
Security updates for web-prod
14 packages · 3 hostsAwaiting approval| Package | Change | Fixes |
|---|---|---|
| openssl | 3.0.13-0ubuntu3.4 → 3.0.13-0ubuntu3.5 | CVE-2024-5535 High |
| libssl3 | 3.0.13-0ubuntu3.4 → 3.0.13-0ubuntu3.5 | CVE-2024-5535 High |
| curl | 8.5.0-2ubuntu10.5 → 8.5.0-2ubuntu10.6 | CVE-2024-7264 Medium |
| + 11 more | ||
How it works
The agent reports
One small binary per host. It reads what is installed and what is available and sends it out over HTTPS.
We classify it
Packages are matched against security advisories, and releases against their end-of-life dates.
You get a proposal
Grouped by policy, with changelogs, CVEs and reboot impact. This is the part that looks like a pull request.
It rolls out
Canary, then waves, with health checks between them and an automatic halt if one fails.
Nothing in that sequence happens without an approval, unless you wrote a policy that says it may. Observe-only is the default: an agent that has just been installed reports and changes nothing at all.
What you get
See the whole fleet
Every host: release, kernel, installed packages, pending updates, security updates with their CVEs, reboot required, services needing a restart, third-party repositories, and how long until the release goes end of life.
Review before anything happens
Pending updates are grouped into proposals by policy. Each one shows version changes, changelog excerpts, the CVEs it fixes, reboot impact and which hosts it touches. Approve, reject, snooze or schedule.
Policy decides what needs you
Written as YAML, validated against a schema, previewable against the live fleet before you save. Security patches on staging can merge themselves; a kernel on production can always wait for a human.
Roll out in stages
Canary hosts first, then waves, with soak periods between them. Health checks run on the host after every change, and a failure halts the rollout instead of continuing into the next wave.
Snapshot and roll back
Where the host can do it — Btrfs with Snapper, ZFS, LVM thin volumes — a snapshot is taken before changes are applied, and rolling back is a button rather than an evening.
Know about EOL early
A calendar of every release you run, with alerts at 180, 90 and 30 days. Dist-upgrade proposals come with a preflight: disk space, held packages, third-party repositories with nothing published for the target release.
It runs as root. So here is exactly what it can do.
Installing packages needs root, so the agent has it. That is a large thing to ask, and the answer is not "trust us" — it is four properties built into the shape of the thing, which stay true even if our servers are taken over entirely.
- No inbound access
- The agent makes outbound HTTPS connections and nothing else. No listener, no open port, no SSH key to distribute or rotate. It works behind NAT and through strict egress firewalls because it never asks to be reached.
- No arbitrary execution
- Jobs are a closed set of typed operations. There is no variant that carries a script, a command line or a string to evaluate — not disabled, not guarded, absent. Full control of the Updawg control plane still cannot run a command of its choosing on your machines.
- Your config always wins
- The server can narrow what an agent will do and can never widen it. If /etc/updawg/agent.toml says this host never dist-upgrades, nothing we send changes that. An empty configuration permits nothing rather than everything.
- Signed, and verified against a pinned key
- Every job is signed by your organization's key, and the agent checks it against the key it pinned when it enrolled — not against whatever the server currently claims. Key rotation works by the old key endorsing the new one, so an agent can follow a rotation without simply believing us.
The agent is intended to be open source under Apache 2.0, because the only convincing answer to "what does it do as root?" is a repository you can read. It also collects a fixed list of things — packages, versions, repositories, and facts about the machine — and never file contents, environment variables, process arguments or credentials. Running updawgctl --print-inventory shows exactly what would be sent, so you never have to take that on faith either.
Pricing
Billed on active hosts per day — a host that checked in within the last 24 hours. A machine you decommission stops costing you money tomorrow, with nothing to cancel.
The shape is settled; the per-host number is not, and we would rather leave it blank than publish a figure we have to walk back.
Free
Individuals and homelabs
£0
up to 5 hosts
- Full visibility
- Proposals
- Manual apply
- Email alerts
Team
Small teams
Per host
billed per active host per day
- Everything in Free
- Policies and auto-merge
- Staged rollouts
- Slack and Teams
- 90-day history
Business
Growing companies
Per host
billed per active host per day
- Everything in Team
- Maintenance windows
- Snapshots and rollback
- Compliance reports
- API and webhooks
- 1-year history
Enterprise
Regulated organisations and MSPs
Talk to us
- Everything in Business
- SSO, SAML and SCIM
- Customer-held signing keys
- Multi-org management
- Data residency
- SLA
Where this is up to
Updawg is being built and is not available yet. Everything above describes the product as designed; this is what actually exists today. Publishing that seems more useful than a launch date we would only move.
Built
- The agent: enrolment, its own generated key, mutual TLS with certificates that renew themselves, and the check-in loop.
- Reading the host — release, kernel, architecture, whether a reboot is pending, which services need restarting.
- The properties in the section above: outbound-only, the closed set of operations, local configuration winning, keys pinned at enrolment.
Not yet
- The service the agent talks to. Until it exists nothing can be signed up for, and the agent has been tested against a gateway built for testing rather than a real one.
- Reading package managers, proposals, policies, rollouts, snapshots and the end-of-life calendar.
- A way to tell us you are interested. There is not even a mailbox on this domain yet — when there is, it will be here.