Gantry

Choose the URL first

A launcher can point directly at a fixed endpoint such as http://localhost:7332/, but a my.* address is usually more durable:

my.crtx.dev
my.warden.cv
my.trestle.cv
my.watchpost.cv
my.webfleet.cv

With no explicit instances configured, those addresses still go straight to localhost. If the machine later moves or you add multiple deployments, the operating-system shortcut does not need to change—the browser-side launcher handles the choice.

Linux: a `.desktop` application

For a local Chromium-family browser, application mode gives the Gantry web app a dedicated window rather than a normal tab. Put a desktop entry in ~/.local/share/applications/:

[Desktop Entry]
Version=1.0
Type=Application
Name=Warden
Comment=Open Warden
Exec=chromium --app=https://my.warden.cv/
Terminal=false
Icon=/home/you/.local/share/icons/warden.png
Categories=Development;
StartupNotify=false

Run update-desktop-database ~/.local/share/applications if your desktop environment needs it, then launch Warden from the application menu and pin it to the dock normally. Use an absolute icon path or an icon name installed into the current icon theme.

Wayland window grouping

Native Wayland browsers may not use X11 WM_CLASS matching for an --app window. If the Gantry window is grouped under the main browser icon, inspect the browser’s actual application identity or install the web app/PWA through the browser so it receives a stable app ID. Do not cargo-cult a StartupWMClass value from another machine: Chromium-derived app IDs can depend on the installed app/profile.

Installed browser app vs `--app=URL`

--app=URL is the zero-setup option. An installed PWA/browser app can integrate more cleanly with menus and dock identity because Chromium can launch the installed application by app ID rather than treating the URL as an arbitrary app-mode window. Both approaches still talk to the same self-hosted Gantry service.

macOS

The lowest-friction path is the browser’s “install app” or “create shortcut/open as window” support, which creates an application bundle that can live in Applications and be pinned to the Dock. Point it at the project’s my.* address when you want the endpoint to remain configurable.

If you use a custom wrapper instead, keep it deliberately thin: its job is to open the URL in an app-like window, not to become a second updater or configuration store for the Gantry service.

Windows

Chromium-family browsers can install a site as an app and create Start Menu/taskbar integration. Alternatively create a shortcut whose target is the browser executable plus --app=https://my.warden.cv/. The service itself remains separately installed and updated; the shortcut is only navigation.

For a remote deployment, use an HTTPS hostname or the corresponding my.* launcher rather than baking a private IP into shortcuts on every workstation.

Local app, remote app, same UX

This pattern is one reason Gantry can keep web UIs without giving up desktop ergonomics. The browser shell handles rendering; the Gantry service handles files, terminals, monitoring or backend state. You can run the service on the same computer, a NUC on the LAN, a VPN-connected server or a public HTTPS host without changing the product UI.

Security and browser profiles

A desktop launcher is not an authentication bypass. It opens the same URL with the same application authentication and browser storage as any other visit. If you separate personal and work Gantry deployments, separate browser profiles can also separate cookies and each origin’s local launcher configuration.

Good defaults

Use the my.* address when you want a stable human entry point.
Use app/PWA mode when you want a separate dock/taskbar identity.
Keep the Gantry service bound to localhost unless the deployment actually needs remote access.
Do not duplicate passwords, API keys or service configuration in the desktop shortcut.