Connect Mockarty Desktop to Cloud

Mockarty Desktop can connect a named Cloud profile without copying a password or licence into the app.

Where to get Desktop

Open Desktop & Devices in the Cloud cabinet: it lists the published builds for each platform with their size and SHA-256 checksum. A platform may be offered in more than one form — on macOS a disk image (.dmg) and an archive (.zip) with the same application; pick whichever your policy prefers. Apple Silicon and Intel Macs are separate builds. When a build comes from a beta channel, the card says Beta next to the version. Download the build for your system, and verify the checksum if your policy asks for it.

If the section says no build has been published yet, this Cloud installation has not shipped a release: ask your administrator rather than looking for the file elsewhere.

When these builds are published, the same section also shows Other Mockarty apps: the CLI for CI and scripts, the Runner for running your Space’s tests on your own servers, the Android Companion and the browser extension. Until then, this block is hidden rather than offering broken downloads. The buttons show the available platform builds; for macOS, choose Apple Silicon or Intel explicitly. All apps and platforms opens the full download catalogue only when it is published.

Desktop on a server

You can run Desktop on your own Linux server and use it from your browser like a remote machine: mocks, tests and Cloud sync run on the server while you open the interface on your computer. In Desktop and devices, take the Linux server build (.tar.gz) for the server’s architecture and unpack it.

1. Create the key Desktop uses to encrypt saved sign-ins. A server has no system password vault, so you provide the key:

   openssl rand -base64 32 > ~/.mockarty-vault.key
   chmod 600 ~/.mockarty-vault.key
   

   Keep the key apart from Desktop’s data. Without the key Desktop does not start, and with a different key it cannot open sign-ins already saved.

2. Start Desktop without a window:

   MOCKARTY_NO_BROWSER=1 \
   MOCKARTY_DESKTOP_VAULT_KEY_FILE=$HOME/.mockarty-vault.key \
   ./mockarty-desktop
   

3. On your computer, open a tunnel and go to the interface:

   ssh -N -L 15780:127.0.0.1:5780 user@your-server
   

   Open http://127.0.0.1:15780/ui/. Port 15780 keeps clear of a Desktop on your own computer.

The interface listens on the server’s 127.0.0.1 only and is not reachable from outside — access goes through SSH. Signing in to Cloud works as in the app: the cabinet opens in your browser and, once you approve, you return to Desktop through the same tunnel. The sign-in survives restarts. If the page asks you to sign in again after the server restarted, reload it. Data lives in ~/.mockarty of the user Desktop runs as.

Before you start

Without an account you can use local mocks, API and UI testing, and capped
fuzz testing. Reliability and chaos testing require signing in with an active
Cloud entitlement or activating a licence that includes those capabilities.

Local work does not require an account. Hover over Limits in the Desktop header or press that button to see usage for available objects and runs. You can also open sign-in or account settings there. Reaching a limit preserves existing data.

Without signing in, start in sandbox. Creating additional workspaces requires signing in; existing workspaces from earlier use remain accessible. Usage limits are shared across this device’s workspaces, not reset when you switch workspaces. If existing usage exceeds a limit, remove unneeded objects or choose a plan with more capacity before creating more.

In Desktop → Namespaces, a failed refresh is shown separately from an empty list. Previously loaded workspaces stay visible; choose Retry after the local service is reachable again. If creating a workspace fails while offline, the current workspace remains selected.

On Mocks, copy HTTP mock address on this device, then append your mock’s route. The address includes the actual local port and selected workspace: for example, http://127.0.0.1:5780/stubs/sandbox plus /orders. Keep Desktop running while clients call it. Select one workspace to obtain its address; the all-workspaces view has no single base address.

In the native app, use − / percentage / + in the header to adjust zoom from 50% to 200%. Click the percentage to reset it to 100%; your choice is saved between launches. The View menu also provides zoom controls. Grid Console in the sidebar opens the local runner console inside the app. Local dashboards show data sources for available local tools.

The embedded Grid Console follows the app’s theme and language. API, UI, performance and fuzz tests execute on the local node; they do not require connecting a separate browser runner. The console manages optional device runners. It shows service status and the runner namespace; selecting a workspace in the header does not itself rebind the runner. Node identity and scheduling controls are under Advanced settings. Start optional services explicitly with Connect; use the same button to disconnect. A separately opened console retains its own header and presentation preferences.

The first local UI test may take longer while Desktop installs the browser components. This first installation needs internet access; prepare and verify the browser before taking the device offline. An account is not required to run a local UI test.

In Desktop → UI Testing, choose whether Desktop should manage a browser or attach to one already running on this device, then select Install / verify browser. The controls become available after Desktop reads the saved browser choice. If that read fails, use Retry; Desktop will not replace an unknown choice with a default. A failed save or verification is shown as an error rather than a successful setup. If an automatic browser installation fails offline, the panel shows the manual installation command for the selected engine.

To run a phone UI test on the same local network, open Desktop → UI Testing → Phone on this network, select the network and a time-limited window, then open it. The QR code on the UI testing page uses the address shown there. Desktop confirms the window status before reporting success and refreshes it while open. If status becomes unknown, do not use an old QR code; choose Refresh pairing status. Turn pairing off closes the temporary network reach, but does not revoke a phone’s existing device token.

The temporary window also carries the paired phone’s runner signaling connection. It does not expose the viewer or administration routes, and closing or expiring the window disconnects active phone connections as well as preventing new ones.

Where things are set

The Desktop menu has two settings entries, as the server does:

• Settings — local namespace settings: recycle bin, Git sync, tracker and test cases, callbacks, cleanup policy. Server-side jury, meeting agents and namespace AI profiles are managed on the server, not here.
• Desktop — the application itself: the Cloud connection, licence, namespaces, modules, plugins, UI testing, updates and the AI and models section.

In a Team Space with task tracking available, its owner can switch on the local tracker under Settings → Test cases & tasks. The Tasks navigation then appears. Team discussions and their notification sound are personal preferences in the account menu; these controls are hidden without access to team features.

For AI functions available to your account and licence, add a local model under Desktop → AI and models: press Create Profile, pick the provider, enter the model and your key, press Test and make the profile the default. Adding a profile does not unlock agent features that your plan does not include. The key is stored encrypted on this device. Team members and their roles are managed in the Cloud cabinet: the Desktop is one person’s application.

Open Desktop → General for appearance, language and privacy preferences.
Privacy and network options form a separate group; changing the appearance does
not save or enable analytics. Other settings remain available in the section list.
Privacy controls remain unavailable until Desktop reads the saved privacy settings.
If that read fails, check local storage and use Retry; Desktop does not save
the form’s default values over an unread setting.
If the Grid Console’s default local port is occupied, Desktop automatically
selects another free port on this machine. An explicitly configured address is
never changed: if it is occupied, free it or change the setting and restart Desktop.
The embedded console shows its status and any failure reason in the upper panel;
it does not leave an empty duplicate status card below.

Native Desktop packages include desktop-runner for testing real desktop
applications; no separate download is needed. Enable Desktop app testing in
Grid Console, check readiness and connect the runner services. On macOS, grant
Screen Recording and Accessibility access when requested, then Re-check.
Installed components and available permissions are reported separately. Keep the
desktop session available while scenarios run. On Linux, use an X11/Xorg session;
Wayland can restrict capture and input.

On macOS, permissions apply to the installed application requesting access,
not to every application with the same displayed name.
Keep one installed copy in a consistent location when checking permissions.
Switching between development and distributed builds may require approval again.
If the switch is already enabled after an update but the check still fails,
remove only the old Mockarty entry with −, add the currently installed copy
with +, then fully quit and reopen Desktop. Other applications’ permissions
and your Mockarty workspaces do not need to be removed.
Do not delete your work or reinstall Desktop merely because a permission is missing;
first check the exact entry in System Settings and use Re-check.
Readiness checks do not request missing macOS permissions automatically. Use
Open Settings to request access explicitly, grant it in the system dialog,
then check readiness again. If macOS asks for a restart, fully quit and reopen
Mockarty before re-checking.

When installing the Linux tar archive, install GTK 3, WebKit2GTK and the X11/XTest
and XKB runtime libraries using your distribution’s package manager. On Debian
and Ubuntu, the additional runner packages are libxtst6, libx11-xcb1,
libxcb-xkb1 and libxkbcommon-x11-0. The Debian package declares these dependencies.

• Create or select a Cloud profile in Desktop settings → Connection → Named connection profiles.
• If creating a profile reports a connection error, check the local Desktop service and retry; the existing profile list is not replaced.
• Make sure the Desktop can reach the Cloud address configured for that profile.
• Sign in to the Cloud cabinet with a verified account.
• If the deployment uses a private certificate authority, ask the administrator
  for its local PEM bundle and start Desktop with SSL_CERT_FILE pointing to
  that file. Desktop still validates the certificate and the exact server pin;
  do not disable TLS verification.

Authorize the device

External HTTP and HTTPS links in native Desktop open in your default browser.
Documentation links to the local interface stay inside Desktop. Download links
retain their download action.

1. On the Desktop sign-in screen, choose Cloud and click Continue with Cloud.

2. Your browser opens the Cloud cabinet. Compare the visible device code and device name with the Desktop window. The device name is your computer’s name and system, for example MacBook-Air · macOS.

3. Select the Space that this Desktop may access. The selector starts empty; approval never silently chooses the first Space.

4. Click Approve device. The cabinet confirms what it connected, names the Space, and offers Return to Mockarty Desktop; it also returns you there on its own after a few seconds. The cabinet tab stays open, so the browser’s Back button brings it back if you want it.

   If you would rather stay in the cabinet, click Stay in the cabinet — the Desktop is already connected either way.

The authorization is bound to the exact named profile, installation and selected Space. The verified local lease cache records that installation scope and is rejected when copied to another installation, profile or Space.

Your own signed plan controls paid work on this device; the selected Space controls paid shared work in that Space. Joining a paid Team gives an active Seat holder Pro local capability, while Team shared capability remains inside that Team’s Spaces. Selecting a Free Space does not turn your Pro grant into a paid grant for everyone there, and selecting another Team’s Space does not carry your Team’s shared allowance into it. See Cloud entitlements.

Changing the active connection profile applies the new profile’s limits immediately while Desktop prepares its orderly restart. It does not retain the previous Space’s paid controls, and it does not reset account-wide daily usage.

When a Desktop profile is connected to Cloud, fuzz, load and UI-test runs need a live Cloud connection to start. Their daily usage belongs to your account and is shared by all your Desktop installations and Spaces; changing Space or joining a Team does not restart the day’s counter. A run type without a daily ceiling still needs this connection in a Cloud profile so its usage history stays complete. The count resets at midnight UTC. If Cloud cannot be reached, existing local data remains available, and you can retry the run after reconnecting. Anonymous local use and an activated offline licence keep their device-local limits.

The request expires after a short time. You can close the confirmation without approving or denying it. If it expires, is denied, or the browser was closed before approval, start the flow again. Repeated polling is handled by Desktop; you do not need to refresh either page.

Sign out

Open the account menu (top right) and choose Log out, or open the sign-in page and choose Sign out of Mockarty Cloud, then confirm. Desktop:

• removes its Cloud credentials and your plan’s paid capability from this computer;
• stops sync and forgets the sync choice, so the next person who signs in chooses again what to sync;
• asks Cloud to remove this device from Desktop & Devices in the cabinet.

Your local projects stay on this computer. If Cloud cannot be reached, Desktop still signs out here and tells you; remove the device in the cabinet to be sure. To use another account, sign out and sign in again.

Connection recovery

The connection status always names the next action; it never silently changes
profile or Space.

Cloud connection and Desktop package updates are independent. Authorizing a
device does not enable an update feed, and importing an offline update does not
send project data or connection credentials. Use the signed update controls in
the application Help menu; their details view never displays profile tokens.

Lost or replaced device

Open the Desktop & Devices section in the Cloud cabinet and revoke the old installation — each device is listed by its computer name and system. Revocation prevents that installation from receiving a new active connection. Then authorize the replacement device as a new Desktop.

Security notes

• Choose a Space explicitly and verify the device name before approval.
• Do not send the visible device code to another person.
• A private CA bundle adds trust for that CA; it does not bypass the configured
  server identity pin. Stop if either check fails.
• Desktop stores the resulting connection in the credential storage selected by the active named profile. Session-only storage is cleared when Desktop exits.
• If you choose persistent access, keep your operating-system credential vault available to Desktop. If you choose session-only access, sign in again after closing Desktop.
• Before working offline, connect Desktop to Cloud so it can refresh your current access. Offline access lasts only while that access remains valid.

Approve the device in the Cloud cabinet while signed in. A Cloud API token cannot approve it for you.