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.serviceon Linux,ru.mockarty.mockarty.plist
on macOS,install-mockarty-service.ps1on 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
- Administration Guide — first-time admin setup
- Cluster Deployment
- Docker Build Guide
- GitOps Guide