Docs Installer Guide

Mockarty Installer

The Mockarty CLI installer (mockarty-cli install) is the canonical way
to deploy every Mockarty platform binary across every supported mode:
plain binary, Docker Compose, or Kubernetes (Helm).

Components

mockarty-cli install knows about the six Mockarty platform binaries:

Binary What it does
mockarty Central admin server (Web UI, REST + gRPC API, all features)
mockarty-resolver Lightweight mock-resolution node for distributed deployments
mockarty-runner Distributed test runner (API tests, performance, fuzzing)
mockarty-server-generator Generates standalone mock/MCP/gRPC/SOAP servers from specs
mockarty-desktop Cross-platform desktop UI (standalone / connected / personal modes)
mockarty-cli The CLI itself (self-update channel)

Deployment Shapes

Shape Flag Use when…
Binary --mode binary (default) Single host with systemd / launchd / Windows Service
SQLite --mode sqlite The simplest start: one binary, embedded database, no PostgreSQL or Redis
Compose --mode docker-compose Single host or VM, Docker is available
Kubernetes --mode kubernetes Production cluster, Helm 3 is available
Operator --mode operator Kubernetes with the Mockarty operator managing the cluster for you

Quick Start

Desktop app on Linux

After downloading the Linux Desktop release archive, extract it and run the
installer included in the package:

VERSION=1.2.3
tar -xzf "Mockarty-${VERSION}-linux-amd64.tar.gz"
cd mockarty-desktop
./install.sh

Replace 1.2.3 with the downloaded release version. On an ARM64 machine, use
the linux-arm64 archive instead.

The default per-user installation needs no administrator privileges. It places
the application in $HOME/.local/bin and its desktop entry in
$HOME/.local/share/applications. If this directory is not already on your
PATH, launch the app as $HOME/.local/bin/mockarty-desktop or add the
directory to PATH.

To upgrade an existing installation made by this package, extract the new
archive and run its installer with --force:

./install.sh --force

The upgrade proceeds only when the existing Desktop files still belong to the
previous package installation. It refuses to overwrite unrelated files at the
same paths.

A successful owned upgrade retains exactly one verified previous package slot.
To swap the current and retained slots transactionally, run:

$HOME/.local/bin/mockarty-desktop-rollback

Rollback refuses to continue when either slot is missing, modified, or no
longer matches its ownership receipt. A successful rollback keeps the replaced
slot as the single rollback slot, so the same command can undo that swap.

In a packaged native Desktop build, open Help → Check for Updates… for the
signed online channel or Help → Import Offline Update… for a bundle received
separately. Both paths apply the same metadata, release-index, digest, package-
signature and platform checks. Nothing downloads in the background and nothing
installs until you choose Install verified update for the exact candidate.

Native installation is offered only when that exact Desktop package contains
embedded release trust and an accepted platform helper. Otherwise Mockarty
retains the verified package, reports that installation was not attempted and
directs you to the manual package path. Use only a Windows or macOS release
whose release notes identify that exact package as signed for the platform;
do not approve an unexpected UAC or Gatekeeper prompt. A developer build reports
the feed as unavailable instead of falling back to the legacy raw-binary updater.

Native Desktop update status

The status dialog always shows the current version and one primary action.
Verified details discloses the candidate version, channel, bounded size,
SHA-256 prefix, publisher trust and platform recovery instructions without
showing local paths or internal errors.

Status What it means What to do
Checking / verifying Metadata or an offline bundle is being checked; no install has started Wait, or cancel the check
Up to date The signed channel contained no newer compatible package Close, or verify an offline bundle
Ready The exact candidate is verified and retained Review details, then install only if the native helper is available
Transaction in progress The helper owns a durable request and is checking restart readiness Keep both package slots; resume only when the dialog offers it
Completed The candidate passed readiness Close the dialog
Previous version restored Readiness failed and the retained owned slot was restored Review recovery details before checking again
Manual recovery Completion or rollback cannot be proved Preserve update state and packages; follow the displayed platform instructions

Installing closes and restarts the app only after the external helper has
durably accepted the exact verified package. A success message is shown only
after the next process has passed readiness. If the dialog reports rollback or
manual recovery, do not remove the retained package or update-state directory.

To uninstall the default per-user installation:

$HOME/.local/bin/mockarty-desktop-uninstall

The installer also attempts to register mockarty:// links with the current
Linux desktop. This step is best-effort: if the required desktop utilities are
missing or reject the update, the installer prints a warning while keeping the
application installed. You may need to refresh or sign in to the desktop
session before links open in Mockarty.

Single binary

mockarty-cli install mockarty                       # latest stable
mockarty-cli install mockarty --mode sqlite         # simplest: embedded database
mockarty-cli install mockarty --version 1.2.3       # specific version
mockarty-cli install --all                          # every component

admin-node is accepted as an alias for mockarty, and server-generator
for mockarty-server-generator.

After a binary install you get, side-by-side in the install dir:

  • the binary itself (mockarty-linux-amd64)
  • a convenience symlink (mockarty)
  • a per-binary README (mockarty.README.md)
  • a starter env file (mockarty.env)
  • a service unit (mockarty.service on Linux, ru.mockarty.mockarty.plist
    on macOS, install-mockarty-service.ps1 on Windows)

The README’s “Next Steps” section walks you through licence activation,
admin password setup, and how to enrol runners and resolvers.

Docker Compose

mockarty-cli install mockarty --mode docker-compose
docker compose up -d

This emits docker-compose.yml + .env at the current directory (the .env
is created owner-only, because you will put credentials into it). Each
component lands in its own service block. PostgreSQL and Redis are added
automatically when the admin server is part of the selection.

When the selection includes the resolver or the runner, start the admin
first — those two authenticate with tokens the admin mints, and the generated
.env carries their slots commented out:

docker compose up -d mockarty        # 1. the admin alone
# 2. create a resolver token and a runner token in the admin (Settings → Integrations)
# 3. paste them into .env as RESOLVER_API_TOKEN / RUNNER_API_TOKEN
docker compose up -d                 # 4. then the rest

The CLI prints the same four steps right after it writes the files.

Kubernetes / Helm

mockarty-cli install --all --mode kubernetes --namespace=mockarty

Requires helm and kubectl on PATH. The installer composes a values
file, adds the Bitnami repo for the PostgreSQL + Redis sub-charts, and
runs helm upgrade --install against the bundled Mockarty Helm chart. Pass
--dry-run to write only the rendered values + README without touching
the cluster.

Pin the image for an upgrade you can repeat. The chart derives each
component’s pull policy from its image: a sha256: digest or a pinned tag is
pulled only when missing, while latest is pulled on every start. A latest
image left on a node is therefore never refreshed by helm upgrade — the image
name it compares does not change — so pass an explicit tag or digest
(--set admin.image.tag=<version>) for a reproducible release, and use
pullPolicy: Always only for a tag you deliberately re-push under the same name.
The chart README lists the values.

Generate config without downloading (setup)

To produce deployment files without pulling any binaries — useful when the
image is built elsewhere or you only need the manifests:

mockarty-cli setup docker-compose    # docker-compose.yml + .env
mockarty-cli setup env               # environment file only
mockarty-cli setup kubernetes        # Helm values / K8s manifests

Cross-platform downloads

install downloads for the current OS/arch by default. Override to stage
binaries for another target, or pick the release channel:

mockarty-cli install mockarty --os linux --arch arm64
mockarty-cli install mockarty --channel landing   # mockarty.ru instead of GitHub

Upgrades

mockarty-cli upgrade all                         # latest for everything
mockarty-cli upgrade mockarty-runner             # one component
mockarty-cli upgrade mockarty --version 1.5.0    # pin a version
mockarty-cli update                              # check + update all tracked components

upgrade re-installs to the requested (or latest) version; update checks
every tracked component and upgrades only those that have a newer release.

The CLI reads its installation manifest (~/.mockarty/installed.json),
fetches the latest release per tracked component, and re-installs only
when the requested version differs. Use --force to re-install at the
same version (useful after a corrupt download).

Uninstall

mockarty-cli uninstall mockarty-runner
mockarty-cli uninstall all

Removes the binary, the symlink, the per-binary README, and the
generated service unit from disk and drops the entry from the manifest.
Stop the service first (systemctl stop, launchctl unload, or
Stop-Service) — uninstall does not touch the running process.

versions

Prints a side-by-side table of installed vs latest releases:

mockarty-cli versions

Useful for “what’s drifted” checks before an upgrade.

Air-gapped installs

Mockarty runs fully offline: the web UI, fonts, icons and documentation are
built into the binary and load nothing from the internet. What you prepare in
advance is the set of files the offline host needs. Build it once on a host
with network access:

SOURCE_DATE_EPOCH=1767225600 mockarty-cli install bundle \
  --version 1.0.0 \
  --components mockarty,mockarty-resolver,mockarty-runner \
  --platforms linux-amd64 \
  --chart ./mockarty \
  --compose ./docker-compose.yml \
  --values ./values.onprem.yaml \
  --with-images --images-compose ./docker-compose.yml \
  --out mockarty-1.0.0-airgap.tar.gz

This produces, in one directory:

File What it is
mockarty-1.0.0-airgap.tar.gz Binaries for the chosen platforms, the Helm chart, Compose and values files, and a manifest listing every file with its SHA-256
mockarty-1.0.0-airgap.tar.gz.sha256 Checksum of the bundle itself — publish it or send it over a separate channel
mockarty-1.0.0-airgap-images.tar Container images (docker save), pinned by SHA-256 inside the bundle manifest
load-images.sh Helper that checks the images archive and loads it into Docker

The bundle is reproducible: the same inputs and the same SOURCE_DATE_EPOCH
give a byte-identical file, so two people can compare checksums instead of
trusting each other. --from-dir <dir> takes the binaries from a local release
build instead of downloading them.

Copy the whole directory to the offline host, then check it before installing:

sha256sum -c mockarty-1.0.0-airgap.tar.gz.sha256
mockarty-cli install bundle-verify mockarty-1.0.0-airgap.tar.gz

bundle-verify refuses the bundle if any file is missing, added, altered, or
is not a plain file, and checks the images archive next to it. Then install:

mockarty-cli install airgap-install mockarty-1.0.0-airgap.tar.gz \
  --dir /opt/mockarty \
  --load-images mockarty-1.0.0-airgap-images.tar

The binaries for this platform go to /opt/mockarty, the chart, Compose and
values files to /opt/mockarty/mockarty-assets. The installer verifies the
whole bundle first and writes nothing if a single file fails the check.

Kubernetes without internet access. Push the loaded images to your private
registry, then install the chart from the unpacked files — its PostgreSQL and
Redis dependencies are already inside the chart, so no chart repository is
contacted:

helm upgrade --install mockarty /opt/mockarty/mockarty-assets/chart/mockarty \
  -f /opt/mockarty/mockarty-assets/values/values.onprem.yaml \
  --set global.registry=registry.local/mockarty \
  --set postgresql.image.registry=registry.local \
  --set redis.image.registry=registry.local

If you use an external PostgreSQL and Redis instead, disable the bundled ones
(postgresql.enabled=false, redis.enabled=false) and point the chart at yours.

Release mirrors

For customers who can reach a private GitHub mirror but not
github.com, set the mirror URL:

export MOCKARTY_RELEASE_MIRROR=https://gh-mirror.corp.example.com
mockarty-cli install --all

The installer rewrites all asset URLs through the mirror.

Service activation

After a binary install the service unit is generated but not loaded
into the service manager — that requires root and is left to the user
so the installer itself stays unprivileged. The README prints the exact
load command for your OS:

OS Command
Linux sudo systemctl daemon-reload && sudo systemctl enable --now mockarty
macOS launchctl load ~/Library/LaunchAgents/ru.mockarty.mockarty.plist
Windows powershell -ExecutionPolicy Bypass -File install-mockarty-service.ps1

Next steps