Short answer: WordPress itself is free, but a working blog isn't. Once you add managed hosting, an SEO plugin, a page builder, caching and a membership or newsletter tool, a single serious WordPress blog typically lands between \(600 and \)900 a year in 2026, before any percentage fees on paid subscriptions. A budget shared-hosting setup can run under $200 a year, but you give up speed, security and support to get there.

"WordPress is free" is true and misleading at the same time

WordPress the software costs nothing. You can download it today and install it on a $5 server. That's the part everyone repeats.

Here's the part most cost breakdowns skip: WordPress out of the box is a text editor with a theme. It doesn't do SEO properly, it doesn't cache, it doesn't send newsletters, it doesn't take payments and it doesn't build landing pages. Every one of those jobs is a plugin, and the good plugins are paid, per site, per year. The real question isn't "how much does WordPress cost." It's "how much does the WordPress you'd actually publish on cost."

This guide adds it up with dated prices from vendor pages, then shows where the number swings depending on the choices you make. If you'd rather see the same question framed as a head-to-head, the VeloCMS vs WordPress page covers the trade-offs.

What you're actually paying for

Think of a WordPress blog as five bills that arrive at different times.

Hosting. This is the one recurring cost you can't avoid. Managed WordPress hosts handle updates, backups and security for you. As of Aug 2026, Kinsta's single-site Starter plan lists at \(30/month on annual billing (about \)35/month monthly), and WP Engine's entry plan sits around \(20/month. Budget shared hosting from the likes of Hostinger or Bluehost is often advertised at \)3 to $8/month, but that's usually a first-term promo that renews higher, and you're doing your own patching. See how the two premium hosts compare on their own pages: Kinsta and WP Engine.

SEO. Yoast SEO Premium is the default choice for most blogs. As of Aug 2026, Yoast lists Premium at \(118.80 per site per year (ex VAT), up from the \)99 rate that held through mid-2026; the new price folds in the Local, News and Video SEO add-ons that used to cost \(79 each. Rank Math Pro is the usual cheaper alternative at \)79/year for unlimited personal sites.

Page builder. The free block editor is fine for posts and poor for landing pages, so most sites add a builder. Elementor Pro's Essential plan lists at \(59/year for one site as of Aug 2026, with Advanced Solo at \)79/year if you want the full widget set. Read the Elementor comparison for what that money buys.

Speed. A page-caching plugin is close to mandatory on shared hosting and still common on managed hosts. WP Rocket lists at $59/year for a single site as of Aug 2026, with no free tier. Some managed hosts include server-side caching, which lets you skip this line.

Monetisation and email. This is where the bill stops being predictable. A membership plugin, a newsletter plugin or email service, a form builder and an anti-spam tool each carry their own licence. Prices vary widely by list size and features, so check the vendor page for the exact tools you'd pick. The point for budgeting is that each one is another renewal on a different date.

The 2026 bill, three ways

The "standard serious blog" column is the one most bloggers land in after a year. Not because they're extravagant, but because each free tool eventually hits a wall (no redirects in free Yoast, no theme builder in free Elementor, no real caching on a \(4 host) and the paid upgrade fixes it for \)59 here and $118 there.

The costs that don't show up on any invoice

Money is the visible half. Three other costs decide whether a WordPress blog is cheap or expensive.

Renewal creep. Most plugin and hosting prices are introductory. Shared hosting advertised at $3/month often renews at two to four times that. Yoast is one of the few that charges the same at renewal; many others don't. Your year-two bill is the honest one.

Conflict time. Eight plugins from eight vendors means eight update schedules and a real chance that one breaks another. If you value your time at even \(30/hour, a couple of hours a month on updates, patches and "why is the checkout blank" is \)700 a year on its own.

Security exposure. Every plugin widens the attack surface. Managed hosts partly cover this, which is exactly why they charge \(30/month instead of \)5.

How an all-in-one plan changes the math

The alternative isn't "WordPress but cheaper." It's a platform where the SEO scoring, page builder, caching, newsletters, memberships and commerce are part of the product, so the plugin column goes to zero and the renewal dates collapse into one.

VeloCMS is built that way: block editor, page builder, AI SEO scoring, newsletter segments, paid memberships and native commerce ship without add-ons, payments run through your own Stripe account at a 0% platform fee, and the site is built to a sub-second LCP budget without a caching plugin. Current plan prices are on the pricing page; the whole side-by-side matrix, including Ghost, Substack and Squarespace, is on the compare page.

Compare that to the "standard serious blog" column above. The hosting line disappears (it's included), the four plugin lines disappear, and what's left is one subscription. Whether that's cheaper for you depends on which column you're really in, which is the honest part of this decision.

When WordPress is still the better choice

A cost guide that pretends WordPress always loses isn't worth reading. There are real cases where the plugin tax is worth paying.

1. You need a plugin that only exists on WordPress. The ecosystem is 20 years deep. If your blog depends on a specific LMS, booking system, multilingual plugin or industry integration, WordPress has it and most platforms don't.
2. You already have a developer. If someone on your team maintains WordPress for a living, the conflict-time cost drops to near zero and self-hosted WordPress on a cheap VPS can be the lowest-cash option available.
3. You want full server access. Custom PHP, custom database tables, unusual caching layers, on-prem hosting for compliance reasons. WordPress gives you the whole machine.
4. Your blog is tiny and static. One author, a few posts a month, no memberships, no store. Free Yoast, the block editor and \(4 shared hosting will do, and the \)100/year column is real.
5. You need WooCommerce at scale. For a large physical-product catalogue with complex shipping and tax, WooCommerce remains one of the most flexible options, plugin costs and all.

If you're in one of those five, stay put. The point of this guide is that most bloggers aren't, and they're paying the standard column without ever having added it up. If you want to see what your current stack would cost on one plan, the pricing page lays it out, and every plan starts with a 14-day free trial (card required).

Frequently asked questions

How much does a WordPress blog cost per year in 2026?

A budget WordPress blog on shared hosting with free plugins costs roughly \(100 to \)200 a year. A typical serious blog with managed hosting (Kinsta Starter at \(30/month as of Aug 2026), Yoast Premium (\)118.80/yr), Elementor Pro (\(59/yr) and WP Rocket (\)59/yr) lands between \(750 and \)900 a year before membership or email tools.

Is WordPress really free?

The WordPress software is free and open source. Hosting is never free, and the plugins most blogs rely on for SEO, page building, caching, forms, memberships and newsletters are paid, usually per site per year. "Free" describes the download, not the running cost.

What is the cheapest way to run a WordPress blog?

Shared hosting on a promotional rate, free Yoast, the built-in block editor, a free caching plugin and no paid memberships. Expect roughly \(100 to \)200 a year, and expect the hosting price to rise at renewal. You trade money for your own time on updates and security.

How much do WordPress plugins cost in total?

For a standard blog, the four common paid plugins cost about \(296 a year as of Aug 2026: Yoast Premium \)118.80, Elementor Pro Essential \(59, WP Rocket \)59, plus a membership or newsletter tool that varies by vendor. Agencies running multiple sites pay per site unless they buy multi-site licences.

Does an all-in-one CMS actually save money over WordPress?

It depends on which column you're in. If you're paying for managed hosting plus three or four premium plugins, an all-in-one plan that includes hosting, SEO, builder, caching, newsletters and memberships usually costs less and removes renewal creep and plugin conflicts. If you run a small static blog on free tools, WordPress can still be cheaper in cash.

Does WordPress charge a fee on paid memberships?

WordPress itself doesn't, and neither does VeloCMS. Both let you connect your own Stripe account at 0% platform fee. That's different from newsletter platforms like Substack, which takes 10% of paid subscriptions, or Patreon at 5% to 12% depending on plan. See the Substack comparison for that side of the decision.

Short answer: Substack is free to run but takes 10% of paid subscription revenue forever. Ghost(Pro) Publisher starts at \(29/month billed yearly with a 0% platform fee, and Beehiiv Scale starts at \)43/month billed yearly, also at 0%. Below roughly \(300 to \)500 a month in paid revenue, Substack is cheapest. Above that, the flat-fee platforms keep more, and the gap widens every month you grow.

Three platforms, three different bets on your money

The three most-recommended paid newsletter platforms in 2026 price themselves in three different ways, and that's the whole decision.

Substack bets that you'll start free and never leave, so it charges nothing up front and a percentage forever. Ghost bets that you're a publisher who wants to own the site as much as the list, so it charges a flat monthly fee that rises with your member count. Beehiiv bets that you're building a newsletter business with ads and referrals, so it charges a flat fee by subscriber count and layers growth tools on top.

None of those bets is wrong. Which one is right for you depends on two numbers: how much paid revenue you have today, and how large your free list is. This guide runs both. All prices were read from vendor pricing pages in July and August 2026; they change, so check the page before you commit.

What each platform actually is

Substack is a hosted newsletter and publication platform with a built-in reader network, notes, podcasts and video. It's free to use at any list size. On paid subscriptions, Substack takes 10% of revenue, and Stripe's processing fee (about 2.9% + \(0.30 per transaction) comes out on top. There's no plan to upgrade to and no way to reduce the percentage. Custom domains cost a one-time \)50 fee. You get discovery from the network, which for many writers is the real reason to be there.

Ghost is an open-source publishing CMS with newsletters and memberships built into the same product. You can self-host it for free (Ghost's own docs estimate a realistic self-hosted setup at around \(72/month once you add email delivery, CDN and backups) or use the managed Ghost(Pro). As of July 2026, Ghost(Pro) Starter is \)15/month billed yearly (\(18 monthly) for up to 1,000 members but no longer supports paid subscriptions. Publisher, the plan you need to charge readers, is \)29/month billed yearly (\(35 monthly) at 1,000 members and scales with your list, reaching about \)88/month at 10,000 members. Platform fee on subscriptions is 0% on every plan.

Beehiiv is a newsletter-first platform built by former Morning Brew engineers, with a landing page builder, referral program, an ad network and recommendation network. As of July 2026, the Launch plan is free up to 2,500 subscribers but doesn't include paid subscriptions. Scale starts at \(43/month billed yearly (\)49 monthly) and unlocks monetisation; Max starts at \(96/month billed yearly (\)109 monthly) and removes Beehiiv branding. Prices step up by subscriber bracket: a list that just passed 2,500 subscribers lands at about $77/month on Scale billed yearly. Platform fee on paid subscriptions is 0%.

Side-by-side comparison

The real question: what do you pay at each revenue level?

Percentage fees and flat fees cross over. Here's where, using Ghost Publisher and Beehiiv Scale at their entry brackets, yearly billing, and Substack's 10%. Stripe is left out because all three pay it.

\(200/month in paid revenue (say 40 readers at \)5). Substack takes \(20/month, or \)240/year. Ghost Publisher costs \(348/year. Beehiiv Scale costs \)516/year. Substack wins clearly.

$1,000/month in paid revenue. Substack takes \(100/month, or \)1,200/year. Ghost is still \(348/year at up to 1,000 members. Beehiiv is \)516/year up to its entry bracket. Both flat-fee platforms now save you \(700 to \)850 a year.

$5,000/month in paid revenue. Substack takes \(500/month, or \)6,000/year. By now your total list is probably past 1,000, so Ghost Publisher might be \(50 to \)88/month (\(600 to \)1,056/year) and Beehiiv Scale roughly \(77 to \)109/month (\(924 to \)1,308/year). Either way, you keep \(4,500 to \)5,400 more per year than on Substack.

The break-even sits around \(300 to \)500 a month in paid revenue, depending on which platform and bracket you'd land in. Below it, pay the percentage and enjoy the free ride. Above it, the percentage becomes the most expensive line in your business.

One thing the table hides: Ghost counts free members toward your plan bracket, and Beehiiv counts all active subscribers. A newsletter with 9,000 free readers and 300 paying ones pays Ghost's 10,000-member rate. Substack doesn't care how big the free list is. If your free-to-paid ratio is very high, that shifts the break-even upward.

Migration: what moves and what doesn't

All three let you export subscribers as CSV, so the list is never trapped. Paid subscriptions are the sticking point: Stripe customers can be transferred between platforms if the destination supports importing existing Stripe subscriptions (Ghost and Beehiiv both document this), but readers on Substack may need to re-enter payment details depending on how the migration is handled. Plan a week of overlap and expect a few percent of churn. Content moves as posts or JSON; Substack's reader network does not move at all.

When each platform is the better choice

Choose Substack if:

1. You have little or no paid revenue yet and want zero fixed cost while you find out whether readers will pay.
2. Discovery matters more than margin. Recommendations and Notes still bring new readers in a way the other two can't replicate.
3. You want podcasts, video and text in one place without stitching tools together.

Choose Ghost if:

1. You want a real website as well as a newsletter: pages, themes, tags, structured content, on your own domain, with nothing that says "Ghost" unless you want it to.
2. You value the exit. Open source means you can move from Ghost(Pro) to your own server, or back, without asking anyone.
3. Your paid revenue is past a few hundred dollars a month and your free list isn't enormous relative to it.

Choose Beehiiv if:

1. Your model is ads and sponsorships rather than (or alongside) paid subscriptions. The ad network is the reason most Beehiiv publishers are there.
2. You want built-in referral and recommendation growth loops without third-party tools.
3. Your list is under 2,500 and you want a free plan that includes a landing page and custom domain while you grow.

If you want all three of those things (a full CMS, 0% fees and newsletter segments) in one subscription, that's the category VeloCMS sits in; the compare page shows it next to Substack and Ghost, and the individual Substack, Ghost and Beehiiv comparisons cover the trade-offs in detail. If you'd rather run your own numbers first, the compare page is the place to start.

Frequently asked questions

Does Substack take a percentage of paid subscriptions?

Yes. Substack takes 10% of paid subscription revenue on every plan, and Stripe's processing fee (about 2.9% + $0.30 per transaction) applies on top. There's no paid tier that lowers the percentage. Free newsletters cost nothing to run.

How much does Ghost cost for a paid newsletter in 2026?

As of July 2026, the Ghost(Pro) Publisher plan starts at \(29/month billed yearly (\)35 monthly) at 1,000 members and scales with your list, to about \(88/month at 10,000 members. Platform fee on subscription revenue is 0%. The cheaper Starter plan (\)15/month yearly) no longer supports paid subscriptions.

How much does Beehiiv cost for a paid newsletter in 2026?

As of July 2026, paid subscriptions need Beehiiv's Scale plan, which starts at \(43/month billed yearly (\)49 monthly) and steps up by subscriber bracket, reaching about \(77/month yearly once you pass 2,500 subscribers. Max, from \)96/month yearly, removes Beehiiv branding. Platform fee on paid revenue is 0%.

At what revenue does Substack become more expensive than Ghost or Beehiiv?

Roughly \(300 to \)500 a month in paid subscription revenue. At \(1,000/month, Substack's 10% costs \)1,200/year versus about \(348/year for Ghost Publisher or \)516/year for Beehiiv Scale at their entry brackets. The gap grows with revenue.

Do free subscribers cost money on Ghost or Beehiiv?

Yes. Ghost prices Publisher and Business by total members, free and paid combined. Beehiiv prices Scale and Max by total active subscribers. A large free list pushes you into a higher bracket even if few readers pay. Substack charges nothing for free subscribers.

Can I move my paid subscribers from Substack to Ghost or Beehiiv?

Subscriber lists export as CSV from all three. Existing Stripe subscriptions can be imported into Ghost and Beehiiv, but the process depends on how the payments were set up on Substack, and some readers may need to re-enter card details. Expect some churn during the move and plan an overlap week.

The instinct, for most of us, is to reach for Shopify. It's the obvious answer, the one every "how to sell online" guide points you toward. But bolting a full e-commerce platform onto a blog you already built somewhere else is its own project — a new subdomain, a second design system to maintain, an embed widget that looks like it got airlifted in from a completely different website, because, well, it did. You end up paying a monthly platform fee for a store that doesn't match your blog, plus a cut on every sale, plus the quiet tax of switching between two admin panels every time you want to change a price.

There's a simpler version of this. What if the shop wasn't bolted on at all — what if it just lived there, using the same theme, the same nav, the same voice, because it's the same site?

Why does bolting Shopify onto a blog you already built feel like duct tape?

Because it is duct tape. Most "add a store to your blog" tutorials walk you through embedding a Shopify Buy Button, or an iframe, or a widget script — and every one of those approaches has the same tell. The typography doesn't match. The button radius is off by a few pixels from everything else on the page. The colors were picked for a generic storefront template, not for the specific, deliberate aesthetic you spent a weekend tuning. Readers notice, even if they can't say exactly why. A mismatched shop reads as an ad, not a product you're proud of.

The deeper issue is architectural. Shopify (and most standalone store builders) are designed to be the entire website. Your blog is an afterthought bolted onto their system, not the other way around. So when you already have the blog — the content, the SEO, the years of archive — and you just want to add selling on top, you're forcing two products that were never meant to share a roof to somehow cohabit. One of them always loses the design argument, and it's never the store.

What does a store built into your own theme actually look like?

VeloCMS takes the opposite approach: the shop isn't a separate app you embed, it's a rendering surface your theme already owns. Under the hood, the platform hands your active theme a plain, structured feed of your products, prices, and cart state — what we call the raw-data shop contract — and the theme decides how to actually draw it. That's the whole trick. Nobody hand-designed 38 individual storefronts; every theme's designer just extended the visual language they'd already built for posts and pages into commerce, using the same data every other theme gets.

You can see the difference immediately when you put two themes side by side. Here's Maker Supply Co., running the Terminal theme — dark background, monospace type, a shop rendered like a command-line directory listing, right down to the "grep --query" search field:

And here's Atelier Lumen, running the Atelier theme on the exact same underlying commerce engine — light background, a large serif "Shop" headline, soft category pills, product cards with generous whitespace:

Same product grid, same filters, same cart. Neither one looks like a plugin. Neither one looks like the other.

How do you actually start selling products on your blog?

There's no separate onboarding flow to learn. From your VeloCMS admin, you flip commerce on for the tenant, and a Shop link appears in your nav automatically — themes pick it up without you touching a template file. From there you add your first product, choosing digital (a PDF, a Notion template, a video course you deliver instantly on purchase) or physical (something that needs a shipping address and, eventually, a tracking number). Pricing, a description, and a cover image are all you need to get a product live.

The part that actually matters for your margin comes next: connecting a payment processor. VeloCMS is BYOK here — bring your own keys — so you link your own Stripe or PayPal account directly, and money from a sale lands in your account, not ours, with 0% platform commission taken off the top. No revenue share, no waiting period, no third party sitting between you and your buyer's card. If you'd rather not build a full catalog yet, gift cards are built in too, which turns out to be a surprisingly good way to test whether your audience is willing to spend money on you at all before you commit to inventory.

Does every one of VeloCMS's 38 themes really look different?

It's worth pushing on this claim, because "every theme is unique" is the kind of thing marketing copy says about everything. Here's Chloe Noir, running the Velvet Editorial theme — a warm, cream-and-blush fashion-magazine aesthetic, italic serif headline, product cards that look like they belong in a print catalog rather than a checkout flow:

Put this next to the Terminal and Atelier screenshots above and you're looking at three completely different visual systems rendering identical underlying data: same product titles, same prices, same cart logic. That's the raw-data shop contract doing its job — the theme decides the shape, not the commerce engine.

What happens when a reader actually wants to buy something?

For a digital product, checkout is fast: the reader pays through your connected Stripe or PayPal, and delivery happens instantly — a download link, an access grant, whatever you configured. For a physical product, you collect a shipping address at checkout the same way, and fulfillment is on you, exactly like it would be anywhere else. The cart itself lives quietly in the corner of your theme's nav, the same one your readers already recognize, so buying something never feels like leaving your site.

If you'd rather watch this than read about it, here's a short walkthrough across a handful of the 38 themes, shop pages included:

▶ Watch the demo — 38 blog themes in five minutes — including how each one renders its own shop.

None of this requires you to abandon the blog you've spent years building, or to learn a second platform's admin panel, or to hand a chunk of every sale to a company that's never read a word you've written. The shop is just another part of the site your readers already trust. If you want to see it on your own blog, start a 14-day free trial and turn commerce on from the dashboard — the theme you're already using will handle the rest.

Building your own home online feels like a monumental task, but it's more achievable than you think. It's not about becoming a web developer overnight. It's about a focused, three-month push to build a foundation for a business that can sustain your art for years. Let's walk through what that actually looks like.

Days 1-30: The Brutal Edit and a Solid Foundation

The first month is all about laying the groundwork. And let's be honest, the hardest part isn't the technology—it's the edit. Culling years of work down to a cohesive, powerful portfolio is an agonizing but essential process. It's tempting to show everything, but curation is what separates a professional gallery from a camera roll. This is where you have to be ruthless. Your portfolio should be a short, powerful sentence, not a rambling paragraph.

Here's a piece of data that might help you make those tough choices: in the fine art world, it's widely understood that about 80% of a photographer's print revenue will come from just 20% of their images. The Pareto principle is alive and well. Your job in this first month is to make an educated guess about which images belong in that top 20%. These are your hero shots, the ones that define your style and your point of view. Lead with them.

Once your edit is locked in, getting the site live is the next step. You need a platform that puts your images front and center without compressing them into oblivion or hitting you with surprise bandwidth bills. This is why we built VeloCMS with native Cloudflare R2 storage—it's designed to handle massive, high-resolution files without breaking a sweat (or your bank account). You can upload your best work and know it will load fast and look stunning. Alongside your gallery, set up a simple blog. This isn't for sharing vacation photos; it's your long-term SEO engine. Write about the story behind a specific photo, the gear you used for a particular series, or the location that inspired you. These posts are magnets for search traffic and people who are genuinely interested in your craft.

Days 31-60: Opening the Shop and the First Sale

With your digital gallery walls up, month two is about unlocking the door and putting a price on the work. This is where many artists get stuck. How do you price a photograph? You can go the simple route: (cost of printing + cost of shipping) + your desired margin. It's a clean, logical formula. But are you selling paper and ink, or are you selling a piece of your vision, a story, a moment that can never be repeated?

This is the argument for value-based pricing. Your price should reflect the skill, time, and artistic sensibility that went into creating the image. It positions you as an artist, not just a print-shop operator. Start with a few of your strongest pieces. Offer them in a limited run, maybe signed and numbered, in one or two standard sizes. Don't overwhelm visitors with a dozen different paper types and framing options. Keep it simple and elegant.

And then, you wait. The days or weeks leading up to the first sale can be nerve-wracking. You'll check your analytics, you'll tweak your product descriptions. Then, one day, you'll get that first email notification. That first sale is rarely about the money. It's pure validation. It's proof that someone out there connected so deeply with your work that they wanted to make it a physical part of their life. Don't underestimate how powerful that feeling is. It's the fuel for everything that comes next.

Days 61-90: From Visitors to Collectors

One sale is a victory. A sustainable business is a system. Month three is about building that system. You can't just hope the next person stumbles upon your site; you have to build a way to stay in touch. This is the crucial difference between a casual visitor and a true collector. Collectors want a relationship with the artist. The best way to build that is with an email list.

Your email list is the only audience you truly own—it's immune to algorithm changes on Instagram or Facebook. Add a simple, non-annoying signup form to your site. Promise them first access to new series, stories behind the work, and maybe an exclusive print offering every now and then. Your newsletter isn't a sales circular; it's a letter from your studio. It's where you share your process and your passion.

For your most dedicated fans—the ones who reply to your emails and ask about your technique—you can offer something even deeper. This is where a modern CMS can really shine. VeloCMS has a built-in paywall feature that lets you protect certain posts or pages for members only. You could create a section for a small monthly fee that gives collectors access to behind-the-scenes videos, essays on your creative process, or even digital contact sheets. It's an incredible way to serve your biggest supporters and generate a predictable, recurring income stream that isn't tied to one-off print sales.

This 90-day framework isn't a magic formula, but it is a focused plan. It moves you from simply having a portfolio to running a photography business on your own terms. We've thought a lot about what photographers need to make this leap, building tools that support the art, not just the transaction. It's a different approach, and you can see a full breakdown of how we're building a better home for your work in our guide for photographers. The goal is independence—artistic and financial. And that's a project worth investing in.

You hit publish on your first post, the URL resolves, and technically, yes, your blog is "live." But live and ready aren't the same thing, and most of the gap between them is invisible from the inside. You don't notice a newsletter sender domain that never got verified — until a batch of emails lands in spam and you spend an evening wondering why. You don't notice a custom domain sitting in "pending" for three days over one bad DNS record. The point of a launch-readiness check is to surface exactly the stuff you'd otherwise only discover from a reader.

What does "ready to launch" actually mean for a blog?

It's less a single moment than a short list of things that are each individually easy to skip. Some of it is content — a post actually published, a theme switched on, a real description instead of a placeholder. Some of it is discoverability — the SEO basics filled in, a custom domain (if your plan includes one) actually verified rather than just added. Some of it is the stuff readers never see until it breaks — a newsletter sender domain, a payment provider, whether your legal pages still say exactly what the default template said on day one. None of it blocks you from publishing. Together, it's the difference between "I have a blog" and "my blog is set up the way I meant it to be."

Where do I find my launch-readiness checklist?

Open your dashboard and look at the sidebar — Setup Assistant lives at /admin/setup as its own permanent page, not a banner that shows up once and vanishes the moment you dismiss it. That's a deliberate change from how this used to work. The old onboarding checklist only appeared on your first login and disappeared for good once you closed it, which meant there was nowhere to go back and ask "wait, is everything still okay?" three months later, after you'd switched newsletter providers or your domain's SSL quietly lapsed. Setup Assistant re-checks everything live, every time you open the page.

At the top, instead of a single percentage, you get an honest three-part count: how many checks are passing, how many need your attention, and how many it simply couldn't verify right now. That last category matters more than it sounds. A percentage that includes a database hiccup as a failure is lying to you about your own work; a page that says "we couldn't check this, try again" is telling you the truth about what it actually knows.

What does the Setup Assistant actually check?

It's organized into five groups, and none of them are theoretical — each maps to something a reader would eventually notice if it stayed broken. Foundation covers the basics: a published first post, an active theme, a real blog description. Reach looks at whether search engines and social previews have anything to work with — SEO defaults filled in, social links added, and, on plans with custom domains, whether yours is verified rather than just entered. Audience is about your newsletter: a provider connected, and — the one that quietly bit people under the old checklist — a sender domain that's verified, not just switched on. Revenue checks whether a payment provider resolves if you've turned on the store, and whether Stripe is connected for paid memberships. Integrity has one deliberately gentle check: whether your privacy and terms pages have actually been edited, or are still running the seeded default text every blog starts with.

Two of those checks get flagged more urgently than the rest, and it's worth knowing which ones, because they're the pair that used to slip through unnoticed: a custom domain that's been added but never verified, and a newsletter provider that's switched on with a sender domain that hasn't been confirmed. Everything else nudges you toward "materially better" — genuinely worth doing, never an emergency. Your legal pages check, in particular, is graded as optional rather than urgent, on purpose. Every brand-new blog starts with the same seeded privacy and terms text, so if that check colored the whole page red on day one, it would just be noise for anyone who hasn't gotten around to their legal copy yet. It sits there quietly instead, waiting for the day you actually want to personalize it.

What does it mean when a check comes back "unknown" instead of pass or fail?

It means exactly what it says — the assistant tried to read the signal it needed and, for whatever reason (a momentary database hiccup is the usual culprit), it couldn't get a clean answer. This is the detail that makes the whole page trustworthy rather than just decorative. A checklist that quietly treats "I couldn't check" the same as "this failed" ends up telling a fully configured blog that it's done nothing at all, which is worse than useless — it's actively misleading. Setup Assistant keeps "unknown" as its own separate bucket in the count at the top, and if every single check comes back unknown at once (a full connectivity blip, effectively), the page says so plainly instead of showing you a wall of red. Refresh a moment later and it usually resolves itself.

How do I actually fix something it flags?

Every check that needs attention comes with a "Fix this" link, and it goes to the real settings screen that would resolve it — the newsletter check links to your newsletter settings, the custom domain check links to your domain setup screen, and so on. There's no dead end where the fix link dumps you on a generic settings page and leaves you to hunt for the actual control. If you're working through the domain checks specifically, our walkthrough on connecting a custom domain covers the DNS side in more detail than Setup Assistant's short summary needs to. Work through the list category by category, and once every check that applies to your blog is passing, the page tells you so — plainly, with its own small celebration, not a vague "all good" you have to take on faith.

Do I need a custom domain, or payments, before I'm "ready"?

Not necessarily — and this is where the checklist earns some trust rather than nagging you. Custom domain checks only show up if you're on a plan that includes one; if you're happily running on your velocms.org subdomain, they simply don't appear on your list at all. The same goes for payments and commerce: those checks only apply once you've actually turned that module on. Setup Assistant is scoped to what your blog is actually trying to be, not a generic checklist written for a hypothetical tenant running every feature at once. A photography blog with no store enabled will never see a payment-provider check demanding attention, because there's nothing there for it to demand.

Ready, in the end, isn't a certificate you earn once. It's a page you can go back to whenever something changes — a new plan, a new newsletter provider, six months of not thinking about your legal pages — and get an honest answer instead of a guess. If your blog's still finding its footing, or if you haven't started one yet, VeloCMS is available on a 14-day free trial, card required, no surprises — and Setup Assistant is there in your sidebar from the first login, quietly keeping score.

The good news is that the scary part of connecting one — the DNS records, the SSL certificates, the acronyms that read like radio static — has mostly been automated away. On VeloCMS, the whole process is one screen and a short visit to wherever you bought the domain. Here's the entire walkthrough, plus what's actually happening under the hood, so nothing about it feels like a magic trick you're afraid to touch.

Why does a custom domain matter for a blog?

Three reasons, in ascending order of importance. First, memorability: "myblog.com" survives being said out loud at a dinner table; a subdomain usually doesn't. Second, ownership: your domain is an asset you control, independent of any platform, and every link anyone ever shares accrues to something that's yours. Third — and this is the one people underrate — search engines treat your domain as the container for all of your reputation. Reviews, backlinks, mentions, years of posts: all of it compounds against one name. Starting that compounding early is one of the cheapest SEO decisions you'll ever make.

None of this means you need a domain on day one. Your blog is live on its velocms.org subdomain the moment you sign up, and that address keeps working even after you connect your own. But the earlier you make the switch, the less link equity you leave scattered behind you.

What do you need before you start?

Two things. A VeloCMS blog on any paid plan, and a domain you own — from literally any registrar. Namecheap, GoDaddy, Cloudflare, Porkbun, Google-Domains-refugee registrars, the one your uncle recommended in 2011: all fine. You don't transfer the domain to us, you don't change nameservers, and you don't need a hosting add-on. The domain stays exactly where it is; you'll just add a couple of DNS records to point it at your blog.

Both root domains (myblog.com) and subdomains (blog.mystudio.com) work, which matters if your main site lives elsewhere and you only want the blog on a subdomain.

How do you connect the domain in VeloCMS?

From your admin dashboard, head to the custom domain setup screen. It looks like this — one field, one button, and a note reminding you the subdomain keeps working if you'd rather do this later:

Type the domain exactly as you want visitors to reach it — root or subdomain — and click Add Domain:

That's the entire VeloCMS side of the job. The moment you add the domain, the platform provisions it through Cloudflare behind the scenes and shows you the exact DNS records to create at your registrar — copy-paste values, no guesswork.

What DNS records do you add at your registrar?

This is the part with the reputation, so let's demystify it. DNS records are just address-book entries: they tell the internet which server answers for your name. VeloCMS shows you precisely which entries to add for your specific domain, and they fall into two familiar shapes. A root domain gets a record pointing it at our edge; a subdomain gets a CNAME doing the same. There's also a small TXT record that proves to the certificate authority that you actually control the domain, which is what lets the SSL certificate get issued for you automatically.

You add those records in your registrar's DNS panel — usually under a tab literally called "DNS" — and then you wait. Propagation typically takes a few minutes, occasionally a few hours if your registrar is slow to publish. VeloCMS keeps checking in the background and flips your domain to verified the moment the records are visible. HTTPS comes with it; there is no certificate to buy, renew, or think about ever again.

While you wait, nothing breaks. Your velocms.org subdomain keeps serving your blog the whole time, so readers mid-scroll never notice the plumbing being connected beneath them.

What about the links people already shared?

They keep working. The subdomain doesn't die when your custom domain goes live — both addresses resolve to your blog, so old bookmarks, old newsletter links, and that one post that did numbers on X all still land where they should. Going forward, your custom domain is the address on your site's canonical tags and the one you should put on everything, but the transition costs you nothing you've already earned.

One quiet detail worth knowing: because the certificate and routing run through Cloudflare's network, your blog also picks up CDN-grade delivery on your own domain — the same sub-second page loads VeloCMS is built around, now under your name.

The whole thing — buying a domain excluded — takes maybe ten minutes, most of which is your registrar's dashboard loading. If your blog is still wearing its subdomain, start a 14-day free trial or open your dashboard, and give the work a name that's actually yours.

We've all been there. You get a call from a client—or worse, an automated alert at 3 AM—that their site is down, defaced, or sending out spam. You log in, heart pounding, and start the grim process of elimination. Disable all plugins. Re-enable one by one. It's almost always a plugin. Maybe it was an obscure one the client installed for a blinking-text widget, or maybe it was a popular one with a zero-day vulnerability. The specific culprit doesn't matter as much as the underlying cause.

The original sin of the WordPress ecosystem is that every plugin is just a bundle of PHP files running with the exact same permissions as the WordPress core itself. It's untrusted code, often written by a stranger with unknown skills and motivations, executing in the same process that handles your content, your users, and your database. There is no sandbox. There is no containment. A single poorly-written line in a free SEO plugin can read your wp-config.php file and hand over your database credentials to an attacker. That's not a bug; it's the design.

This technical problem is compounded by a broken economic model. A developer builds a genuinely useful plugin. It gets popular. Suddenly, they're on the hook for support, security patches, and compatibility updates for a user base of thousands, all for free. It's completely unsustainable. So what happens? The developer either burns out and abandons the project (creating a ticking security time bomb for everyone still using it), or they sell it. Often, the buyer is a private equity firm or a large plugin conglomerate that immediately guts the free version, plasters it with aggressive upsells, and slowly lets the code quality slide. The user is left holding the bag every single time.

Look no further than WooCommerce for the perfect case study in this sprawl. It's sold as a simple way to add a store to your site. But to build a functional, modern e-commerce operation, you don't just install WooCommerce. You need a plugin for Stripe payments. Another for advanced shipping calculations. One for subscriptions. Another for abandoned cart emails. One for custom product fields. Before you know it, you're juggling seven, ten, maybe fifteen different plugins from a dozen different vendors, each with its own update cycle, potential conflicts, and security surface area. Your simple store has become a fragile house of cards, and you're the one who has to live in it.

When we started mapping out VeloCMS, we knew we couldn't ignore the need for extensibility. But we also refused to repeat the mistakes of the past. The problem isn't the idea of plugins; it's the lazy, insecure implementation that has become the industry standard. Our approach starts by treating third-party code with the healthy suspicion it deserves.

We're building our plugin architecture around two core principles: isolation and explicit permissions. For isolation, we're designing the system to run third-party code in sandboxed V8 Isolates. Think of it like a secure container. A plugin lives and runs inside this little box, and it can't see or touch anything outside of it unless it's explicitly allowed to. If a plugin has a vulnerability, the damage is contained to its own sandbox, not your entire application. It's the difference between a leaky faucet in one apartment and a flood that brings down the whole building.

The second piece of the puzzle is what we're calling a capability manifest. Before you even install a plugin, it will have to declare exactly what it needs to do. Does it need to read posts? Does it need to write to a specific database table? Does it need to make an external network request to a third-party API? It's all listed in a plain-text file. This is fundamentally about consent. It puts the power back in the hands of the site owner, just like your phone asks for permission before an app can access your camera or contacts. No more silently installing a plugin that turns out to be scraping your user data.

This leads to an open-core model. The essential, high-stakes functionality—the stuff that absolutely needs to be secure and stable—will be built and maintained by our team as first-party features. For everything else, the sandboxed, permission-based plugin system will provide a safe way for the community to extend the platform. This is a core part of how we see ourselves as a serious WordPress alternative.

Now, for a dose of honesty. This secure plugin sandbox is a cornerstone of our v2 architecture. It is not shipped today. Building a truly isolated, high-performance runtime for untrusted code is a massive undertaking, and we're not going to cut corners. But we're not just waving our hands and making promises, either. The groundwork is being laid right now. The capability manifest specification is already part of our core design, shaping how we think about every feature we build. We believe in getting the foundation right first, something that many platforms forget in their rush to add features. You can see the work we're putting into that foundation over on our pages for developers.

Fixing the plugin problem isn't about having more plugins. It's about having better, safer ones. It's about creating an ecosystem where developers can build and distribute extensions without inadvertently putting users at risk, and where users can extend their sites with confidence. It requires a fundamental shift in thinking, moving from a model of implicit trust to one of explicit, verifiable permissions. It's a harder path, but it's the only way to build a CMS that's truly fit for the next decade.

But incubators, by their nature, are temporary. They're meant for starting, not for scaling. There comes a point in every successful newsletter's journey where the cozy convenience of Substack starts to feel less like a support system and more like a golden cage. That point, for many, is the 1,000-subscriber mark.

Why a thousand? It's a magic number. It's the moment your project often transforms from a hobby into a potential business. It's the point where you've proven product-market fit. People are not only reading your work, but they're willing to pay for it. And it's precisely at this milestone that Substack's business model begins to work against you.

Let's do some back-of-the-napkin math. Say you have 1,000 paying subscribers at a pretty standard \(10 a month. That's \)10,000 in monthly revenue, or \(120,000 a year. It's a fantastic, life-changing amount of money for an independent writer. Substack takes a 10% cut of that. So, you're paying them \)1,000 a month, or $12,000 a year, just for the privilege of using their platform. And remember, that's before Stripe takes its own processing fee (usually around 2.9% + 30¢ per transaction).

Suddenly, that "free" platform is your single biggest business expense. The question you have to ask yourself is: what am I getting for that $12,000? Early on, the answer is "discovery." Substack's network and recommendation engine can be a huge boost. But once you have 1,000 dedicated readers, where is your next subscriber really coming from? Is it the Substack homepage, or is it from your own guest appearances on podcasts, your social media presence, and—most importantly—your existing readers sharing your work? For most established writers, the engine of growth is their own brand, not the platform's algorithm.

This leads to the thornier issue: ownership. When your business is built on someone else's platform, you don't truly own it. You're a tenant, not a homeowner. You can export a CSV of your email list from Substack, which is better than nothing, but it's not the whole story. You don't own the payment relationships. You don't own the design. You're subject to their terms of service, their content moderation policies, and their future business pivots. If Substack decides to change its algorithm, raise its fees, or gets acquired by a company with different priorities, your business is at their mercy.

True ownership means controlling the core assets of your business. It means your subscriber data is yours, period. It means the revenue flows directly from your readers into your bank account, without a middleman taking a hefty percentage. This is where moving to a platform like VeloCMS comes into the picture.

With VeloCMS, you bring your own keys (BYOK) to Stripe. When a reader subscribes, the payment goes straight to your Stripe account. We never touch your money. That 10% platform fee vanishes. Our model is a predictable, flat fee that you can see on our pricing page, which doesn't penalize you for growing. That $12,000 you were paying to Substack? It's back in your pocket, where you can reinvest it in your business, hire an editor, or just, you know, live on it.

I know what you're thinking—migration sounds like a nightmare. We've worked hard to make it as painless as possible. You export your list from Substack and import the CSV into VeloCMS. To handle the paid subscribers, we use a magic link re-authentication process. Your readers get an email, click a link, and their subscription is seamlessly moved over. They don't have to create a new account or re-enter their credit card details. It just works.

And the ownership goes further than the export button. VeloCMS runs on a flat fee with no revenue cut at any subscriber count, which means the math that made Substack expensive at 1,000 subscribers just doesn't happen here — you don't watch your platform bill climb in lockstep with your success. Your subscriber data, your posts, your media: all of it is yours, and you can pull a full export of everything, any time, straight from the dashboard. No support ticket, no waiting period, no proprietary format designed to make leaving annoying.

The trade-off, if you can call it that, is that you take on a little more responsibility for your own discovery than a marketplace-style platform hands you. It's a step up in complexity from Substack's all-in-one simplicity. But at 1,000 subscribers, you're ready for that step. You're no longer just a writer; you're a business owner. For a more detailed breakdown of the differences, our Substack comparison page lays it all out.

Graduating from Substack isn't a knock against it. It's a sign that you've succeeded on the very terms it enabled. You built an audience so loyal and a product so valuable that it no longer makes sense to pay a five-figure tax for the training wheels you've long since outgrown. It's time to own your work, own your audience, and own your revenue.

This week that tax gets a lot smaller. VeloCMS now has an official community node for n8n — the open-source automation platform — and an MCP server that lets AI tools like Claude work your blog directly. Both talk to the same public REST API, both authenticate with a single scoped API key from your dashboard, and both were built by us, not a third party guessing at our endpoints.

What can you actually automate with the n8n node?

The node covers the things a real publishing workflow needs: create a post, publish it (immediately or as a draft for review), update or fetch existing posts, and upload media. There's a companion trigger node too, so a workflow can start from your blog instead of ending there — a new post goes live and n8n fans it out to wherever you want the news to travel.

The workflows practically write themselves once the node exists. A form submission becomes a draft for your review. A row added to a spreadsheet becomes a scheduled post. A new post triggers a message to your community. If you've used n8n at all, you already know this shape — the node just makes your blog one of the thousand-plus things it can wire together.

How do you connect n8n to your blog?

Two steps, and neither involves code. First, install the node: in n8n, open Settings, choose Community nodes, and install n8n-nodes-velocms by name.

Second, create a credential. In your VeloCMS dashboard, go to Settings and open API Keys, generate a key (it starts with velo_ and you scope what it's allowed to touch), then paste it into the node's credential form along with your blog's URL. n8n's built-in credential test tells you on the spot whether the connection works — no publishing a test post to find out.

Here's the whole thing end to end — install, credential, first post, and an AI agent reading the blog — in about a minute:

▶ Watch the demo — Installing the VeloCMS node, connecting a credential, publishing a post, and handing the blog to an AI agent — in about a minute.

Can an AI agent run your blog?

This is the part that surprised us in testing. The node is marked as usable by n8n's AI Agent, which means an agent can pick up your blog as a tool — read what's published, draft something new, publish it — as one step in whatever reasoning loop you've given it. You describe the job in plain language; the agent decides when touching the blog is the right move.

That's a different proposition from a fixed automation. A workflow does the same thing every time. An agent with your blog as a tool can summarize the week's posts into a digest, or notice a gap and draft something to fill it — and you still hold the publish gate if you route its output to drafts.

What if you'd rather stay in Claude?

Not everyone wants a workflow canvas. If your writing already happens in Claude Code, Claude Desktop, or Cursor, the MCP server is the shorter path: run npx @velocms/mcp with your API key and your assistant gets twelve tools against your blog — drafting and publishing posts, uploading media, moderating comments, managing members, reading site settings. You finish a piece in conversation, say "publish it," and it's live. No tab switch, no paste.

Both integrations respect the same boundary: the API key is scoped, revocable in one click from the dashboard, and never gives an automation more access than you chose to hand it. (And if your dashboard is getting busy enough that finding that settings page takes a beat — the new command palette ships this week too. Press one shortcut, type "api", you're there.)

The larger point isn't any single workflow. It's that your blog stopped being a destination you have to visit and became infrastructure other tools can build on. If you want to try it on a blog of your own, start a 14-day free trial — the API keys page is waiting in the dashboard, and the node is one install away.