Convoy: a webhooks gateway that keeps your internal services off the public internet

The problem Convoy puts itself between

Sending a webhook looks like one HTTP POST. In practice it is a delivery system: you need to store the event, retry it when the receiver is down, throttle it so a slow customer does not absorb your whole worker pool, and give someone a way to see what happened. Convoy's README frames the project as a gateway that lives at the edge of your network, streaming webhooks out to your users and receiving them from your providers. The stated goal is that internal systems are never exposed to the public internet. That is the audience: teams running a product where third parties subscribe to events, and teams consuming provider webhooks who want a single ingress instead of every service holding its own endpoint. If your product has no external subscribers, this is a large amount of machinery for a small job.

Server, agent and the delivery queue

Convoy splits into two components, server and agent, which the README says can be scaled independently. The server handles ingestion, configuration and the API surface. The agent does delivery work. Between them sits a queue, and the README states the delivery queue can run on Postgres instead of Redis, described as experimental and requiring a license. That single sentence is the most important architectural constraint in the README. It means the default deployment depends on Redis, and the Redis-free path is both experimental and gated. Events arrive, are persisted, then fan out to matching endpoints. Fan out is driven by event type or payload structure. Subscriptions can filter on body, headers, query, and path, and run a JS transform before delivery; events that do not match are dropped. Transforms run JavaScript, which is a real extension point and also a real thing to review before you let customers author subscriptions.

Retries, circuit breaking and per-endpoint throttling

Two retry algorithms are documented: constant time and exponential backoff with jitter. Where automatic retries are not enough, Convoy provides batch retries for endpoints that have consecutively failed to process retried events. Circuit breaking is separate from retries: the circuit opens when an endpoint fails consecutively, then Convoy probes it before sending traffic again. Rate limiting is per endpoint, and the README is explicit that Convoy ingests events at a massive rate while throttling delivery at a configurable rate per endpoint. That asymmetry is the design. Ingestion should not block on a slow receiver; delivery should. The cost is that a customer with a slow endpoint accumulates a backlog, and you now own the question of how large that backlog is allowed to grow. The README does not state a backlog bound or a retention policy, so treat queue growth as something you measure yourself.

Running it: Docker, Helm and the licence key

The README lists two installation paths: Docker and Kubernetes with Helm, both linking to docs.getconvoy.io. It does not inline the commands, so the exact flags and environment variables have to come from the deployment docs rather than this page. What the README does state plainly is the commercial boundary. Community stays free for one user, one organisation, and two projects. Self-hosted premium means adding a license key to enable paid features on your own instance. The Postgres queue sits behind that gate. So the practical upgrade path is: start on the community tier with Redis, and add a licence when you need the Postgres queue or exceed the user, organisation and project limits. The repository also ships a CLI, listed in the topics, and SDKs for Go, Python, JavaScript, Ruby, PHP, and Java generated from the OpenAPI spec, with signature verification hand-written and shared across languages.

Where Convoy is the wrong tool

The clearest failure mode is scope. If one service needs to notify one internal consumer, Convoy adds a server, an agent, a queue and a database to a problem that a background job with a retry loop already solves. The second is the licence. Elastic License v2.0 is not OSI-approved, and the README itself marks the Postgres queue as experimental and licence-gated, so the Redis-free deployment is not something to assume will work unchanged. The third is the community tier: one user, one organisation, two projects. A small team with three environments or three products hits that ceiling quickly, and the answer is a licence key, not a configuration change. None of this is hidden, but it is easy to miss when the feature list reads like a complete product. The material here does not describe migration tooling between tiers, so plan for that as an open question.

How this differs from a general purpose queue

The obvious alternative is putting webhook delivery on top of a general message broker such as Kafka, RabbitMQ or NATS, with a worker that consumes and POSTs. The difference is what each layer knows about. A broker knows topics, partitions and consumer offsets. It does not know that endpoint A is rate limited to a certain number of deliveries per second, that endpoint B has failed consecutively and should have its circuit opened, or that endpoint C subscribed only to events whose payload matches a filter. Convoy puts those concepts in the product: per-endpoint rate limits, per-endpoint circuit state, subscription filters on body, headers, query and path, and a customer-facing dashboard embedded by iframe where users can debug webhooks, retry events, add endpoints and configure subscriptions. With a broker you build and operate all of that yourself. The trade is that you inherit Convoy's licence, its two-component deployment and its queue dependency instead of a broker your team already runs.

Maintenance cost and the licence question

Release cadence is visible from the tags: v26.7.4, v26.7.5 and v26.7.6 all landed within about a week in August 2026, with the last push to main in September 2026. Frequent patch releases on a version scheme that looks calendar-based suggest active maintenance, and also suggest you should expect to upgrade rather than pin and forget. The repository is not archived. On licensing, the README links to the Elastic License v2.0 and the project metadata reports the licence as NOASSERTION, meaning the automated classifier could not map it to a standard identifier. Read the LICENSE file rather than the badge. The relevant practical points from the README are the community tier limits and the licence key requirement for self-hosted premium features, including the Postgres queue. This is not legal advice; if you are embedding Convoy in something you resell, get the terms checked against your use case.

Editorial conclusion

Adopt Convoy if webhook delivery has become its own operational problem: you need retries, per-endpoint rate limits, a queue, and a place to debug failed deliveries without exposing internal services. Do not adopt it if you only need to send a handful of callbacks from one service, or if you cannot accept the Elastic License v2.0 terms for your use case. Before committing, verify three things on your own instance: whether the Postgres queue works for your workload without a license, what the community tier limits mean for your organisation and project count, and how the agent scales against your delivery volume.

Official sources

1. frain-dev/convoy on GitHub
2. Issues
3. Project website
4. README
5. Releases