Built for automation teams
One webhook surface for every Git provider.
Keep onboarding, namespace sync, and routing in one control plane, then run workers wherever your pipelines live.
Control plane + data plane
Githook hosts your provider configs, installation metadata, and routing rules. Workers pull normalized events from the API and deliver them to your infrastructure with the driver you choose.
Provider instances, tenants, rules, namespaces, and onboarding flows in one place.
Worker SDK receives events, runs match rules, and publishes to your drivers.
What you get
One endpoint to ingest GitHub, GitLab, and Bitbucket events with consistent payloads.
Automatically keep repos, projects, and workspaces in sync after onboarding.
Express match rules once and publish to the right topics and drivers.
Every request is scoped by tenant, ready for SaaS control planes.
Track emitted topics, failures, and retries with a single log stream.
Support both OAuth apps and GitHub App flows with the same API surface.
Open source
Run the same control plane that powers Githook Cloud. The OSS stack ships with the CLI, worker SDK, and provider integrations so you can self-host or prototype quickly.
Self-hosted server
Deploy the Go control plane with Postgres, drivers, and OAuth.
CLI + provisioning
Create providers, sync namespaces, and generate onboarding links.
Worker SDK
Consume normalized events with provider-aware clients.
Pricing
Start free, then step into production-ready routing, longer retention, and priority support when you need it.
Enterprise
Need enterprise support?
SSO/SAML, audit exports, private networking, and dedicated onboarding tailored to your rollout.
Usage-based add-ons
Extra events, retention, and tenant seats are billed as you scale.
What counts as an event?
Any webhook payload processed and routed through rules.
Security first
Per-tenant isolation, secure secrets, and configurable audit trails.
How it works
Githook keeps your onboarding and webhook lifecycle together so your team can focus on automations, not provider plumbing.
Configure a GitHub App, GitLab OAuth app, or Bitbucket consumer in the dashboard.
Pull repos into your tenant and enable webhooks in one action.
Match rules against payloads and publish to the drivers your workers already run.
Worker SDK
Workers connect to the control plane, stream events, and publish to your drivers with minimal setup. You stay focused on the core logic while Githook handles auth, retries, and routing.
package main
import (
"context"
"log"
"os"
"os/signal"
"syscall"
worker "githook/sdk/go/worker"
)
func main() {
ctx, cancel := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
defer cancel()
wk := worker.New(
worker.WithEndpoint("https://githook-app.vercel.app/api/connect"),
)
wk.HandleRule("85101e9f-3bcf-4ed0-b561-750c270ef6c3", func(ctx context.Context, evt *worker.Event) error {
if evt == nil {
return nil
}
log.Printf("topic=%s provider=%s type=%s installation=%s",
evt.Topic, evt.Provider, evt.Type, evt.Metadata["installation_id"])
if len(evt.Payload) > 0 {
log.Printf("payload bytes=%d", len(evt.Payload))
}
return nil
})
if err := wk.Run(ctx); err != nil {
log.Fatalf("worker run failed: %v", err)
}
}FAQ
Get quick clarity on onboarding, security, and how your workers consume events.
Read all FAQsDo I need to host separate webhook endpoints?
No. Githook exposes one endpoint per provider, with tenant isolation and routing handled in the control plane.
How do workers receive events?
Workers use the SDK to pull normalized events from the API and publish them to your configured drivers.
Can I bring my own drivers?
Yes. Use the built-in drivers or register your own to publish into any message bus or queue.
What happens when a repo is removed?
Namespaces are synced automatically. Removed repositories are disabled and events stop flowing.
Spin up a tenant, connect your providers, and start routing events to your workers in minutes.