General

If your users have direct internet access, the application will be available from the browser menu after signing in to your Passwork instance. No additional steps are required: the backend automatically detects the latest compatible version. When the backend is updated, users will be prompted to update the desktop application on their next sign-in.

However, Passwork is often used in air-gapped networks. In that case, installing and updating the desktop application must work without access to the public internet or our repository.

The desktop application version is aligned with the Passwork version you have installed. This article describes the details needed to deploy and keep the Passwork desktop application up to date in air-gapped networks.

Update server

• The update server must serve content in a specific structure so that users can install and update the application correctly. Below we describe the required structure and how to populate it using the provided scripts.
• Desktop application versions are tied to the Desktop feature supported on the backend (version format is XXYY, builds are XXYYZZ). The Passwork server has its own versioning; the desktop application is synchronized with the feature version, not “just the backend”. You cannot publish the “latest” application version to stores or a public repository and install it — the client must receive a build that is compatible with your server.
• The backend has a setting controlled by the DESKTOP_SERVER_BASE_URL variable — the update server URL. The client uses this URL to check for updates and download the installer.
• We strongly recommend hosting the update server separately from the application server: this allows proper resource allocation and keeps responsibilities separate.

Update server structure

The client expects the following layout at the base URL (your DESKTOP_SERVER_BASE_URL):

• At the root — directories for Desktop feature versions in the format XXYY (4 digits, e.g. 0100, 0201). This is not the full backend version but the supported Desktop feature version; it corresponds to specific builds (XXYYZZ).
• In each XXYY directory:
  • Manifest files: latest.yml, latest-linux.yml, latest-mac.yml (paths to installers and checksums).
  • Subdirectories with installers: e.g. 010203/ with .exe, .deb, .rpm, .dmg files, etc.

Example:

shell

DESKTOP_SERVER_BASE_URL/
  0100/
    latest.yml
    latest-linux.yml
    latest-mac.yml
    010203/
      Passwork-Setup-1.2.3.exe
      passwork_1.2.3_amd64.deb
      ...
  0201/
    ...

The client uses the XXYYZZ version obtained from the latest* manifest files.

Scripts for Linux and Windows

• Linux Bash
• Windows PowerShell

Quick checklist

1. Deploy the update server separately from the backend (recommended).
2. Set DESKTOP_SERVER_BASE_URL on the backend to the base URL of this server.
3. Configure population: Bash/PowerShell scripts with OUTPUT_DIR, and if needed PASSWORK_DOMAIN and HTTP_PROXY. Get the version only from the API or a local file; use the repository only as the file source.
4. Run the script on a schedule or manually after backend updates.
5. For monitoring, use the exit code and optionally STATUS_FILE and LOG_FILE.
6. In fully air-gapped networks — use archives from the portal and manually place content in the XXYY format with latest*.yml and installers.

Version rollback

If the application server was rolled back to an older version (the available XXYY version decreased), the script does not automatically remove directories for newer versions. We recommend:

1. Determine the available desktop version using this API request to the backend: <PASSWORK_DOMAIN>/api/v1/app/features; in the response, for the desktop feature — use the version field.
2. On the update server, remove XXYY directories that are newer than this version. Under OUTPUT_DIR there are directories named with 4 digits; keep only those that are not newer than the rollback version and remove the rest (so that clients do not receive an update to a version the backend is not yet compatible with).
3. Run the desktop update fetch script again after the next application server update.

There is no built-in automatic rollback handling in the script: it only syncs one selected version and, per KEEP_RELEASES, removes excess old directories. Removing “too new” directories on rollback is a separate step (script or manual) based on the API response and cleaning the tree under OUTPUT_DIR.