Skip to main content
Golux Group
PigeonAtlas: Golux Group project

Email infrastructure

PigeonAtlas

Email sending for applications: an HTTP API and an SMTP endpoint, Resend-compatible, with your own DKIM key and newsletters that can never delay a password reset.

Visit the live product

The password reset that never arrived

Ask anyone who runs an application what email costs them, and the answer is rarely the invoice. It is the support ticket from a user whose password reset landed in spam, or arrived twenty minutes late because a newsletter was going out at the same moment.

PigeonAtlas is built around the few decisions that actually decide whether mail arrives. Transactional and bulk mail are dispatched by separate processes that never read each other's work, so a broadcast to fifty thousand people cannot put a single reset behind it.

Each customer signs with a DKIM key generated for their own domain, and their DNS points only at PigeonAtlas. What runs underneath can change without anyone being asked to edit a record, and the 'via' label Gmail shows when the sending and signing domains disagree goes away.

Moving in is meant to be boring. Requests match Resend's format, so existing code, including code an AI assistant wrote, works after changing one URL. The migration guide covers the step people skip, bringing the suppression list across, which is also the step that costs them.

What it does

  1. One request

    An HTTP API and an SMTP endpoint. The response returns as soon as the message is queued, so a slow recipient never slows the application down.

  2. Your own DKIM key

    Mail is signed for your domain, with DNS that points only at PigeonAtlas and never needs to change again.

  3. Separate lanes

    Transactional and bulk mail never share a queue, so a newsletter can never hold up a reset or a receipt.

  4. Dead addresses stop at the door

    A hard bounce or a complaint suppresses an address permanently, checked at submission so it never enters the queue.

  5. See what was sent

    Every message is archived as the bytes that actually went out, searchable by recipient, with its full delivery history beside it.

Built with

Ruby on Rails
PostgreSQL
Solid Queue
SMTP

For your product

What this says about how we work

Email is one of the places where an app built quickly fails quietly: a reset in spam, a receipt that never came, and nobody able to see why. We trace that path in every production review, because it decides whether users can get back into the product, and fixing it is usually a day of work rather than a project.

Questions people ask

Is it compatible with Resend?
Yes. Requests match Resend's format, so moving is a base URL and a key.
Does it work with Lovable and Supabase?
There is a setup guide for exactly that, alongside SMTP settings, webhooks and an OpenAPI description.
Is there a free tier?
A thousand messages a month, with no card, which is enough to run a small app and to prove it works before anything is decided.
Why separate transactional and bulk mail?
Because a password reset that waits behind a newsletter is a lost user. Separate processes mean one can never delay the other.

What we did on this one

  • Backend development
  • Frontend development
  • Business consulting

Your project

Build something like this

Get a preliminary budget, timeline and team shape for your product, or talk it through with the engineer who would deliver it.

Other projects

The engineering notes

What we find inside AI-built apps.

The findings from the apps we audit, the fixes that worked, and what each one cost, written by the person who did the work. No roundups, no reposts.

A few emails a month. No spam, unsubscribe any time.

Golux Group

Already a client? Golux Club
is where your project lives: tickets, approvals, files, one record.

Open