SendRepute Campaigns v0.1.36

SendRepute Campaigns v0.1.36

• In installations using the included managed Caddy HTTPS profile, successful tracking-domain DNS verification now automatically queues additional hostnames and their base paths on the same Campaigns instance. Multiple tracking hosts coexist without replacing the primary hostname, certificate identity or existing campaign choices. Each campaign independently selects its verified tracking domain; verification does not select it automatically.
• Add the tracking hostname's address record pointing to the real server, publish the exact ownership TXT value, allow DNS propagation, then check DNS and verify. The managed installation handles the additional proxy configuration; Campaigns does not create DNS records. External reverse proxies and Tunnels remain operator-managed.
• Covered verified tracking names explicitly reuse an uploaded primary or Origin CA certificate only when its SAN covers the hostname; uncovered names use automatic individual certificate management. Uploaded certificates still need replacement before expiry. Origin CA is not directly browser-trusted: use a compatible Cloudflare proxied Full (strict) setup. Retain required DNS, ports and ACME connectivity.
• Native flock serializes managed writers, revision selection and controller pins. Atomic publication and retention of loading/last-good revisions keep needed PEM files available through concurrent updates, rejection and restart. The runtime image includes util-linux; bare Node installations opting into the shared managed site directory also need native flock.
• Approved tracking routes are retained for already-delivered immutable links when a selectable domain is deleted or its ownership challenge is rotated. Keep those historical hosts' DNS and certificates working; rotation/deletion stops new selection, not previously delivered links.
• Installation and all 14 in-product domain guides now describe automatic managed-Caddy setup, SAN/Origin-CA trust prerequisites, custom base-path mapping and retained-host lifecycle consistently. DNS ownership, configuration acknowledgement and working trusted HTTPS remain separate facts. A loaded configuration or SAN match is not a public TLS probe; this release does not claim a live customer TLS/525 issue was fixed.
• Repository downloads remain the supported publication channel, with the checker validating official releases and complete SHA-256 manifests before returning same-commit pinned archive/checksum URLs. No attachment upload, owner action or manual GitHub workflow is required; actual GitHub workflows are not changed.
• This archive is an isolated, audited self-hosted build with a real installation wizard, not the public website demo.

Compatibility and safe upgrade

This release adds the additive migration 033_tracking_https_hosts.sql, which retains approved hostname/base-path routes and seeds them from previously verified tracking domains. All existing migrations through 032_first_party_unsubscribes.sql are unchanged. Startup applies missing migrations using the existing Campaigns migration path.

Update-checker compatibility: installed v0.1.35 checkers can discover these verified repository downloads. Older attachment-only checkers need the normal one-time Git or archive upgrade to a compatible release. Nothing is downloaded or installed automatically, and no standalone/customer installation is remotely updated by publication. After the ordinary server upgrade, an already configured managed-Caddy installation automatically reconciles existing verified tracking hosts while preserving the primary site and campaign selections.

Before upgrading, back up the complete PostgreSQL database, application data/encryption key and private .env. From the existing Git clone on your server, inspect local edits with git status --short, then run:

git pull --ff-only && ./setup.sh --mode resume

Resume preserves the existing access mode, including HTTPS. Preserve the Compose project, volumes and encryption key; do not clone over an installation, run two versions against one database, or use docker compose down -v. Archive installations follow the installation guide. See Docker backup instructions and isolated restore instructions. Rollback can require restoring matching database and application-data backups.

Downloads and verification

Versioned repository downloads: ZIP · tar.gz · SHA-256 checksums. Verify checksums before extraction; GitHub Code → Download ZIP is a different snapshot.

The exact v0.1.36 archives passed isolated clean-room component builds, a fresh audited self-hosted frontend build, archive/hash/portable-lockfile checks, production npm installation, real local PostgreSQL migration and restart-persistence checks, a Chromium check of the extracted blank installation wizard and branding before owner setup, activation-gated setup, root and installed-installer GET/HEAD redirect checks, public routes and offline paid-settlement upgrade/backup fixtures. The extracted, installed Node runtime also passed additive two-host managed HTTPS staging and native-lock checks. Focused disposable real-Caddy TLS and local ACME-renewal evidence covers multiple hosts, primary certificate reuse, rejection/restart and retained keys; no public ACME or customer host was used. The packaged release checker was verified against the live previous release and its pinned manifest, with its output accepted by the actual TypeScript frontend guard. Release boundary audits remain unchanged; no central website/API implementation, proprietary catalog, tests or source maps are included. No live customer DNS/TLS change, real email, paid generation or customer-host upgrade was performed.