my.* instance launchers

The zero / one / many rule

The launcher adapts to the amount of configuration instead of making every user pass through a configuration screen:

0 configured instances  → standard localhost service
1 configured instance   → redirect directly to that instance
2+ configured instances → show the named instance launcher

The zero-instance localhost target is implicit. It is not secretly added to localStorage, so opening configuration still truthfully shows zero configured instances.

Current launchers

Configured instance shape

Each explicit deployment has three human-relevant fields:

{
  "name": "NUC",
  "domain": "warden.home.example",
  "port": null
}

Name is the primary label in the launcher. Domain/IP remains visible as secondary information so you can distinguish similarly named environments. Port is optional because normal HTTP/HTTPS deployments often use standard ports through a reverse proxy.

Config UX

The configuration view keeps management separate from launching. Add/Edit opens a compact modal with vertically stacked Name, Domain/IP and Port fields. The instances table supports selection, edit, individual open and bulk delete. Larger lists paginate in JavaScript with Previous, exact page input and Next controls.

Configuration remains reachable directly even when the normal launcher would immediately redirect to localhost or the only configured instance.

Why browser-local storage

The launcher does not need credentials or a Gantry account; it only needs to remember where you chose to run the application. Browser-local storage keeps that infrastructure map on the device using it.

The trade-off is origin isolation. my.warden.cv cannot directly read my.watchpost.cv storage, and my.crtx.dev lives on another registrable domain entirely. That is inconvenient for setup but preferable to quietly centralizing everybody’s self-hosted endpoints.

Portable setup without a mandatory cloud account

A future shared Gantry launcher configuration can solve the repetition explicitly through import/export or a deliberate cross-origin hand-off protocol. A portable document could carry app visibility/order and named instance definitions while still requiring the user to choose where it is imported.

Hidden iframes plus postMessage may look tempting, but modern third-party storage partitioning makes that a browser-dependent foundation. The safer UX is an explicit user-initiated propagation/import flow whose behaviour is visible and testable.

my.gantry.cv

my.gantry.cv is the app drawer above the per-product instance launchers. Its job is “which Gantry application do I want?” rather than “which Warden machine do I want?”

my.gantry.cv
  ├── Cortex    → my.crtx.dev
  ├── Warden    → my.warden.cv
  ├── Trestle   → my.trestle.cv
  ├── Watchpost → my.watchpost.cv
  ├── Webfleet  → my.webfleet.cv
  └── Pict      → pict.ink

The launcher should be configurable. Cortex, Warden, Trestle, Watchpost, Webfleet and Pict make sensible default-visible tiles; Watchpost Agent and the CLI/library projects can default hidden while remaining available if somebody wants them. Ordering can be user-controlled too.

Why Pict is different

Pict is interactive and therefore belongs naturally in the Gantry app drawer, but it has no per-user self-hosted instance registry. The tile goes directly to pict.ink. Nift, Jsonic++, Minify++, Markup++, TSCC and JS++ are primarily CLI/library tools, so their project sites can be optional tiles rather than default app-launcher entries.

Watchpost links are machine-centric

A Watchpost machine can also carry a Cortex or Warden link. That is not a replacement for my.*: Watchpost answers “open the tool associated with this machine/incident,” while my.* answers “choose one of my deployments of this product.” Both navigation layers remain useful because they start from different intent.