Simple, Fair, Predictable

Each repository you connect to Zekt (whether as a provider or consumer) costs $10/month. This covers the core infrastructure, security, and workflow orchestration capabilities. Usage fees (API calls, events, etc.) are added on top based on your actual consumption.

No — all repositories connected to Zekt are billed identically at $10/repo/month, whether they act as a provider (sending events) or a consumer (receiving events). If a repository needs to do both, you can either use two separate repositories ($10 each) or the Chainlink add-on ($22/repo), which is purpose-built for that dual role.

Per repository. A chain is not a billable unit — the repositories that form it are. Each Chainlink-enabled repository is $22/month. A three-hop pipeline (A→B→C) consists of three Chainlink repositories billed individually, plus any add-ons (Analytics, Shield) applied per repository on top.

Completely free. The zekt-action is an open-source GitHub Action included at no charge on all tiers. Some teams only use Zekt's event signal (no payload). Others attach rich JSON message payloads via zekt-action for richer cross-org context. Either way — no per-action charges, no metering.

Everything Zekt processes on your behalf: ingesting events from providers, dispatching repository_dispatch webhooks to consumers, evaluating delivery rules, network transfer (inbound and outbound), and storage of event and payload data. If Analytics is enabled, long-term payload retention also contributes to storage costs. GitHub runner costs are not included — those are between you and GitHub.

Event delivery costs a fraction of a cent per dispatch — $0.05 per 1,000 events. A repository with moderate traffic (100 events/day) typically adds about $0.30–$0.50 in usage fees on top of the $10 base, keeping total cost well under $11/month. You can track your exact costs in real time from the Billing tab in the management console. The 7-day free trial gives you real usage data before you commit to anything.

Nothing changes — that's the point of pay-as-you-go. If you send 10,000 events instead of 1,000, you simply pay for 10,000. Zekt does not throttle or cut off your service. Note that GitHub has its own throttling and quotas at the Actions level — those are enforced by GitHub independently of Zekt. You can set budget alerts in the management console to get notified if usage exceeds your expectations.

No hidden fees, no commitments. Pay month-to-month with no contracts. Cancel anytime with no penalties. We believe in transparent pricing — what you see is what you pay. All costs are clearly itemized in your monthly invoice.

Yes — Zekt offers a 7-day free trial with full access to all features including Analytics. Sign up with a payment method; if you opt out within the trial period, no charges apply. Test it with your actual workflows, see the value firsthand, and if you want to continue, your payment method is already in place.

Add Analytics when you need Time Travel Replay — recover from incidents by replaying events exactly as they were delivered, with zero payload drift. Also ideal for deep insights into workflow performance, or visibility into which teams are consuming your services. It's the go-to upgrade for platform teams, ops leads, and anyone who needs to troubleshoot, audit, or optimize cross-org workflows. Try the base service first — you can always upgrade later.

Yes. Contact us at hello@zekt.dev to discuss volume discounts and enterprise features.

In standard Zekt, a repository plays exactly one role: it is either a Provider (it sends events) or a Consumer (it receives them). Chainlink removes that constraint — a single repository can be both simultaneously. This is the building block for multi-step pipelines that span teams and organizational boundaries: each node in the chain receives an event, processes it (optionally enriching or transforming the payload using the free zekt-action), and dispatches downstream to the next consumer. Complex, cross-org business processes become a series of native GitHub workflows, each owned by the team responsible for that step.

Use Chainlink when a repository needs to sit in the middle of a process — receiving a trigger from upstream and dispatching a result downstream. If you're only publishing events, or only consuming them, the standard $10/repo service is the right fit. Chainlink is for repositories that bridge steps in a larger, multi-party workflow.

Zekt uses native GitHub repository_dispatch events as the transport between links. Each link can optionally use the free zekt-action to attach or transform a JSON message payload before dispatching downstream. Each node can pass the payload through unchanged, enrich it with new fields, or strip out data not relevant to downstream consumers — giving every party in the chain full control over what it forwards.

Yes. Zekt supports 1-to-many fan-out at every hop — a single repository can dispatch to multiple downstream consumers simultaneously. Chains don't have to be linear: at any step, one repository can trigger several downstream consumers in parallel, each of which can continue their own independent chain. Every branch can also enrich or transform the payload before forwarding.

Yes. An event can originate in one repository, traverse multiple processing steps across separate teams or organizations, and return a completion signal or enriched response back to the originating repository. This enables full round-trip orchestration — for example, triggering a cross-org compliance check and receiving a structured pass/fail result back into your own workflow.

Chains are capped at 5 hops by default, configurable up to a maximum of 20 hops. This is enforced by Zekt at subscription time to prevent runaway chains and protect against accidental processing loops.

The chain stops at the failed link — downstream consumers will not receive the event. With the Analytics add-on enabled, you get Time Travel Replay: once the failing workflow is fixed, you can re-dispatch the original event (with its exact payload) from the point of failure, without needing to restart the full chain from scratch.

No. Zekt never reads, clones, or inspects your source code. Access is strictly scoped to workflow run metadata, webhook registration, and repository metadata — the minimum required to orchestrate event dispatch.

Zekt is installed as a GitHub App (the Zekt Orchestration App), consented to per-repository — not organization-wide. Required permissions:

• Actions: Read & Write
• Administration: Read & Write
• Contents: Read & Write
• Metadata: Read (mandatory, set by GitHub)
• Webhooks: Read & Write

Organization permissions: None  ·  Account permissions: None

By default, yes — Zekt processes and routes your event payloads in order to deliver them. If payload confidentiality is required, enable the Shield add-on: payloads are encrypted client-side (inside the zekt-action) before they ever reach Zekt's servers, and only the intended consumer can decrypt them using their own private key. With Shield enabled, Zekt cannot read your payloads — and as a consequence, cannot replay them either, since the content remains opaque to us.

It depends on your configuration:

• Base service: Payloads are retained only long enough to guarantee delivery — typically seconds to under a minute, then discarded.
• Analytics add-on: Event and payload history is retained for up to 90 days to support Time Travel Replay.
• Shield add-on: Payloads are stored as opaque ciphertext — same retention rules apply, but the content is never readable by Zekt.

All Zekt infrastructure runs on Microsoft Azure in the EU region. Event data, customer configuration, and metadata are stored in Azure PaaS services (Cosmos DB, Azure Storage). Payment information is handled exclusively by Stripe and is never stored by Zekt.

When you enable Shield, you generate an RSA key pair locally — the private key never leaves your machine. You upload only the public key to Zekt. When a provider dispatches with Shield enabled, the zekt-action fetches your public key and encrypts the payload client-side using a hybrid RSA + AES-GCM scheme before sending it to Zekt. Zekt stores and forwards the encrypted envelope but holds no private key — it is architecturally incapable of decrypting it. Your consumer workflow decrypts the payload locally using your private key. This is a cryptographic guarantee: even under legal compulsion, Zekt cannot produce your plaintext.

When a provider is creating their Service Description, they specify the event type name (dispatched event type) and is associated with the service configuration. This MUST BE the EXACT same name, as they submit to Zekt Action (when depositing their payload) from their whitelisted workflow (service). The consumer of the service, can see / observe the event type name, from the Service card, shown in the tab "Browse Directory" (marketplace) as a property of the service when expanded for easy consumption. The customer would configure their workflow, that they intend to trigger when subscribing to the service as follows from their receiving workflow:

name: Consume GitHub event from custom provider (with message payload)

on:
  repository_dispatch:
    types: [event-type-name-to-trigger-on]

When a provider distributes a pure event (with no message payload via zekt-action), the repository_dispatch trigger on the consumer side must use the value zekt-workflow-completed:

name: Consume GitHub event from custom provider (no message)

on:
  repository_dispatch:
    types: [zekt-workflow-completed]

If you use a custom types value (or omit the types filter entirely), the consumer workflow will not be triggered when the provider sends a plain event. zekt-workflow-completed is the fixed event type Zekt dispatches when no custom payload is attached.

Yes — it is possible to have multiple enabled Zekt services, within a single provider/chainlinked repository! We don't cap the number of workflows that can be whitelisted within a repository, nor services! Eventually it will be around how convenient it is to have all services coming out of a single repository, or if the customer desires to have multiple repos for different services. Zekt has tested +20 workflows/services coming out of a single repository — without problems!

Zekt got you covered! The consumer tab named Inquisition, allows you to block/filter down payloads (events and messages) before the service is allowed to become dispatched to your consumer repository! Inquisition is a deny feature — meaning all rule-sets you configure, if the payload & event matches one of the rule-sets, it will become blocked. This allows you to sort out false-positive scenarios — where event payloads that would otherwise trigger your consumer workflow will become blocked (not dispatched).

Short answer is: Yes — you can create endless loops and you need to be careful! Think of the below scenario:

• A chainlinked provider repo A, service A — generates an event type named A-triggers-B. It also contains a consumer workflow (repo A is chainlinked) which triggers on event type C-triggers-A and by accident, this workflow is using Zekt action, with the event type name A-triggers-B (which would yet again, kick off the chain of calls).

In this case, the workflow in repo A would run — trigger receiver/consumer B, which then sends to C. C would eventually call back to A (event type name C-triggers-A) → which creates an endless loop, by re-using the A-triggers-B value.

Misconfiguration generating endless-loops — if introduced by customers — will be billed, as these can be perfectly legit scenarios depending on intention and are impossible for Zekt to distinguish from invalid scenarios.