fghj

Why fghj?

Testing one user journey shouldn’t require booting every microservice you own. fghj reads a small fghj.yaml in each repo, follows declared dependencies outward from whichever repos you’re actually working on, and brings up just that subgraph — with real *.fghj.internal HTTPS domains, trusted locally signed certs, and no docker-compose.yml to hand-maintain.

Federated config

No mega-repo. Every service declares its own dependencies in its own fghj.yaml — peers, not a tree with one root.

Real HTTPS, locally

A local CA and a TLS-terminating reverse proxy issue trusted certs on the fly for every *.fghj.internal domain your services get.

Fog-of-war visibility

The graph only shows what’s actually on disk. Selecting a user flow highlights its slice — it never hides the rest.

One shared environment

A default run tops up idempotently as you touch more of the graph, plus disposable named runs for testing a specific branch in isolation.

At a glance

# Wire a workspace into the running daemon
fghj wire git@github.com:acme/checkout-service.git

# Validate a service's fghj.yaml against the schema
fghj validate ./fghj.yaml

# Resolve the full dependency graph and print it as JSON
fghj graph git@github.com:acme/checkout-service.git

fghj.yaml

version: "1.0"
service:
  name: checkout-service
  build:
    context: .
  ports:
    http:
      primary: true
  dependencies:
    - kind: service
      repo: git@github.com:acme/payments-service.git
      default_branch: main
    - kind: backing
      name: postgres
      image: postgres:16
      ports: ["5432"]

flows:
  checkout:
    description: End-to-end checkout journey
    dependencies:
      - kind: service
        repo: git@github.com:acme/payments-service.git
        default_branch: main