v0.4.60
Signedpublished October 15, 2026What changed
- User accounts is easier to use, and works on a phone. Each account's controls now open under a Manage button as labelled buttons, grouped by sign-in, permissions, limits and removal, with each setting's current state beside it, in place of a row of unlabelled icons that only explained themselves on hover. New account sits beside the heading, and a search box appears once the list is long. Dialog buttons wrap on narrow screens instead of running off the edge.
- Administration is organized into tabs. Server holds updates, server health, the deployment, the push contact and open-source licenses; Workspaces holds the resource limits, file size limits and SSH port range; Domains & TLS holds app subdomains and both kinds of certificate. The links to System, Traefik routes, Container images and User accounts are now a compact row of tiles above the tabs. Workspace defaults explains each group of limits next to its fields, and a card whose setting fails to load shows the error instead of an empty form that would clear the setting on save.
- How to move to another registry. The Deployment card in Administration now explains that the registry changes by running the installer from the new site on the host, which also moves dashboard upgrades to that site.
- A clearer server health card. Administration's About card is now Server health. It opens with a single Ready or Degraded verdict, says in plain words what each check means and what a failure stops working, and shows when the checks last ran, with a button to run them again.
- Open-source licenses have a card of their own. Administration's new Open-source software card links to the server's license notices and says where the notices for workspaces and the desktop add-on are.
- Publish a release without opening the admin dashboard.
scripts/publish.sh --publish-draftmakes an uploaded draft live, every artifact at once, as the dashboard's Publish button does; add--envand a version for another environment. The Control Center's Release page offers it as Publish the draft, confirmed by typing the version. It refuses an unsigned draft and leaves a release that is already published alone, so rolling back stays in the dashboard. - A DNS provider for wildcard certificates. Administration's new
Wildcard certificates card, or
sudo devgrail dns-provider set <provider> <test-domain>over SSH, checks a DNS provider by issuing a test wildcard certificate from Let's Encrypt's staging CA, and only then hands it to Traefik. The card lists Loopia, Cloudflare, DigitalOcean, Gandi, GoDaddy, Google Cloud DNS, Hetzner, Hostup, Linode, Namecheap, OVHcloud, Porkbun and Vultr with the credentials each one needs, and takes any other provider lego supports except AWS Route 53. The card andstatus,test,removeandpruneon the command line show the provider, test more domains and remove it; a failedsetorteston the command line now exits non-zero. The card's domain to test starts as your default base domain, since a base domain's wildcard switch needs a passed test of that domain, and it lists the base domains that have not passed yet. Values are entered once, never shown again, and kept as root-only files on the host: not in the database and not in backups. - A wildcard certificate per base domain. Each base domain under App
subdomains gets a Wildcard certificate switch. Once the DNS provider has
passed a test of that domain (Test this domain runs one), switching it on
has Traefik order
*.<domain>with no restart; every new subdomain is then served at once, with no certificate of its own and no name in Certificate Transparency logs. Subdomains that already have a certificate keep it. Switching it off asks for your password: Traefik drops the wildcard and restarts, briefly disconnecting everyone, and each subdomain without a certificate of its own then orders one. A base domain with the switch on cannot be removed, nor can the DNS provider. - Wildcard certificates are watched. Every 10 minutes (every minute while
a switched-on base domain waits for its first wildcard) DevGrail reads the
certificate Traefik serves under each base domain, and App subdomains shows
it: ordering, active (in green) and valid until a date, renewal overdue or
expired. Admins get a notification when a switched-on wildcard becomes
active. If no wildcard arrives within 2 hours of switching on, or one has
under 20 days left, admins get a notification, at most once a day, naming
the command to test the provider. A first order that failed is retried on
its own. A wildcard 3 days from expiry is removed before it can block every
subdomain under it, and admins are told. A wildcard still served after its
switch went off shows as left-over, with Remove it. The System overview
lists these problems, and warns when the dashboard itself is served a
wildcard instead of a certificate of its own.
docs/RUNBOOK.mdhas a section on wildcard certificates: the Loopia API user and its permissions, the staging test, what switching off costs, what the alerts mean, and recovery over SSH, including after restoring onto a rebuilt host. - Why a wildcard certificate is worth having. While no base domain has one, Administration suggests it near the top of the page, and a workspace's Subdomains section suggests it to admins when its base domain has none: a new subdomain works over HTTPS at once, its name stays out of the public Certificate Transparency logs, and it no longer counts against Let's Encrypt's rate limits. Set up a wildcard certificate goes straight to the Wildcard certificates card, which now opens with the same reasons. Dismiss the suggestion once and it stays gone everywhere in that browser.
Container images
Installer files
devgrail-desktop-files.tar.gz31 KB
sha256:44dc54d035e3262da2df136dce5e3aac0a1b53b4c31775ee0a2f3024d5d38308devgrail-desktop-install.sh46 KB
sha256:c2f31ebdcb1c09c7278f8d1073d6b99c3b50586922c9d1ca0fe8451e798e4187devgrail-desktop-linux-amd6411 MB
sha256:b48ee796f8479ca37d2fcd558a402f235e349eedb7ecd90cf68df9562bda286bdevgrail-desktop-linux-arm649.9 MB
sha256:ff5d2518c240cfc5671d4533115312e45a2de08e94fce1b177778967c77849a9Signature
ecdsa-p256-sha256key f1f1eaf642454d65
One signature covers every artifact above. It is made off this host, and neither this site nor the registry behind it can check it — that is the point, and it is why verifying it catches things a checksum from the same server cannot. How to verify it.
Verify devgrail-container (amd64)
curl -fsSL https://web-dev.trixibot.com/api/registry/releases/v0.4.60 -o release.json
# -j, not -r: -r appends a newline the signer never saw, and the check fails.
jq -j '.signature.payload' release.json > payload
jq -r '.signature.signature' release.json | base64 -d > payload.sig
openssl dgst -sha256 -verify devgrail-release.pem -signature payload.sig payload
# -> Verified OK
# The payload must name this release, so an older signed one cannot be replayed.
head -2 payload
# ...and it must name this exact file. -qxF: whole line, literal.
grep -qxF 'image devgrail-container 42 amd64 a1d2610c4a69728fdb7d33cf55528f9d307c9ec6d50e7280af7b9ce90a5d8f73' payload && echo "digest is covered by the signature"The signed payload — shown for reading, not for verifying
Copy this from the manifest with jq -j, never from this page: the signature covers exact bytes, and rendering here drops the trailing newline the signer included.
devgrail-release-signature-v1
release v0.4.60
asset devgrail-desktop-files.tar.gz 9 44dc54d035e3262da2df136dce5e3aac0a1b53b4c31775ee0a2f3024d5d38308
asset devgrail-desktop-install.sh 9 c2f31ebdcb1c09c7278f8d1073d6b99c3b50586922c9d1ca0fe8451e798e4187
asset devgrail-desktop-linux-amd64 9 b48ee796f8479ca37d2fcd558a402f235e349eedb7ecd90cf68df9562bda286b
asset devgrail-desktop-linux-arm64 9 ff5d2518c240cfc5671d4533115312e45a2de08e94fce1b177778967c77849a9
asset docker-compose.yml 70 5a68fd5d15c018ef3eb4aef29fa54881c74517f18378d24c75d8723ff62568a9
asset install.sh 70 780257ad7262e5d806bbef534490b686718f3687b56e2ffa381822ef7a05e494
asset traefik-dynamic-http.yml 69 726f358caacf8625fcc3ab27ae3d8d811308029389bf01c6d93efacf8b60fe60
asset traefik-dynamic.yml 70 db7d4c5afe08ae9eb5f0c8227e9ac632776fff4b8929ba30484c36b85924054a
asset uninstall.sh 70 b5fa5df04d471097ceb8d59a0745dd681e21715937c66cf0fdecc945c5076ea7
image devgrail-container 42 amd64 a1d2610c4a69728fdb7d33cf55528f9d307c9ec6d50e7280af7b9ce90a5d8f73
image devgrail-container 42 arm64 76020567b84e4073ac7b548531166e85728da860f2eec9684f1b5d9d0c7ba566
image devgrail-server 86 amd64 0f459c4b14fcff9058521b4e487833d6c4aaf95d6455cb9384d3f772867e7978
image devgrail-server 86 arm64 40549dbaab6ad5fda3e053a582bf16e70ff248d50515829d201daf93c35ef1d8