Taking Control: Why Self-Hosting Your Newsletter Makes Sense (And How to Do It)

The Newsletter Platform Graveyard

Remember Tinyletter? If you were a writer in the early 2020s, you probably do. It was the antidote to bloated marketing platforms—a simple, elegant tool that just worked. You wrote. You sent. People read it. No funnels, no engagement metrics, no A/B tests.

Then it didn't.

When Mailchimp (now part of Intuit) shut down Tinyletter in February 2024, it was yet another reminder of a harsh truth in the SaaS world: if you're not paying for the product, or if you're not the core customer, your service is one "business priority pivot" away from extinction.

This isn't a unique story. It's becoming the norm. And it's sparking a quiet revolution among indie creators, developers, and small publishers: taking newsletter hosting in-house.

The Third-Party Service Trap

On the surface, outsourcing your newsletter makes sense. You avoid dealing with SPF records, DKIM keys, DMARC policies, bounce handling, and all the other email deliverability infrastructure that makes most developers break out in hives. Let someone else worry about maintaining sender reputation, managing suppression lists, and ensuring your messages land in inboxes instead of spam folders.

But there's a hidden cost.

Most commercial newsletter platforms are built for marketers running campaigns, not writers sending letters. Their entire architecture—templates, drag-and-drop builders, tracking pixels, engagement scoring—assumes you want to optimize conversion rates and measure opens. They're designed to answer questions like "Which segment performs best?" when what you actually want to answer is "Did people read my thing?"

Pricing is another problem. Many services charge per subscriber, which makes them prohibitively expensive for a personal newsletter with a modest but engaged audience. And the moment your use case drifts outside their target market, you're no longer their priority. You're friction. You're deprecated.

Most critically: you can't control your own destiny. Your audience—your most valuable asset—is locked behind someone else's platform. If priorities shift, you're starting over.

The Self-Hosting Revelation

Self-hosting a newsletter doesn't mean becoming a DevOps engineer. It means being intentional about your infrastructure choices and building on solid, sustainable foundations.

The modern approach looks something like this:

Infrastructure as Code: Version-control your newsletter content as plain markdown files in a Git repository. Your newsletter issues are just files. Your configuration is declarative and portable. If you need to migrate tomorrow, your content isn't trapped in a database.

API-First Sending: You don't need a marketing dashboard. You need a clean API that integrates with your existing workflow. Feed it your subscriber list, pass it your email content, and let it handle the hairy stuff—bounce detection, deliverability optimization, GDPR compliance. Tools like Postmark, Resend, SendGrid, Mailgun, and open-source options like Plunk can handle this layer without making you feel like you're fighting against their platform.

Simple CLI Workflows: The best part about self-hosting? You can build for yourself. A small command-line tool that lives in your repository. It takes your markdown, transforms it into email, manages your subscriber CSV, and coordinates with your sending service. No web interface. No distractions. Just you, your terminal, and your editor.

Minimal Aesthetics: Embrace the simplicity. Your newsletter doesn't need to compete with Madison Square Garden. A plain-text email with a simple HTML version can be more memorable than most templated designs. Your writing becomes the star, not the design system.

The Architecture That Actually Works

Here's what a self-hosted newsletter setup might look like:

newsletter/
├── issues/              # One .md file per edition
│   ├── 1.md
│   ├── 2.md
│   └── 3.md
├── subscribers.csv      # Your audience (version-controlled)
├── send/                # CLI tool (Python, Rust, Go, whatever)
│   ├── send.py          # Main sending logic
│   └── config.yaml      # Sending service credentials
├── web/                 # Tiny HTTP service
│   └── subscribe.py     # Signup form backend
└── .github/workflows/   # Optional automation
    └── backup.yaml      # Periodic subscriber list backup

Your stack is predictable, debuggable, and—most importantly—portable. You own every piece. If you need to swap sending services, you update one configuration file. If you want to add features (automated social sharing, RSS feeds, markdown footnotes), you ship them in your own codebase.

The Deliverability Question

"But won't my emails get marked as spam?"

This is the legitimate concern. Sending email at scale requires proper authentication (SPF, DKIM, DMARC), domain reputation management, and bounce handling. Setting up these records seems intimidating.

Here's the good news: you don't have to do it alone. Dedicated sending services have solved this problem. They maintain sender infrastructure, manage reputation across millions of messages, and automatically suppress bounces. You delegate the deliverability complexity to specialists while keeping ownership of your content and subscriber relationship.

When you finally do send after a long silence—which is hard in the email world—honest communication matters more than technical perfection. A genuine message acknowledging the gap ("Hey, sorry for the silence—here's what I've been working on") generates engagement that protective list warmup strategies can't buy.

The Cost Reality

Self-hosting isn't free, but it's refreshingly cheap. A sending service might cost $1-2 per thousand emails for a small publisher. That's less than the coffee you drink while writing the newsletter. Compared to per-subscriber pricing tiers, it's almost negligible.

You're trading the simplicity of "set and forget" for a slightly more hands-on approach. But given that most independent publishers send irregularly anyway, the maintenance burden is minimal.

Reclaiming Your Voice

There's something profound about owning your distribution channel. It's the digital equivalent of owning your printing press. You're not renting someone else's platform and hoping they don't pivot their business priorities. You're building something that belongs to you.

This is especially important for independent writers, developers publishing technical articles, and founders building in public. Your newsletter is often your most direct line to your audience—more reliable than Twitter, more intimate than your blog, more controllable than any algorithm.

The tools to self-host are better than they've ever been. Deployment platforms like Fly.io, AWS Lambda, and Railway have made running small services cheap and trivial. Open-source sending layers have matured. The entire infrastructure landscape has shifted in favor of independent creators.

Getting Started

If you're thinking about reclaiming your newsletter:

1. Audit your current stack. Where does your subscriber list live? What's your backup strategy? What happens if your current service shuts down?

2. Pick a sending service based on API quality and pricing that scales with your actual list size, not your dreams of becoming ConvertKit.

3. Start simple. A markdown folder + basic Python/Rust CLI + one HTTP endpoint for signups. You can iterate from there.

4. Make it Git-friendly. Your issues are files. Your config is in the repo. Your infrastructure is code.

5. Genuinely think about your audience. Self-hosting isn't an excuse to stop caring about subscriber experience. Open rates matter less than open minds.

The newsletter revival is underway. Not because self-hosting is trendy, but because it's the antidote to a decade of startup consolidation and platform decay. Your audience deserves a channel that won't disappear when someone's business priorities shift.

Your words deserve a home where they'll still exist tomorrow.