# Hyvor Relay: a self-hosted email API that sends through your own SMTP infrastructure

> Hyvor Relay is an open source email sending service you host yourself, with a Symfony API, Go workers that handle SMTP, webhooks and DNS, a Postgres database that doubles as the queue, and the deliverability machinery that usually comes with commercial providers. It is a good fit when IP reputation matters to you, and a poor fit if you want a set-and-forget transactional mail setup.

**hyvor/relay** — 📨 Open-Source Email API for Developers. Cloud & Self-hosted Alternative to SES, Mailgun, SendGrid.

- Repository: https://github.com/hyvor/relay
- Website: https://relay.hyvor.com
- Stars: 918 · Forks: 65
- Language: PHP
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/hyvor-relay

## Sending mail through infrastructure you control

Hyvor Relay is a self-hosted, open source email API for developers, and the project describes it as a cloud and self-hosted alternative to SES, Mailgun and SendGrid. The mechanism is SMTP: you send email through your own infrastructure rather than through a provider that owns the sending IPs.

The stated design goals are simple to self-host, easy to manage and observe, and capable of sending millions of daily emails. That last number is a claim from the project rather than a measured figure, and the interesting part is what has to be true for it to hold: several sending IPs, queueing, and per-stream reputation management.

The product surface is a small set of pieces that map onto familiar provider features. There is an email API for sending, a set of health checks aimed at performance and deliverability, and logs with the full SMTP conversation for each message, retained for up to 30 days. There is a web interface for administrators and a separate console for users to look at their own send logs.

Scaling is described as adding more servers and IP addresses as needed, and the deployment paths are Docker compose or swarm based.

The repository is a polyglot project with an unusual shape: the API is PHP on Symfony, the workers are Go, the frontend is SvelteKit with the Hyvor Design System, and Postgres serves as both the database and the queue.

## Two queues, greylisting and the rest of the deliverability machinery

The parts that separate a mail API from an HTTP relay are the deliverability features, and this project implements a lot of them.

Two main queues isolate transactional email from distributional email, and the stated reason is IP reputation. That is the correct reason. A password reset message and a newsletter that nobody asked for have completely different complaint rates, and mixing them in the same sending pool means the worst offenders drag down the reputation of everything else.

Around the queues, the project handles greylisting and retries automatically, handles bounced emails automatically, integrates with feedback loops to manage spam complaints, and maintains suppressions for bounces, unsubscribes and similar cases. Greylisting in particular is the practice of deliberately rejecting a first attempt from a new sender, which many receiving servers use as a spam filter; a sender that greylists correctly has to retry, and a sender that does not get filtered.

Webhooks cover the other side of the contract, with HTTP callbacks for email events so your application can react to a delivery, a bounce or a complaint instead of polling.

One line in the feature list is commented out: dedicated IPs are marked as coming soon. That matters for anyone choosing between this and a provider, because sending from shared addresses and sending from your own dedicated addresses are different products.

## The built-in DNS server removes record management and adds responsibility

DNS automation is one of the more unusual features in the list. The project says you can delegate DNS to the in-built DNS server, so there is no need to manage DNS records manually.

For a self-hosted mail server this is a substantial convenience, because the records involved, the mail exchange host, the SPF and DKIM entries and the sender policy framework records, are exactly the part that newcomers get wrong and that break silently when they get it wrong. Having the software write its own records removes a class of errors.

It also moves the responsibility. Delegating a zone to a server that runs inside your mail infrastructure means that server becomes a component of your DNS. The project also publishes a ROADMAP.md and links a community, a Discord channel and a roadmap file, and the repository contains a benchmark directory and a dev-testing-mail.md file, which suggests the send path is exercised in development rather than only described.

Everything else in the observability story supports the same goal. Prometheus metrics, Grafana dashboards and logs are listed as first-class features, which is what you need when the question is not why did this email fail but why did the whole sending pool start failing after the last DNS change.

## Tenants, projects and two different interfaces

The multi-tenancy model is described as support for multiple tenants with scoped access, useful for organisations and agencies, and on top of that there is project management with multiple isolated projects inside a tenant.

The distinction matters for two kinds of user. An agency running mail for several clients wants one account boundary per client, with its own keys, its own logs and its own reputation, and the project layer is what provides it. A team inside one organisation wants the same isolation between internal systems so that a marketing system cannot spend the reputation budget of the billing system, which the tenant layer provides.

The interface mirrors that split. There is a sudo dashboard for administrators and a console for users, where the console is used for viewing send logs and SMTP conversations. Keeping a hard separation between an administrative surface and a customer surface is the right call for a multi-tenant mail system, because the administrative surface is the one that can change routing and suppression rules for everyone.

The logs being retained for up to 30 days is what makes the console useful for debugging, since a delivery problem is often visible only in the SMTP conversation rather than in the API response.

## Three services in compose, one image built from four base stages

The compose file in the repository shows the deployment shape: a frontend service, a backend service and a worker service, each built from the same context with different targets, all on a shared network, and routed by Traefik labels rather than by published ports.

```yaml
  backend:
    container_name: hyvor-relay-backend
    build:
      context: .
      target: backend-dev
    volumes:
      - ./backend:/app/backend
      - /app/backend/vendor
      - relay_media:/app/media
```

The routing is done with host rules, so the same hostname serves both the frontend and the API paths.

```yaml
      traefik.http.routers.hyvor-relay-backend.rule: Host(`relay.hyvor.localhost`) && PathPrefix(`/api`)
      traefik.http.routers.hyvor-relay-backend.entrypoints: https
      traefik.http.routers.hyvor-relay-backend.tls: true
```

The Dockerfile is a multi-stage build over four base images, one per ecosystem, which is why the build needs all of them.

```dockerfile
FROM node:24.9.0 AS node
FROM composer:2.8.8 AS composer
FROM dunglas/frankenphp:1.10.0-php8.4.15 AS frankenphp
FROM golang:1.25.4 AS golang
```

For development, the project points at a separate environment repository, hyvor/dev, and the run command starts the stack on a local hostname.

```bash
./run relay
```

The directory structure mirrors that split: /backend for the Symfony API, /frontend for SvelteKit and /worker for the Go services, which the README describes as a single binary.

## AGPL-3.0, enterprise licences and a version number still under 1.0

Hyvor Relay is licensed under the AGPL-3.0 licence, and the project also offers enterprise licences for organisations that require a commercial licence or that do not wish to comply with the AGPLv3 terms, with a self-hosting licence FAQ linked from the README.

That combination is worth understanding before you deploy it. A self-hosted network service under the AGPL is not the same position as a library under the MIT licence, and the reason the project sells an alternative licence is that the copyleft reach of the AGPL is a genuine constraint for companies that modify the software and serve it over a network. The correct move is to read the licence text and the FAQ and, if the terms do not fit, to talk to the vendor rather than to assume.

The trademark line is also explicit: the HYVOR name and logo are trademarks of HYVOR, SARL. So a fork can be AGPL compliant and still not be allowed to call itself Relay.

On maturity, the version numbers tell their own story. The recent releases are 0.0.46 from 2026-08-10, 0.0.45 from 2026-06-04 and 0.0.44 from 2026-05-09, and the last push was on 2026-10-21. The repository is not archived, and the cadence is frequent, but the software is still numbered below 1.0, which for infrastructure you put in front of a sending IP is the fact to hold onto. Plan for the API to move, and read the ROADMAP.md file that sits in the repository root.

## Conclusion

Adopt Hyvor Relay when you send transactional and distributional email at volume and you want to control the sending infrastructure, the IP pool and the deliverability rules instead of renting them. Do not adopt it when the AGPL-3.0 terms do not fit your organisation, since the project sells an enterprise licence precisely for that case, and do not adopt it expecting dedicated IPs today, because that entry is still marked as coming soon in the feature list. Before the first deployment, read the self-hosting licence FAQ, decide whether you will run the hosted cloud version or the Docker compose and swarm deployment, and plan the DNS side early, because the built-in DNS server exists to remove record management but it also means you are giving an SMTP server authority over your zone.

## FAQ

### What is Hyvor Relay and how does it send email?

Hyvor Relay is a self-hosted open source email API for developers that uses SMTP to send email through your own infrastructure rather than a third party provider. It is positioned as a cloud and self-hosted alternative to SES, Mailgun and SendGrid.

### How does Hyvor Relay protect email deliverability?

It keeps two main queues that isolate transactional from distributional email to protect IP reputation, and it handles greylisting and retries, bounces, feedback loops and suppressions automatically. It also provides multiple health checks, Prometheus metrics and Grafana dashboards.

### What licence does Hyvor Relay use and can I use it commercially?

The project is licensed under AGPL-3.0 and also offers enterprise licences for organisations that need a commercial licence or do not wish to comply with the AGPLv3 terms, with a self-hosting licence FAQ linked from the README. The HYVOR name and logo are trademarks.

### What technology does Hyvor Relay use?

The API backend is PHP with Symfony, the email workers, webhook handlers, DNS server and incoming SMTP server are written in Go, the frontend is SvelteKit with the Hyvor Design System, and PGSQL is used for the database and for the queue.

### Can Hyvor Relay manage DNS for me?

Yes. The project says you can delegate DNS to the in-built DNS server, which removes the need to manage DNS records manually. It also sends webhooks for email events and keeps send logs and SMTP conversations for up to 30 days.

## Sources

- [hyvor/relay on GitHub](https://github.com/hyvor/relay)
- [License: AGPL-3.0](https://github.com/hyvor/relay/blob/main/LICENSE)
- [Project website](https://relay.hyvor.com)
- [README](https://github.com/hyvor/relay/blob/main/README.md)
- [Releases](https://github.com/hyvor/relay/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hyvor-relay