Best Boilerplates for Newsletter & Email Products 2026

TL;DR

Ghost 5.x is the best self-hosted newsletter platform for creators — handles subscriptions, Stripe billing, email sends, and a polished editor without any custom development
Keila is the best open source alternative if you need GDPR-first design, multi-tenant architecture, or prefer Elixir/Phoenix over Node.js
Custom Next.js newsletter builds make sense only when you're building a platform for other newsletter operators (Beehiiv-style), not when you're running your own newsletter
Email deliverability is the hidden technical challenge: DKIM/SPF/DMARC setup and IP warming are more important than your sending infrastructure choice
RevenueCat-style paid tier mechanics can be replicated for newsletters with Stripe subscriptions + middleware access control, but the complexity is substantial

The first and most important architectural question for newsletter projects is: are you building a tool for newsletter operators, or are you running a newsletter yourself? These are completely different engineering problems with almost no overlap in the right technical choices.

A newsletter creator (running their own newsletter) needs a content editor, subscriber management, an email sending integration, and optionally paid tiers. The best choice is almost always an existing platform — Ghost self-hosted, Beehiiv, or Kit. Building custom infrastructure for your own newsletter is premature optimization that costs weeks of engineering time to build features you could have for $15/month. The only creator-level justification for custom infrastructure is deep integration with a larger product: if you're building a developer tool where the newsletter is part of the product experience and needs to share authentication, user data, or content with the core SaaS.

A newsletter platform builder (building the Beehiiv, the Substack, the Ghost — a tool for other people to run newsletters) is an entirely different problem. Now you need multi-tenant architecture, per-newsletter analytics, custom sending domains per tenant, a referral program engine, an ad marketplace (if you're going there), and subscriber growth tooling. This is a startup-scale engineering project, not a weekend build. If you're building a newsletter platform, skip the self-hosted Ghost route and read the "Building a Newsletter Platform" section below.

The confusion between these two paths is why so many newsletter-adjacent projects end up over-engineered (creators who built custom infrastructure they didn't need) or under-powered (platform builders who started with Ghost and tried to extend it beyond its design).

Platform Decision

Platform	Cost	Take Rate	Best For
Substack	Free	10%	Discovery-focused newsletters
Beehiiv	$42-$99/mo	0%	Scale-focused newsletters
Ghost	$9-$199/mo (self-host free)	0%	Tech-savvy creators
Kit (ConvertKit)	$9+/mo	0%	Marketing-heavy creators
Custom	Dev time	0%	Platform builders

For most newsletter creators: Ghost (self-hosted) or Beehiiv. Build custom only when you're building the platform itself.

Price: Free (self-host) / $9-$199/month (Ghost Pro) | Creator: Ghost Foundation

Ghost 5.x has excellent newsletter functionality: subscriber segments, scheduled sends, email analytics (open rate, click rate), paid memberships (Stripe), and portal widget for embeds.

# Self-host Ghost on Railway (cheapest managed option)
# Cost: ~$5/month (Railway Hobby plan)

ghost install --db sqlite3  # SQLite for small newsletters
# or
ghost install --db mysql    # MySQL for larger newsletters

Email delivery: Ghost uses Mailgun by default. Budget: ~$15/month for 50k sends.

Ghost's self-hosted deployment has a meaningful difference between the two database options. SQLite is fine for newsletters under ~10,000 subscribers with infrequent sends, but its single-writer limitation becomes a bottleneck when Ghost is simultaneously processing a large send batch and serving web traffic. MySQL is the right choice for any newsletter that expects growth beyond that threshold, or for any deployment that needs read replicas or connection pooling.

Ghost on Railway vs Fly.io vs VPS: Railway's Hobby plan at ~$5/month is the cheapest managed option with zero DevOps overhead — Railway handles TLS, deployment, and environment variables. The limitation is resource constraints; Ghost can be slow on Railway's smallest tier during large sends. Fly.io gives more control: you can deploy Ghost as a Docker container, configure persistent volumes for media storage, and choose your region for latency optimization, at similar pricing to Railway's paid tier. A VPS (Hetzner, DigitalOcean) at $6-12/month gives the most resources for the price and is appropriate for newsletters with >25k subscribers, but requires manual TLS setup, backups, and server maintenance.

Ghost + Stripe membership setup is genuinely polished. Ghost's Portal widget handles the subscription flow end-to-end: subscriber clicks "Subscribe," enters email and payment info, Stripe processes the charge, Ghost creates the subscription, and the subscriber gets confirmation. The Ghost admin dashboard shows MRR, subscriber count, open rates, and churn rate in a single view. For a solo creator, this is everything needed to run a paid newsletter without writing a line of code.

Email performance: Ghost's default Mailgun integration delivers solid open rates for well-maintained lists, but Ghost's sending infrastructure is not differentiated from other platforms on a technical level — deliverability depends on your domain reputation and your list hygiene, not which platform you're using to send. Ghost does include proper unsubscribe handling and bounce processing out of the box, which prevents the list decay that damages reputation over time.

Price: Free (AGPL) / $19-$99/month (Keila Cloud) | Creator: Wambui Karuga + community

Keila is an open source email newsletter manager built on Elixir and Phoenix. It's the most GDPR-native newsletter platform available — consent tracking, right-to-erasure, and data export are first-class features rather than afterthoughts.

Where Ghost is designed for content-first creators who also want newsletter monetization, Keila is designed for developers and organizations that need robust subscriber management with explicit consent workflows. The difference is apparent in the data model: Keila tracks the consent timestamp, consent source (which signup form), and consent text version for every subscriber. When GDPR requires you to demonstrate that a subscriber explicitly opted in, Keila has that record.

The Elixir/Phoenix foundation gives Keila different operational characteristics than Ghost (Node.js). Elixir's OTP supervision trees mean Keila is highly fault-tolerant — a failed email send job doesn't take down the web server. The concurrent programming model handles large batch sends efficiently without blocking the application. For organizations sending to hundreds of thousands of subscribers, Keila's architecture handles load better than Node.js-based alternatives.

Self-hosting Keila requires a PostgreSQL database and an Elixir runtime, which adds operational complexity compared to Ghost's more familiar Node.js/SQLite stack. However, Keila ships an official Docker image that simplifies deployment considerably. The recommended production setup is Docker Compose with PostgreSQL and a reverse proxy (Caddy or Nginx), deployable on any VPS or cloud instance.

Keila's multi-tenant design is relevant for platform builders: the data model separates newsletters by project, with each project having its own subscriber lists, campaigns, and settings. This isn't the full multi-tenant architecture you'd need for a Beehiiv-scale platform, but it gives individual accounts (teams, agencies managing multiple newsletter brands) proper isolation between newsletters.

For building a newsletter product (not just running a newsletter):

// Core newsletter data model
model Newsletter {
  id           String        @id @default(cuid())
  slug         String        @unique
  name         String
  description  String?
  owner        User          @relation(fields: [ownerId], references: [id])
  ownerId      String
  subscribers  Subscriber[]
  posts        Post[]
  // Stripe for paid subscriptions
  stripeProductId String?
  stripePriceId   String?
}

model Subscriber {
  id           String     @id @default(cuid())
  email        String
  newsletter   Newsletter @relation(fields: [newsletterId], references: [id])
  newsletterId String
  status       SubscriberStatus @default(ACTIVE)  // ACTIVE, UNSUBSCRIBED, BOUNCED
  tier         String     @default("free")  // free, paid
  stripeSubId  String?    // If paid subscriber
  openCount    Int        @default(0)
  clickCount   Int        @default(0)
  joinedAt     DateTime   @default(now())
  @@unique([email, newsletterId])
}

A Beehiiv-style platform requires several components beyond this baseline data model. Per-newsletter sending domains are the technically hard part: each newsletter operator needs their own @theirnewsletter.com sending address, which requires per-tenant DNS records (MX, DKIM, SPF), verified in real-time when the operator connects their domain. AWS SES supports this via domain identity verification; you programmatically create a sending identity for each newsletter domain and verify the DNS records before allowing sends.

Multi-tenant analytics means tracking open rates, click rates, and deliverability per newsletter, not just platform-wide. Each email send needs a unique tracking pixel per subscriber per newsletter, and each link needs per-subscriber click tracking. At scale, this generates a high volume of tracking events — using a purpose-built analytics database (TimescaleDB, ClickHouse) rather than standard PostgreSQL queries against a growing events table becomes important beyond ~1 million sends per month.

Referral programs are a significant subscriber growth lever on platforms like Beehiiv. The mechanics: each subscriber gets a unique referral URL, new subscribers who sign up through that URL are attributed to the referrer, and referrers are rewarded (digital rewards, paid tier access, physical goods) at subscriber milestones. The technical implementation requires an attribution table, a reward fulfillment trigger, and referral URL generation. It's 2-3 days of work once the data model is right.

Email Sending Infrastructure

For a newsletter platform, you need a transactional email provider that supports:

High volume (millions of sends per month)
Domain verification (DKIM, SPF, DMARC)
Bounce handling (auto-unsubscribe hard bounces)
Unsubscribe processing (honor unsubscribes automatically)

Best providers for newsletter platforms:

Resend — Best developer experience, $20/month for 100k emails
AWS SES — Cheapest at scale, $0.10 per 1000 emails
Postmark — Best deliverability reputation, $15/month for 10k emails
Mailgun — Good balance, $35/month for 100k emails

// Send newsletter issue via Resend
import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

// Batch send (respect rate limits)
async function sendIssue(issueId: string) {
  const issue = await db.post.findUnique({
    where: { id: issueId },
    include: { newsletter: { include: { subscribers: { where: { status: 'ACTIVE' } } } } },
  });

  // Send in batches of 100
  const batches = chunk(issue.newsletter.subscribers, 100);
  for (const batch of batches) {
    await resend.batch.send(
      batch.map(subscriber => ({
        from: `${issue.newsletter.name} <newsletter@yourdomain.com>`,
        to: subscriber.email,
        subject: issue.title,
        html: renderEmailTemplate(issue, subscriber),
        headers: {
          'List-Unsubscribe': `<https://yoursite.com/unsubscribe/${subscriber.id}>`,
          'List-Unsubscribe-Post': 'List-Unsubscribe=One-Click',
        },
      }))
    );
    await sleep(1000);  // Respect rate limits
  }
}

Email Deliverability

Deliverability is the newsletter product problem that doesn't get enough attention in technical write-ups. You can have perfect code, a great product, and enthusiastic subscribers, and still have your emails landing in spam. The technical fundamentals are non-negotiable.

DKIM/SPF/DMARC setup is the baseline. SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorized to send email from your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing mail that receivers verify against a public key in your DNS. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do when SPF or DKIM checks fail and provides reporting back to you. All three need to be configured in your DNS before you send a single production email. Missing any of them will cause your emails to be filtered or rejected by major providers (Gmail, Outlook).

IP warming applies when you're sending from a dedicated IP (relevant at volumes above ~100k emails/month). A fresh IP has no reputation — spam filters don't trust it. IP warming means gradually increasing your send volume over 2-4 weeks, starting with your most engaged subscribers, to build a positive sending reputation before sending to your full list. Starting with a fresh IP and immediately sending to 50,000 subscribers will trigger spam filters at every major provider, and recovering from a damaged IP reputation takes months.

Engagement-based sending is the most important ongoing deliverability practice. Send preferentially to subscribers who open and click. Inactive subscribers (no opens in 90+ days) drag down your engagement metrics, and engagement rates are a primary signal for spam filter classification. Segment your list into active and inactive buckets and suppress inactive subscribers from sends — or run a specific re-engagement campaign before removing them. Never buy email lists; never scrape emails; never add people who haven't explicitly opted in.

Bounce handling must be automated. Hard bounces (permanent delivery failures — invalid address, domain doesn't exist) must be immediately removed from your sending list. Soft bounces (temporary failures — mailbox full, server temporarily unavailable) should be tracked across multiple sends and converted to hard-bounce treatment after 3-5 consecutive failures. Continuing to send to bounced addresses damages your sender reputation and signals to spam filters that you have poor list hygiene.

Subscriber Growth Features

Growing a newsletter list is as much a product design problem as a marketing problem. The features that drive subscriber growth most efficiently are referral mechanics, frictionless embed forms, and magic link authentication.

Referral mechanics are the highest-leverage growth feature for newsletters with existing subscribers. SparkLoop (a third-party referral tool integrating with most platforms) or a custom implementation: each subscriber gets a personal referral link, new subscribers signing up through that link are attributed to the referrer, rewards unlock at milestones (3 referrals = exclusive content, 10 referrals = paid tier for a month). The flywheel works because your most enthusiastic readers are the most likely to refer, and the reward structure keeps them engaged.

Embed forms are your acquisition surface on external sites. A clean, fast-loading subscribe form that works in an iframe is table stakes. The friction reduction that matters most is single-field forms (email only, no name required) and immediate confirmation feedback — the form should visibly respond within 200ms of submission, with the server confirmation following asynchronously. Adding a name field reduces conversions by 20-40% on average.

Magic link authentication for subscribers eliminates the password problem for paid tiers. A subscriber clicks "Access your account," receives a one-time link by email, clicks the link, and is logged in. No password to forget, no OAuth friction for users who aren't logged into Google or GitHub. For a newsletter audience that's less technically sophisticated than typical SaaS users, magic links reduce support tickets significantly. This is covered in detail in Authentication Setup for Next.js Boilerplates.

Adding paid tiers to a newsletter creates a bifurcated product: free subscribers get some content, paid subscribers get everything. The mechanics are straightforward conceptually but have enough edge cases to be annoying in implementation.

Stripe subscriptions are the standard for paid newsletter tiers. The subscriber flow: user clicks "Subscribe" on the paid tier, redirects to Stripe Checkout with your price ID, completes payment, Stripe webhook fires checkout.session.completed, your webhook handler creates a subscription record linking the subscriber's email to an active Stripe subscription ID, and subsequent content requests check for an active subscription. The content access control middleware is the piece that requires care — it needs to handle subscription grace periods (failed payment, retry window), subscription paused states, and lifetime access edge cases consistently.

Lemon Squeezy is a Stripe alternative worth considering for newsletter products. Lemon Squeezy handles VAT/sales tax collection automatically, which matters for European subscribers — Stripe requires you to configure Stripe Tax separately. For a newsletter operator who doesn't want to think about EU VAT compliance, Lemon Squeezy's flat-fee-inclusive pricing is a genuine simplification.

Tiered access (free/paid/premium) with more than two tiers adds significant product design complexity. Most successful paid newsletters have exactly two tiers: free and paid. Three tiers require clear value differentiation that's hard to communicate and creates subscriber upgrade/downgrade management overhead. Start with two tiers and add a third only after validating demand for the intermediate tier.

Paywall mechanics: where to put the paywall in a newsletter affects conversion rates meaningfully. Mid-article paywalls (free intro, paywall after N paragraphs) outperform end-article paywalls in most A/B tests because readers who are engaged with the content are more likely to convert than readers who've just finished reading. The paywall placement should be after the reader has received enough value to understand what they're buying, but before they've received full value — creating genuine motivation to upgrade.

Newsletter analytics differs from SaaS analytics in what matters: the key metrics are engagement quality (open rate, click rate), list health (bounce rate, spam complaints, churn), and monetization (free-to-paid conversion, subscriber LTV).

Open rate is a directionally useful but increasingly imprecise metric. Apple Mail Privacy Protection (MPP), enabled by default since iOS 15, pre-loads email tracking pixels for Apple Mail users, inflating open rates by 20-40% for lists with significant Apple Mail usage. Open rates should be interpreted as trending data (is it going up or down?) rather than absolute truth. Click rate is a more reliable engagement signal because it requires an actual user action.

Deliverability rate (emails delivered / emails sent) is the metric that tells you whether your infrastructure is working. Anything below 95% warrants investigation — high bounce rates, spam complaint rates above 0.1%, or DMARC failures are the usual culprits. Most sending providers expose deliverability reporting in their dashboard; surface these metrics in your product analytics.

Subscriber LTV for paid newsletters is straightforward: average paid subscriber lifetime (months) times monthly subscription price. The key driver is reducing involuntary churn — subscribers who meant to stay but lost access due to failed payments. Stripe's Smart Retries and Dunning emails recover a meaningful percentage of failed renewals; configure both before your first paid subscriber.

Methodology

Newsletter platform comparison based on direct evaluation of Ghost 5.x, Keila 0.17+, and custom Next.js implementations as of Q1 2026. Email deliverability guidance based on AWS SES, Resend, and Mailgun documentation combined with RFC standards for SPF/DKIM/DMARC. Pricing from official sources as of Q1 2026.

For open source SaaS foundations to build a custom newsletter platform on, see Best Open Source SaaS Boilerplates 2026. For authentication setup in custom newsletter builds, see Authentication Setup for Next.js Boilerplates. If your newsletter product needs community features alongside the newsletter, see Best Boilerplates for Community Apps 2026. Browse all boilerplates in the StarterPick directory.

The SaaS Boilerplate Matrix (Free PDF)