Step-by-step operator runbook for turning on updates.jakubkadlec.dev:
create the webroot, append the site block, validate the Caddyfile
before reload, watch for Let's Encrypt cert issuance, verify from an
external client, plus explicit rollback for every mutating step and a
catastrophic-recovery section in case Caddy drops all sites. Targeted
at Jakub (VPS operator) so Claude does not touch the running service.
Caddy site block for the update CDN. Serves the signed manifest with
short TTL, content-addressed blobs as immutable, historical manifests
as immutable, and the Velopack launcher feed alongside. Caching rules
are calibrated so a new release is visible within a minute without
hammering the origin on thundering herds.
After a survey of existing Metin2 launchers, general-purpose
auto-updaters, and adjacent open-source game launchers, update the
design to:
- drop the hand-rolled rename-before-replace self-update path
- use Velopack for launcher self-update (MIT, modern successor to
Squirrel.Windows, handles atomic replace, delta, Authenticode, AV
friendliness out of the box)
- keep the custom asset patcher for the 4 GB game payload, which
Velopack is not designed for
- reference runelite/launcher as the architectural template
- name Sparkle 2 and wowemulation-dev/wow-patcher as Ed25519 prior art
No Metin2 community launcher is worth forking; the ceiling of
published prior art is 'file list + sha256 + HTTP GET' and this design
is already above it. Greenfield confirmed.
Formal JSON schema for the release manifest, with canonical ordering
rules so signatures stay stable. Includes a small synthetic example
under docs/examples/.
Design for a content-addressed, signed manifest-based update system for
the Metin2 client. Launcher is a single entry point; server is static
files behind Caddy at updates.jakubkadlec.dev; manifests are signed with
Ed25519. Publishing starts manual in v1 and moves to Gitea Actions in v2.
