Role
Independent builder
Self-hosted email infrastructure / 2026 / Independent builder
Single-Binary Email Infrastructure
Self-hosted email server written in Go with SMTP, IMAP, REST APIs, DKIM signing, and multi-domain support. Designed for teams that want operational simplicity without the usual mail-stack overhead.
Role
Independent builder
Focus
Self-hosted email infrastructure
Stack
Go / SQLite / Linux
Stack
3 technologies
Go, SQLite, Linux
Delivery
1 public endpoints
Backed by a public repository and operator-facing docs.
Runtime
Single-binary service
SMTP, IMAP, REST, and signing fit into one deployable unit.
Ops shape
Self-hosted control
Built for ownership without inheriting a scattered mail stack.
Single-binary email infrastructure for teams that want control without inheriting a full Postfix-era operations burden.
Email remains one of the most operationally awkward parts of running software. Traditional self-hosted stacks usually mean stitching together multiple daemons, carrying years of configuration baggage, and debugging deliverability issues across tools that were never designed to feel cohesive. On the other side, managed providers are convenient, but they can be expensive, restrictive, or a poor fit when you want to own the full flow.
For smaller teams, personal products, and operators who care about understanding the system they run, there is a missing middle: something practical, inspectable, and deployable without turning mail into a separate profession.
Lightr is a self-hosted email server written in Go and packaged as a single binary. It handles inbound and outbound SMTP, exposes IMAP for mail clients, and includes an HTTP API for programmatic management. The goal was not to recreate every legacy mail feature. The goal was to build an operationally simpler mail system that still covers the workflows real teams need.
Lightr reflects how I like to build infrastructure software: fewer moving parts, clearer ownership boundaries, and deployment choices that make sense for smaller teams. It is less about chasing feature parity with enterprise mail products and more about designing a system whose operational model stays understandable.
I wanted email infrastructure I could reason about end to end. I needed something usable for my own projects and potentially for small organizations, but I did not want to inherit the complexity of a stitched-together legacy mail stack. Lightr became an exercise in packaging a traditionally messy problem into something leaner, more inspectable, and more realistic to run on modest infrastructure.
Go / SQLite / Linux