Gantry
← DocumentationSuite

Projects working together

Gantry is a suite because the seams between projects can remove real work—not because every project needs to be installed together. Each tool owns a clear problem; integrations pass context, output or navigation across that boundary when doing so improves the workflow.

The rule: independence first

Every Gantry tool should work independently. Using Gantry tools together should unlock disproportionately useful workflows.

A Nift user should never need Watchpost. A Watchpost user should never need Trestle. Pict should not upload images to a Gantry account because somebody installed Warden. Integration is valuable only when the two products already solve adjacent parts of the same real task.

Create → build → optimize

The build-side projects compose as ordinary tools and files:

Pict ───────────────┐
                    │ image assets
Markup++ ─┐         │
Jsonic++ ─┼─→ Nift ─┼─→ generated site ─→ Minify++ ─→ deploy
          │         │
content/data ───────┘

Pict → Nift: Pict edits an image in the browser and exports an ordinary file. Nift references that file like any other asset; neither application needs an integration API.

Markup++ → Nift: this is a direct integration. Nift can process template content and then invoke Markup++ for Markdown, AsciiDoc or reStructuredText, so a documentation site gets one build graph without losing the standalone converter.

Jsonic++ / structured data: dedicated JSON preprocessing can happen before a build when the data needs its own validation/transformation stage. Nift also has native JSON/schema workflows, so Jsonic++ is used when the JSON job genuinely belongs outside the template engine.

Nift → Minify++: generation and optimization stay separate. Readable build output is convenient during development; Minify++ can be a release-stage pass without making Nift responsible for every minification rule.

Frontend → backend

Trestle deliberately integrates through the most boring boundary possible: HTTP.

Nift / JS / Python / Rust / anything
              │
              │ HTTP API
              ▼
           Trestle

A Nift-built application can use Trestle for authentication, collections, files, jobs or functions, but it remains an ordinary web client. Conversely, Trestle can back an application built with a completely different frontend stack. This prevents the suite from turning into a framework lock-in story.

Develop: Warden + Cortex

Warden and Cortex are closely related but intentionally not the same product. Warden is the larger self-hosted development environment: editor, terminals, accounts and agent workflows. Cortex is the focused standalone coding-agent surface.

The useful shared layer is the development context: workspace identity, terminal/process handling, durable sessions, token/run state and eventually completion/debugging primitives. Those can be designed once where appropriate while each product keeps the UI and scope that makes it useful independently.

A developer can therefore choose:

  • Cortex only when the agent is the primary tool.
  • Warden only when a remote browser IDE is enough.
  • Warden + Cortex when both a full workspace and dedicated agent sessions are useful.

Operate: Watchpost + Webfleet

These tools observe different sides of the same system:

Watchpost                    Webfleet
inside the host              outside the host
CPU / RAM / disk             HTTP / API
services / machine state     DNS / TLS / reachability
        │                         │
        └──────── incident ───────┘

If Watchpost says the machine is healthy but Webfleet says the site is down, investigate DNS, TLS, proxying, routing or application behaviour. If both show failure, host/service evidence becomes much more likely to explain the user-visible outage. That correlation is more valuable than duplicating the same check in both products.

Watchpost → Cortex: from alert to investigation

A monitoring product becomes much more useful when the next action is obvious. A Watchpost machine can associate a Cortex endpoint and expose Open Cortex ↗. This is one of the rare Gantry actions that should deliberately open a new tab: the Watchpost incident remains visible while the agent session becomes the investigation workspace.

The integration can evolve in controlled levels:

  1. Open Cortex: navigate to the right machine/instance.
  2. Pass incident context: attach the host identity, failing service, recent telemetry and relevant check IDs.
  3. Investigate read-only: ask Cortex to diagnose and report without making changes.
  4. Propose remediation: Cortex explains exactly what it wants to change and why.
  5. Approve fix: a human authorizes the bounded action.
  6. Policy remediation: only known, explicitly approved failure classes can become automatic.

This preserves a critical distinction: anomaly detection or an agent hypothesis is evidence, not permission to mutate production.

Watchpost → Warden: hands-on repair

Not every incident is an agent problem. A Warden association gives the operator a direct route to editor and terminal access on the affected development/admin machine. The button can live beside Cortex on the Watchpost machine view, again opening a new tab so the incident dashboard remains intact.

Fleet configuration: remove repeated setup

Once Watchpost knows machine identity, it becomes a sensible optional distribution point for selected Gantry configuration. The purpose is not to centralize every preference; it is to make “configure Cortex credentials on 20 machines” achievable.

Configuration bundles can target fleets or selected machines and carry explicit scopes such as provider credentials, model defaults or monitoring policy. Apply-once, managed and default-for-new-machine modes should be distinct so a local change is not silently overwritten unless the operator explicitly chose managed state.

my.* is the human navigation layer

The my.* sites solve a different problem from Watchpost inventory:

my.gantry.cv       choose a Gantry application
my.warden.cv       choose a Warden deployment
my.watchpost.cv    choose a Watchpost deployment
Watchpost          understand machines / fleet / incidents

That separation keeps the browser launchers tiny and privacy-preserving while Watchpost can grow richer machine relationships where there is a real operational reason.

Compiler/runtime relationships

TSCC and JS++ share a language boundary rather than a product dependency. TSCC focuses on compiling TypeScript-oriented programs; JS++ focuses on executing JavaScript in an embeddable native runtime. Cross-testing at the emitted-JavaScript boundary can provide useful evidence without merging compiler and VM concerns.

What Gantry should not do

  • Do not require a Gantry account for local/self-hosted workflows that do not need one.
  • Do not make Watchpost mandatory service discovery for products that can be configured directly.
  • Do not hide privileged cross-product actions behind vague “AI fix” buttons.
  • Do not duplicate project state in a central control plane merely to make the suite look integrated.
  • Do not make the one-machine workflow harder when multi-machine capability is added.