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.

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.

Instead, Zekt would be exactly one thing: the cross-organization event bus for GitHub. Provider orgs publish events. Consumer orgs subscribe. Zekt handles the routing, security, delivery, replay, and audit trail.

The Principles We Build On

Where We Are Now

Zekt is live. Teams are using it to orchestrate GitHub workflows across organizational boundaries — connecting platform teams to their consumers, vendors to their customers, and internal tooling orgs to the rest of the company.

We're still early. There's a lot more to build: richer routing rules, deeper analytics, and more powerful contract validation. But the core proposition is working: publish an event in one org, and every subscribed org's workflow runs automatically, securely, and with full auditability.

If you've ever written a curl script to trigger repository_dispatch across orgs and thought "there has to be a better way" — we built it for you.