Ghost's Native Members Feature: Paid Tiers Without the Plugin Sprawl

You want to charge readers for some of your posts. The traditional answer is bolting on a third‑party platform — Patreon, Memberful, a WordPress paywall plugin — and then spending weekends reconciling two user databases and two login systems. If you're running Ghost 3.0 or later, there's a simpler path: the members and subscriptions feature is built into the core product, and for a straightforward paid‑tier setup it's often all you need.

The thesis here is narrow but practical: if your monetization model is "some posts free, some posts paid, one or two price points," Ghost's native membership stack will get you to production faster and with less operational debt than any external integration. If your model is more complex, read the limitations section before committing.

What the members feature actually gives you

Since Ghost 3.0, the platform ships with a first‑class concept of a member — a registered reader who signs up with an email address and receives a magic‑link login (no passwords to store or leak). On top of that, Ghost supports tiers: named subscription levels that can be free or paid. Paid tiers connect directly to Stripe, which handles card processing, billing cycles, and receipts.

Concretely, you get:

• Free and paid member registration with email‑based sign‑in
• Multiple tiers with monthly and yearly pricing
• Per‑post access rules: public, members only, paid members only, or specific tiers
• A built‑in member portal (the "Portal") for signup, login, and account management
• Stripe integration for payments, configured from the admin UI

No plugins, no webhooks to wire up yourself, no separate membership database. Member records live in Ghost's own database alongside your content.

Turning it on

Everything happens in the Ghost admin panel (/ghost), and you need an admin account on the publication. The general path, with minor label differences across Ghost versions:

1. Go to Settings → Membership and enable membership access. Choose who can subscribe — anyone, or invite‑only.
2. Under Settings → Tiers, create your tiers. Each tier gets a name, an optional description, and — for paid tiers — monthly and yearly prices.
3. Connect Stripe. Ghost generates a secure connection link from the admin UI that walks you through Stripe authorization; you don't have to paste API keys by hand in current versions, though self‑hosters can configure keys directly if they prefer.
4. Optionally customize the Portal's appearance (button style, signup page text) under Settings → Membership → Portal settings.

One version caveat: this requires Ghost 3.0 or later. Older releases have neither the admin UI nor the members API endpoints. Check your version with ghost version from your Ghost install directory on the server (run as the user that owns the Ghost process, not root) before planning around this feature.

A worked example: a $5/month Premium tier

Say you run a newsletter about embedded systems and want to keep weekly posts free while gating deep‑dive teardown articles. The setup:

1. Create a tier named Premium at $5/month and $50/year in Settings → Tiers. With Stripe connected, Ghost creates the corresponding products and prices in your Stripe account automatically.
2. Publish a teardown post. In the post settings sidebar, set Post access to Paid‑members only (or select the Premium tier specifically if you have several paid tiers).
3. Open the post in an incognito window. You should see the public preview followed by the paywall prompt to subscribe. If the full post renders, access control isn't applied — recheck the post's access setting and that your theme isn't overriding the access condition.

To test the full payment flow without real money, switch Stripe to test mode and use Stripe's test card numbers (e.g., 4242 4242 4242 4242 with any future expiry). Subscribe as a test member through your own Portal, confirm the magic‑link sign‑in email arrives, then reload the gated post — it should render in full. Also verify the subscription appears in the Stripe dashboard under test data, and that the member shows as "Premium" in Ghost's member list. Do not claim it works in production until you've repeated the smoke test with live keys and a real (refunded) card.

Theming: the paywall is yours to style

Because membership is native, Ghost themes can react to a member's state. Themes are written in Handlebars, and the relevant pieces are:

• The {{@member}} object, which tells you whether someone is logged in and whether they're a paying member.
• The {{#if access}} conditional in post.hbs, which lets you render the full content, a preview, or a custom call‑to‑action block depending on the reader's access level.
• The Portal, which handles signup and account management as an overlay — so you don't need to build those pages, but you can override its look via Portal settings or custom signup pages if you want tighter visual integration.

This matters more than it sounds: with an external paywall, the gating UI is typically an iframe or a redirect to someone else's domain. Here, the paywall is just your template, so it looks like your site because it is your site.

Where native membership falls short

The trade‑off is flexibility. Ghost's model is deliberately simple, and several common asks fall outside it:

• Complex reward structures. If you want per‑tier physical merch, Discord role sync, or pay‑per‑post, a dedicated platform like Patreon handles that out of the box; Ghost doesn't.
• Billing edge cases. Trial periods, proration behavior on tier changes, coupons, and tax handling are largely delegated to Stripe. Some are configurable in Stripe directly, but anything beyond that means custom work against the Ghost and Stripe APIs.
• Payment processor lock‑in. Native paid memberships assume Stripe. If Stripe doesn't operate in your country or you need PayPal‑first checkout, you're building a custom integration.
• Self‑hosting email. Magic‑link login and member newsletters require working bulk email (Mailgun is the supported path for newsletters). Misconfigured transactional email is the single most common reason self‑hosted membership setups appear "broken" — members can't log in because the sign‑in email never arrives.

None of these are dealbreakers for a simple paid tier, but they define the boundary where you should evaluate external tools instead.

Before you launch

If your model fits the native shape — a free tier plus one or two paid tiers, gated posts, Stripe available in your market — enable membership on a staging or local install (ghost install local on your own machine), run the Stripe test‑mode flow end to end, and check three things: the paywall appears for logged‑out visitors, a test subscriber can read gated posts after paying, and transactional emails actually land in an inbox. If all three pass, you can skip the third‑party middleware and keep your subscriber data, your revenue flow, and your design in one system. That's the real win: fewer moving parts between your readers and your paywall.