Both runners carry `light` (host1, and host2 over the wg-hosts link), so
these jobs run on whichever host is free. Jobs that mount the docker socket
keep `runs-on: docker`, which only host1 has.
The install guide tells people to curl
.../releases/latest/download/<file>
which is a GitHub URL shape. GitLab's equivalent is
/-/releases/permalink/latest/downloads/<path>
but it only resolves for assets that declare direct_asset_path, and the
release job was creating plain links to the package registry. Those carry
the tag in the URL, so they can never be a "latest" link.
Each asset now also declares /binaries/<file>, which is what the docs will
point at. The path is load-bearing: changing it breaks a documented install
command.
Ports .github/workflows/release.yml after the GitHub account was suspended:
tag-driven, reproducible tarballs, the same refusal to release a tag that is
not an ancestor of the default branch, with the assets going to the generic
package registry and a Release created from them.
e2e.yml is not ported. e2e/public.sh publishes 25, 80, 443, 465, 993, 995
and 4190 on the machine it runs on. On Actions that was a throwaway VM; the
runner here is Web_Host, where 80 and 443 are nginx serving every live site.
It stays a manual check on a disposable host.
The Actions workflows stay in the tree as the reference.
The README keeps what the tool is, how to install it and the first commands,
and points to the guide on docs.ihasmail.org. Everything else moves, whole,
into docs/ and CONTRIBUTING.md, where it is organized for readers who want
the detail. Where the old README disagreed with the code, the code wins.
The ihasmail default was a pin that went stale within days, and ihasmail
keeps ten releases' images, so an old default would in time stop pulling.
With no --ihasmail-image the tool now pulls :latest before asking, reads the
version the image carries, confirms the dated tag is the same image, and
writes that tag into compose.yaml (or the digest, if there is no such tag).
Stalwart and Caddy stay pinned. A weekly end-to-end run against the newest
release, three hours after ihasmail publishes, is what keeps it safe.
The same licence as ihasmail, which this tool deploys. The network clause
is the part that matters for a deploy tool: a modified copy offered as a
hosted service that deploys for other people has to make its source
available to them, which GPL would not require. Running the tool for your
own host is unaffected.
v2026.9.13 was released under GPL-3.0-or-later and stays so; this applies
from the next release.
The first release run stopped at govulncheck: go.mod named 1.26.5, so
the workflow built with it, and 1.26.5 carries four standard-library
vulnerabilities the tool reaches (net/url GO-2026-6218, crypto/tls
GO-2026-6090, encoding/asn1 GO-2026-5972, net/http GO-2026-5026), all
fixed in 1.26.6. 1.26.8 is the current patch release; govulncheck is
clean on it, and it is also the minimum for building from source.
scripts/build-release.sh builds reproducible linux/amd64 and linux/arm64
archives with SHA256SUMS; the release workflow runs it on a v* tag after
vet, tests and govulncheck, and publishes the release. The README now
covers what the tool is, what it does step by step, why each decision is
made, how to deploy and run a mail host, the security model, and
troubleshooting. -h exits 0.
deploy stands up Stalwart 0.16, ihasmail and (for a mail host) Caddy as a
compose project: completes Stalwart's bootstrap over x:Bootstrap, links
ihasmail over the private network, requests certificates for both Caddy
(TLS-ALPN-01) and Stalwart (HTTP-01 through Caddy), makes the auto-ban safe
behind the proxy, and proves the link by signing in through the webmail.
--local gives a loopback-only pair. certs retries Stalwart's certificate;
destroy removes a deployment.
e2e/public.sh runs the whole mail-host path against Pebble with no
internet involved.
jcoffey-dev