Why We Built Zekt

The Problem Nobody Talks About

GitHub is the world's development platform. Millions of teams use it every day to build, test, and deploy software. But GitHub was designed around a single assumption: everything that matters happens inside one organization.

In the real world, that's almost never true.

Software supply chains cross organizational boundaries constantly. A platform team publishes a library — and three partner teams in separate orgs need to know immediately. A vendor pushes a security patch — and every customer who depends on that service needs to trigger downstream CI/CD. An internal tools team deprecates an API — and twelve consumer repos across five orgs need to react.

What People Actually Do Today

We asked dozens of engineering teams how they handle cross-org workflow orchestration. The answers were... creative:

• The Curl Script
  A CI step that calls repository_dispatch on the target repo using a PAT token. It works — until someone rotates the token, or a third consumer needs to subscribe, or someone asks "what happened last Tuesday?"
• The Shared Database
  A polling mechanism where consumers check a shared store every few minutes. Fragile, wasteful, and impossible to audit.
• The Slack Message
  "Hey, we just deployed v2.4 — can you update your config?" A human in the loop, every time. Fast for the first month. Unmanageable by month three.
• Nothing
  Teams simply don't coordinate. They accept the drift, the delayed reactions, and the inevitable "why is this broken?" Slack thread at 2 AM.

None of these approaches give you replay. None give you an audit trail. None enforce zero-trust security. And none scale beyond a handful of point-to-point connections.

The Moment It Clicked

We'd been living with this problem ourselves — stitching together curl scripts, managing PAT tokens, and losing sleep over "did that event actually fire?" questions. One day, after spending hours debugging a failed cross-org dispatch that had silently dropped, we asked a simple question:

We looked for it. It didn't exist. So we built it.

Then Our Customers Asked the Next Question

An event bus answers "something happened — react to it." Within weeks, the teams using Zekt were asking for something bigger: "Can I ask five services, owned by three teams, to do something for me — in the right order — and get the results back in my own workflow?"

That question is the everyday reality of platform engineering. A product team needs a subscription, then a resource group, then a key vault, then a pipeline identity. Each piece is automated by someone — usually as a GitHub workflow. Nobody has made them composable.

Declarative Orchestration: One Payload, Many Services

With Zekt, the requestor never scripts the chain. They declare it. A single Zekt Action step sends an orchestration payload to Zekt Core, which dispatches each service to its owner's backend workflow, waits for it to finish, resolves its outputs into the next step's input, and returns the combined result to the requestor.

1. 1 person Requestor workflow Product team declares what it needs
2. 2 send Zekt Action Validates and submits the payload
3. 3 account_tree Zekt Core Orders steps, resolves outputs, tracks every hop
4. 4 dns Provider backends Each service runs as a native GitHub workflow
5. 5 keyboard_return Results returned Outputs land back in the requestor's workflow

{
  "default_service_owner": "platform-team-org",
  "services": [
    {
      "step_id": "create-sub",
      "service_slug": "new-azure-subscription",
      "input": { "billing_account": "ba-123" }
    },
    {
      "step_id": "create-rg",
      "service_slug": "new-azure-resource-group",
      "depends_on": ["create-sub"],
      "input": {
        "subscription_id": "$zekt{{ steps.create-sub.outputs.subscription_id }}"
      }
    },
    {
      "step_id": "create-kv",
      "service_slug": "new-azure-keyvault",
      "depends_on": ["create-rg"],
      "input": {
        "resource_group": "$zekt{{ steps.create-rg.outputs.resource_group_name }}"
      }
    }
  ]
}

Contracts You Can Build On: Zekt Registry & Schema Versioning

Composing services owned by other teams only works if you can trust their interfaces. That is what the Zekt Registry is for: every service can publish versioned schemas describing what it accepts and what it returns — the contract between provider and consumer.

Where Zekt Fits in Platform Engineering

Platform engineering is about one thing: letting product teams consume golden paths without filing a ticket. Most internal developer platforms get there by adding another portal, another backend and another runtime to maintain. Zekt takes a different route — it is a layer on top of GitHub, not a replacement for any part of it.

Every Service Is a Puzzle Piece — and You Can See the Whole Picture

An orchestration-capable service can itself orchestrate other services. A "new product environment" service might, behind the scenes, call a networking service, which in turn calls a DNS and a firewall service. Each of those is a piece of a puzzle: requestors pick the pieces that fit their needs, and providers can build bigger pieces out of smaller ones.

What We Decided to Build — And Not Build

From the start, we were clear about scope. Zekt would not be:

A general automation platform. Zapier and Pipedream do that brilliantly. We're not competing with them. If you need Salesforce-to-Slack, use those tools.

A generic webhook delivery service. Hookdeck, Svix, and Convoy handle arbitrary HTTP webhooks well. We leverage repository_dispatch — GitHub's native event mechanism — because that's what GitHub workflows understand natively.

A CI/CD pipeline. GitHub Actions is your CI/CD. Zekt doesn't replace it. Zekt is the signal that tells your Actions when to run — and, with orchestration, the conductor that tells them in which order.

We started as exactly one thing: the cross-organization event bus for GitHub. Orchestration, the Registry and the Directory grew on that same foundation, because our customers needed them — not because we wanted to become a general-purpose platform. Everything still runs as native GitHub workflows.

The Principles We Build On

Who Zekt Is For

Where We Are Now

Zekt is live. Teams use it to connect GitHub workflows across organizational boundaries, and to orchestrate chains of services owned by other teams — connecting platform teams to their consumers, vendors to their customers, and internal tooling orgs to the rest of the company.

We're still early, and there's a lot more to build. But the core proposition is working: publish a GitHub workflow as a service, and anyone you approve can discover it, subscribe to it, and compose it with others — securely, in order, and with full visibility.

If you've ever written a curl script to trigger repository_dispatch across orgs — or answered the same infrastructure ticket for the tenth time — and thought "there has to be a better way": we built it for you.