Work

Self-hosted email infrastructure / 2026 / Independent builder

Lightr

Single-Binary Email Infrastructure

Overview

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

Selected signals

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.

Case study

Lightr

Single-binary email infrastructure for teams that want control without inheriting a full Postfix-era operations burden.

The Problem

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.

The Solution

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.

How It Works

  1. SMTP Receiver - Accepts inbound mail, parses MIME payloads, and stores messages in account mailboxes.
  2. SMTP Relay - Sends outbound mail and handles signing for better deliverability.
  3. IMAP Server - Lets standard mail clients connect without extra adapters.
  4. REST API - Exposes domain, account, and template management for product integration.
  5. Persistent Queue - Retries failed deliveries with backoff instead of dropping work.

Key Features

  • Single Binary - Minimal deployment surface and straightforward upgrades.
  • Multi-Domain - Supports multiple domains with tenant-style separation.
  • DKIM Signing - Built-in key generation and automatic outbound signing.
  • IMAP Access - Standard protocol support for normal email clients.
  • REST API - Useful for transactional and product-driven email workflows.
  • Delivery Queue - Persistent queueing with retry behavior.
  • Tracking and Webhooks - Event hooks for product and analytics use cases.
  • Bounce Handling - Better visibility into delivery failures.
  • Rate Limiting - Operational guardrails per account and domain.
  • SQLite Storage - Simple zero-dependency persistence model.

Technical Stack

  • Go - Single-binary distribution and explicit systems control.
  • go-smtp - SMTP protocol implementation.
  • go-imap v2 - IMAP server support.
  • go-msgauth - DKIM signing and verification.
  • SQLite - Embedded storage without extra infrastructure.
  • Cobra - CLI surface for administration.
  • YAML - Human-readable runtime configuration.

What This Shows

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.

Why I Built This

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.

Links

What this work shows

  • Combines mail transport, mailbox access, and APIs into a tighter operational surface.
  • Aims at teams that want to own mail infrastructure without carrying legacy stack sprawl.
  • Keeps deployment simple enough for smaller environments to run confidently.

Links

Stack

Go / SQLite / Linux