Desktop updates

Mockarty Desktop checks for updates only when you ask it to. Stable installed applications use signed packages with recovery. Closed-beta installed applications download and verify a signed package for manual installation. A separate server-hosted build has its own update screen.

Installed Desktop application

For a stable installed application, open Help → Check for Updates. Desktop checks the signed stable release channel and either reports that the current version is up to date or shows the verified candidate. Before offering installation, it verifies the release metadata chain, signed release index, package digest, Mockarty package signature, and the operating-system package signature.

Review the version, channel, size, and digest prefix, then choose Install verified update. Desktop passes that exact package to its external update helper, restarts, checks that the new process is ready, and restores the retained previous version if readiness fails. It does not poll or install silently in the background.

No account or Cloud token is needed to check public releases. A developer build without embedded release trust reports the update channel as unavailable instead of accepting an untrusted package.

Closed-beta installed application

Open Help → Check Signed Beta Update (manual install)…. Desktop looks for a newer compatible beta package on GitHub first. If GitHub has only the installed version or an older one, no compatible release, or a transport outage, it checks Mockarty Cloud. It accepts the package only after verifying its Mockarty signature, exact version, platform, architecture, size and SHA-256 digest; an invalid newer GitHub package is an error, not a reason to switch sources. The check does not use your Cloud sign-in or on-prem server profile.

When a newer package passes verification, choose Show package to find the downloaded installer. Install it manually. Automatic replacement and rollback through the stable native helper are not available for this beta channel. Your Desktop data is stored separately from the application. If GitHub is unavailable and Cloud has no newer package, Desktop reports an incomplete check rather than claiming to be up to date.

Stable-channel offline update

In a stable installed application, choose Help → Import Offline Update, then select the bundle directory containing metadata/ and package/. The offline path applies the same metadata, signature, platform, channel, size, and file-identity checks as the online path. Copy the complete bundle without modifying or renaming its files. The closed-beta menu does not offer this stable bundle action; use its verified downloaded package for manual installation as described above.

Use a stable-channel update mirror

For a stable installed application, set MOCKARTY_UPDATE_FEED_URL before starting Desktop. Use an HTTPS origin such as https://updates.example.com/desktop. Plain http:// is accepted only for the same machine or a private-network host, such as http://127.0.0.1:9000 or http://10.0.0.5/desktop. Closed-beta update checks use the pinned GitHub and Mockarty Cloud sources instead of this stable-channel mirror.

The installed native app does not show the server-hosted Mirror URL editor in Settings. Configure its update source with the environment variable before launch.

The mirror serves the same signed release documents and packages as the public feed, so controlling the mirror is not enough to publish a forged update:

<mirror>/repos/mockarty/mockarty/releases/latest        release listing
<mirror>/repos/mockarty/mockarty/commits/<tag>          {"sha":"…"}
<mirror>/repos/mockarty/mockarty/releases/assets/<id>   packages, signatures, manifests, metadata

The mockarty-desktop-index mirror tool writes this static tree from a published release snapshot, its package assets, and its metadata directory. Serve the output directory with any static HTTPS server, or with a local/private HTTP server for an acceptance test. Restart Desktop after changing MOCKARTY_UPDATE_FEED_URL.

Server-hosted Desktop build

The server-hosted build, opened in a browser instead of installed as the native application, uses Desktop → About.

1. Choose Check for updates. The build immediately asks its configured source and shows either Up to date, Update available: X.Y.Z, or the current failure.
2. Choose Download update. The binary is downloaded and checked against its SHA-256 digest and Mockarty release signature.
3. Choose Install & restart when in-place replacement is supported. A macOS application bundle instead offers the new installer.

Up to date appears only after a successful check. Before the first check, if the updater is unavailable, or if the latest check failed, the page names that state instead of claiming the installed version is current.

This build checks about every six hours unless air-gap mode disables update networking. Its Mirror URL field saves a mirror for the current installation; MOCKARTY_UPDATE_FEED_URL takes precedence over that saved value. The editor stays unavailable until Desktop reads the saved source. If that read fails, use Retry; an empty form cannot silently replace the saved mirror.

Its simpler mirror layout is:

<mirror>/releases/latest
<mirror>/download/<version>/mockarty-desktop-<os>-<arch>
<mirror>/download/<version>/mockarty-desktop-<os>-<arch>.sha256
<mirror>/download/<version>/mockarty-desktop-<os>-<arch>.sig

Do not use this layout for the installed native application; use the signed release-document layout from the previous section.

Use a separate Desktop data directory

By default Desktop keeps its local database, activation, privacy settings, connection profiles, window state, and update recovery data under ~/.mockarty. To keep a managed installation or a validation copy separate, set MOCKARTY_DESKTOP_DATA_DIR before starting Desktop.

The value must be an absolute path to a directory other than the filesystem root. Existing path components must not be symbolic links. Desktop creates the directory when needed; an invalid value stops startup instead of silently using ~/.mockarty.

Do not point two running Desktop processes at the same data directory. Back up the complete directory together: copying only the database does not preserve activation, privacy, or update-recovery state. Persistent connection secrets stay in the operating-system credential store and must be recovered separately.