Substack cost vs self-hosted Ghost

The break-even point is a calculation you run on your own numbers, and it starts from one rule: self-hosting pays off once the share you save exceeds your fixed monthly cost of running Ghost. Take your fixed recurring costs (server or cloud instance, backups, email delivery volume you expect to pay for, monitoring, and the share of your engineer's time you can actually allocate to upkeep) and divide them by the effective share you save. The effective share is Substack's platform share minus nothing, because card processing and Stripe fees apply in both cases and cancel out of the comparison. What remains is the platform cut that Ghost does not take on paid subscriptions, expressed as a percentage of gross subscription revenue. Ghost's pricing page lists its hosted plans for comparison, and the Ghost(Pro) figures there are a useful reference point for what managed hosting costs before you decide to run it yourself.

Keep the one-time costs separate from the recurring ones. Migration work, such as exporting from Substack, moving members and reconnecting the Stripe account, and setting up redirects, is a single outlay. Spread it over the number of months you expect to stay on Ghost, then add that monthly amount to your recurring costs before dividing. A publication that expects to leave the platform within a year carries a much heavier monthly burden than one planning a multi-year run. Be honest about the time horizon, because the same migration can look cheap or expensive depending on it. Ask any implementation partner for the migration and maintenance effort as a written scope with deliverables, rather than estimating it from the cost of hosting alone.

Test the result against your own forecast, not a current snapshot. Model subscription revenue at the level you expect in twelve to twenty-four months, and check how sensitive the answer is to member churn and to plan mix. If the monthly revenue at which self-hosting equals the platform share sits well above what you realistically earn, the hosted option is probably the better fit. If it sits comfortably below, confirm the operational risks, including backups, upgrades across Ghost's frequent minor releases, and who responds when email delivery or payments fail, before committing. Those risks are the part of the calculation that a spreadsheet tends to leave out.

The cost comparison leaves out what Substack gives a writer for free, and that value is real. Substack's built-in discovery, including its recommendation network and in-app browsing, can bring readers to a publication without the writer doing anything. Self-hosted Ghost has no equivalent: a publication on your own domain is found through search, your own promotion, referrals from other writers and social channels, and each of those takes time and attention that a cost table does not show. Before you count the 10% share as the price of Substack, estimate how many new paid subscribers came from discovery in the last year. Your Substack dashboard and its referral data are the place to check that figure.

A second item with no line item is the hosted archive. Substack posts stay publicly reachable on its platform, and readers and search engines find them there regardless of what you do. When you move to Ghost, the archive lives on your domain, so you own the URLs but you also carry the SEO work of redirects and re-indexing. Ask your SEO adviser or check your search console data for how much traffic arrives at older posts, and plan redirects from the Substack URLs before the cutover. The migration guide for moving posts and members is covered in the sibling migration topic.

Finally, simplicity has value that is hard to price. Substack needs no server, no database, no mail configuration and no upgrade calendar. A solo writer who publishes weekly may not want to answer for uptime, Node.js updates or a failed Ghost-CLI upgrade, and that time is a cost even if no invoice shows it. Weigh the decision against your own hours, and if you move, consider whether a managed Ghost(Pro) plan or a partner-run install suits you better. For a feature-by-feature view of what Ghost does and does not match, read the sibling topic on Substack versus Ghost before deciding.

The one-time work of moving from Substack to self-hosted Ghost falls into five parts: exporting the Substack content and subscriber data, importing it into Ghost, reconnecting payments, pointing your domain and redirects at the new site, and testing before readers see the change. Most of the cost sits in the people doing the work and in the planning time around the cutover, not in software licences. Ghost itself is MIT-licensed, so the migration does not add a licence fee. Ask any implementation partner to price these five parts separately so you can see which ones your team could absorb and which ones need specialist hands. The sibling migration topic walks through the export, the migrator and the Stripe steps in more detail.

The most sensitive part is payments. Paid subscribers keep paying only if the same Stripe account is connected to the new Ghost site, so the decision to make early is whether the existing Stripe account stays as the system of record. Confirm with your finance lead how Substack's payouts currently reach your bank, how refunds and failed payments are handled, and who holds the Stripe administrator role. Ghost takes no transaction fee on paid subscriptions, but Stripe processing fees still apply, so the payment connection is also where the cost comparison becomes concrete. Plan a window in which subscribers are not charged twice or dropped, and test it with a small group of members first. Domain work and testing are where readers notice problems. Ghost imports posts and members through its migrator, but the Ghost WordPress documentation shows that some content types do not carry across, and you should expect the same kind of gap with Substack-specific embeds, so review a sample of posts by hand. Set up redirects from the old Substack URLs to the new Ghost URLs, confirm that email links and archive links still resolve, and verify the sending domain and email authentication records before the first live send. Ask your implementer to write these checks into the statement of work, with a written acceptance step, so that the cost of rework is visible before the work starts.