Selfish Blog

A blogging app for iPhone that publishes plain HTML

Tue, 15 Sep 2026 09:30:00 +0100

Plenty of apps let you write a blog post on an iPhone. Far fewer let you finish the job there – turn that post into a web page and put it on a server you control – without a platform in the middle.

If what you want at the end is plain HTML files on your own domain, readable in any browser in twenty years’ time, the choice narrows quickly. This is a guide to what to look for, what the main options actually do at the time of writing, and where each one fits.

What to look for

Six questions sort the field.

What is the output? Some apps post into a platform’s database; the page only exists while that platform runs. Others produce actual files: HTML, CSS, images, a feed. Files are the durable option. You can copy them, archive them and serve them from anywhere.

Where does it publish? A hosted platform, or a destination you choose: your own server over SFTP, object storage such as S3, or a static host such as Netlify, Cloudflare Pages or GitHub Pages.

Does it work on the phone alone? Many “mobile” workflows quietly depend on a computer or a cloud build service to do the real work. That is fine if you know it going in.

Is there an account? Every account is a dependency, and a place your writing and credentials sit that you don’t control.

How are credentials stored? Server passwords, SSH keys and API tokens should live in the iOS Keychain, not in an app’s own database or synced in plain text.

Can you see exactly what will be published? A preview that matches the live page saves a lot of republishing.

The landscape

WordPress and Jetpack apps

The official WordPress app is a capable mobile editor for WordPress sites, with the block editor, media uploads and drafts. Automattic splits its mobile features between it and the Jetpack app, which adds stats, notifications and more.

The output is WordPress: posts go into the site’s database and pages are generated by PHP on the server. If you already run WordPress, these apps are the obvious choice and they are good at it. They do not produce HTML files you own; they edit an application you have to keep running and patched. We compare the two approaches in WordPress vs a static site.

Micro.blog

Micro.blog is the closest thing to “blogging from your phone” as a complete, friendly service. There are native apps for iPhone, Mac and Android, hosted blogs, custom domain support, cross-posting to social networks and, on higher plans, email newsletters and multiple blogs. At the time of writing hosted plans start at $1 a month for Micro.one, with the full Micro.blog plan at $5 a month.

Under the hood, Micro.blog builds hosted blogs with Hugo, a static site generator, and it offers an export of your theme and posts as Markdown in a Hugo-style folder. That is a better exit than most platforms offer. But the site is hosted by Micro.blog, not published to a server you run, and it is a subscription. For many people that trade is exactly right.

Ghost in the browser

Ghost does not have an official native iPhone app for writing. Its admin editor runs in Safari and works on a phone, and there is at least one third-party app, Publisher for Ghost, that talks to a Ghost site.

Ghost pages are rendered by a Node.js application backed by a database, whether on Ghost(Pro) or on your own server. It is a strong platform with newsletters and memberships built in – see Substack alternatives that you actually own – but it is not plain HTML.

Working Copy and a static site generator

This is the developer’s route, and it genuinely works. Working Copy is a Git client for iOS: you clone the repository holding your Hugo, Jekyll or Eleventy site, write Markdown in its editor (or in any app that can open files in its folders), commit and push.

The catch is what happens next. The iPhone does not build the site. The push triggers a build elsewhere – GitHub Actions, Netlify, Cloudflare Pages – and that service produces the HTML. You need the site set up from a computer first, you need to be comfortable with Git, and pushing requires Working Copy’s paid pro features (a one-off purchase of $35.99 at the time of writing; the app is free to download and has a trial).

For developers who already live in Git, it is a fine setup. For everyone else it is a lot of moving parts for a blog post.

iA Writer and other writing apps

iA Writer is an excellent place to write, and on iPhone and iPad it can send a document to WordPress, Ghost, Medium, Micro.blog or any Micropub endpoint. It creates a draft on the destination, which you then open and publish there.

That makes it a writing front end for a platform, not a publisher. The output is whatever the destination produces. Several other writing apps take the same approach. If you love the writing experience and already have a platform, this pairing works well.

Summary

	Output	Publishes to your own server	Needs a computer or build service	Cost (at the time of writing)
WordPress app	WordPress site	Your WordPress install	No, but needs a running WordPress	Free app; hosting extra
Micro.blog	Hosted site (built with Hugo)	No, hosted by Micro.blog	No	From $1/month
Ghost in Safari	Ghost site	Your Ghost install, if self-hosted	No, but needs a running Ghost	Ghost(Pro) or your server
Working Copy + SSG	Static HTML	Yes, via a build service	Yes	$35.99 one-off for push
iA Writer	Draft on a platform	No	No	One-off app purchase

None of these is wrong. They answer different questions. What most of them don’t do is let you write on the phone and have the phone produce the finished static site and upload it to a place you chose.

Where Selfish fits

That gap is what Selfish is for: a native app for iPhone, iPad and Mac – £3.99 once, no subscription – that builds a complete static site – HTML, feeds, sitemap – and publishes it over SFTP or to S3-compatible storage, Netlify, Cloudflare Pages or GitHub Pages, with credentials kept in the Keychain and no Selfish account. It does not do comments, newsletters or imports from other platforms. It is out now on the App Store, at a £3.99 introductory price, rising to £9.99 in December; the user guide shows how writing works, and the themes page shows what the output looks like.

Selfish vs Medium: your own site or a borrowed audience

Tue, 08 Sep 2026 11:05:00 +0100

Here’s the short answer. Medium is the better choice if you want readers soon and don’t mind writing inside someone else’s product to get them. Selfish is the better choice if you want a site that is entirely yours: plain HTML files on hosting you control, with no account and no platform between you and whoever reads it. Medium lends you an audience and a way to get paid. Selfish gives you ownership and nothing else. You can’t get both from either one, so the real question is which of the two you’d miss more.

At a glance

	Selfish	Medium
Ownership	You own the files and choose the host	Medium runs the platform your stories live on
Cost	£3.99 once for the app, introductory — £9.99 from December. Optional premium themes at £1.99 each. You pay for your own hosting	Free to write. Membership is $5 a month or $50 a year at the time of writing, and you need it for the Partner Program and custom domains
Where content lives	On your device (optional iCloud sync), published to your server	On Medium’s servers
Custom domain	Whatever domain you point at your own hosting	Members only. A root domain or subdomain, not a subdirectory
Email/newsletter	None. Selfish doesn’t send email, but it does publish RSS and JSON feeds	Readers can subscribe to get your stories by email
Monetisation	None built in	Partner Program pays for member engagement with paywalled stories
Audience/discovery	None built in	Built-in readership, recommendations, publications, Boost
Editing	Native app for iPhone, iPad and Mac, with live preview	Browser editor plus mobile apps
Output	A complete static site: HTML, sitemap, RSS and JSON feeds	Pages on Medium’s platform
Lock-in/export	The published site is standard HTML with no Selfish code in it	Export gives you HTML files in a .zip. Your followers stay on Medium

Where Medium genuinely wins

Distribution

A new Selfish site starts with no readers. It has no feed or recommendation engine and no network of other writers sending people your way. That’s the cost of independence, and it’s a real cost.

Medium starts you somewhere else. It has a readership that’s already there, publications you can submit to, and a recommendation system that can put a story from a brand-new account in front of strangers. It also runs Boost, which gives selected stories wider distribution. Medium’s own explanation of Partner Program earnings says boosted stories earn at a higher rate. If your aim is for strangers to read your first ten posts, Medium is the stronger bet.

Getting paid for words

The Medium Partner Program is the simplest way to earn money from writing without building anything yourself. Medium’s help centre currently lists the eligibility rules as:

an active Medium membership
at least one published story
a complete profile
a bank account in a supported country
being 18 or over
agreeing to the programme terms and the paywall content policy

Earnings depend on how paying members engage with your member-only stories. That covers reading and listening time plus interactions such as claps, highlights and replies.

Selfish has nothing comparable. It has no paywall, no payments and no revenue share. If you want to be paid inside the place where you publish, that settles it.

Zero setup

With Medium you sign up and write. You don’t deal with hosting, DNS, credentials or deploys. Selfish removes most of the friction from self-publishing, but you still need somewhere to publish to. That could be a server you reach over SFTP, an S3-compatible bucket, or an account on Netlify, Cloudflare Pages or GitHub Pages. For some people that one-off setup is enough reason to stay on a platform.

Email to followers

Medium lets readers subscribe to a writer and get new stories by email. Selfish doesn’t send email of any kind. Your readers can follow the RSS feed, and plenty of people still do, but a feed isn’t an inbox.

Where Selfish wins

The address is yours, unconditionally

Medium supports custom domains, but only while you’re a paying member. Its help centre also restricts you to a root domain or a subdomain, so you can’t serve Medium from yourdomain.com/blog. With Selfish your domain points at your own hosting, and no subscription stands between them. The domain and the hosting are both yours. Selfish just writes files to them.

The reader gets a web page

Once you join the Partner Program, stories you put behind the paywall are part of Medium’s membership. Non-members hit the limits Medium sets. A Selfish site is a set of static pages. It has no membership prompts, no third-party scripts and no Selfish code. Themes use no web fonts and send nothing back to anyone. Readers load a page and read it.

The files are the site

When you publish with Selfish, the output is a complete static site. It has standalone HTML for every post and page, archive pages for categories and tags, a sitemap, RSS and JSON feeds, and canonical links. Any web server on earth can serve that, and it will still be readable in twenty years. Your drafts stay on your device, optionally synced through your own iCloud account. Selfish has no servers holding a copy.

Cost is predictable

Selfish costs £3.99, once, with no subscription, no per-site fee and no paywall on publishing. That is an introductory price; it rises to £9.99 in December. The only optional purchases are three premium themes at £1.99 each, bought once. Your ongoing cost is whatever your hosting costs, and static files are about the cheapest thing there is to host.

Leaving Medium, if you decide to

Medium makes it reasonably easy to get your writing out:

On the web, click your profile picture and open Settings.
Go to the Security and apps tab.
Click Download your information, then Export.
Medium emails you a link to a .zip archive of your stories as HTML files.

Be clear about what that archive is. It’s your text, in HTML. It doesn’t bring your followers or your stats with it, and every link anyone has shared still points at Medium. Selfish doesn’t import Medium archives either. Moving posts means copying them across by hand, which is tedious for a large back catalogue and quite manageable for a few dozen posts. We’ve written more about the process in leaving Medium for good.

You also don’t have to choose outright. Many writers publish on their own site first, then republish selected pieces on Medium with a link back to the original. That way they keep the canonical home and still get some of the reach.

Choose Medium if…

You want an audience you didn’t have to build, and you’re happy for the platform to decide who sees what.
You want to earn from your writing without setting up payments yourself, and the Partner Program’s rules and eligibility suit you.
You’d rather pay a membership than think about hosting at all.
Email notifications to followers matter to you.

Choose Selfish if…

You want your writing on your own domain, your own hosting and your own terms, with no membership keeping it there.
You care that the published site is plain, fast HTML with no tracking and no platform code.
You write on an iPhone, iPad or Mac and want a native app with a preview that matches the published page exactly.
You’re fine with finding readers the slow way, through search, links, feeds and people sharing your work.

Where Selfish fits

Selfish is on the App Store for iPhone, iPad and Mac. It’s a one-time £3.99 purchase — introductory, rising to £9.99 in December — and you can run as many independent sites as you like from one app. If you’re weighing up ownership against reach, the user guide shows what writing and publishing look like, and the publishing docs cover each hosting route. Medium will still be there if you want the reach as well.

Own your blog: leaving Medium for good

Wed, 02 Sep 2026 08:50:00 +0100

Medium is a pleasant place to write and a poor place to keep things. The editor is good, the reading experience is clean and there is a built-in audience you will not get on your own site overnight. But the address is theirs, the paywall is theirs, the distribution rules are theirs, and they have changed all three more than once.

Leaving is not hard. It is fiddly, and the fiddly parts are worth doing properly because you only do them once. This guide covers the whole move: getting your archive, getting your posts into a new home, and dealing honestly with the links you can’t take with you.

Step 1: Download your Medium archive

Medium lets you export everything it holds about you as a zip file. At the time of writing the path on the web is:

Click your profile picture, then Settings.
Open the Security and apps tab.
Click Download your information and confirm with Export.

In the iOS and Android apps it is under Settings → Account → Security and apps. Either way, Medium emails you a download link when the archive is ready, usually within minutes.

Do this first, even if you are not ready to move. An export you have is worth more than one you meant to get.

Step 2: Understand what’s in the archive

Unzip the file and you will find a README and a set of folders – posts, bookmarks, claps, highlights, lists, profile and so on. The one that matters is posts.

A few things to know before you start:

Each post is a standalone HTML file. Not Markdown, not JSON. It opens in any browser, and the text copies out cleanly.
Drafts and responses are mixed in with published stories. Every comment you ever left on someone else’s story was a “response”, and Medium treats responses as posts, so they all land in the same folder. Expect to sift before you start moving anything.
Images are not in the zip. The HTML files reference images on Medium’s CDN. They will load for now, but if you want to own them you need to download each one and host it yourself. Several open-source scripts exist to do this in bulk if you have a lot of posts.
Your followers are not in it. The archive lists the accounts you follow, not the email addresses of people who follow you. Treat your Medium followers as an audience you will invite to the new place rather than one you can move.

Step 3: Choose where the posts are going

This is the decision that makes everything else easier. Pick a home at your own domain. It can be WordPress, Ghost, a static site generator such as Hugo, or a native app that builds a static site for you. We compare the options in the best way to self-host a personal blog, and weigh the two biggest camps in WordPress vs a static site.

Whatever you pick, buy the domain first and put it on a registrar you trust. The domain is the part of this move that keeps future moves painless.

Step 4: Move the posts

Some platforms have Medium importers; WordPress.com, for instance, accepts the Medium export file and keeps original dates and tags. If yours does not, you will be copying by hand, and for most personal blogs that is less work than it sounds.

A workable routine, one post at a time:

Open the exported HTML file in a browser.
Copy the body text into your new editor. Formatting such as headings, bold, italics, links and quotes usually survives a paste; check it.
Save each image from the page and attach it to the new post.
Set the publication date to the original date, so your archive stays in order.
Note the old Medium URL next to the new one in a spreadsheet. You will need that list later.

Be ruthless while you do it. Old posts that you would not write today can stay behind. A smaller archive you are proud of beats a complete one you are not.

Step 5: Accept what you can’t redirect

This is the part people get wrong, so to be plain about it: you cannot redirect medium.com URLs. You do not control that domain or its server. Every link to medium.com/@you/some-post-a1b2c3d4e5f6 that already exists on the web will keep pointing at Medium for as long as the post exists there. If you delete the post, those links break.

There is one exception. If you connected your own custom domain to Medium, you control that domain, and you can point it at your new host.

Custom domains have a history on Medium. They were once a paid add-on, were withdrawn for new users for a while, and have since returned; at the time of writing Medium offers them free to paying members. If you used one, the move is much kinder:

Point the domain’s DNS at your new host.
Set up redirects from each old Medium-style path (a slug ending in a string of hex characters) to the matching new URL, using the spreadsheet from Step 4. Most hosts support a redirects file; on your own server, an Nginx return 301 per line works.
Disconnect the domain in your Medium settings too, so Medium is no longer configured to use it.

If you never used a custom domain, there is nothing to redirect. The fix is the next step.

Step 6: Keep a Medium mirror that points home

You don’t have to delete your Medium posts, and there is a good argument for not doing so. Old links keep working, and Medium still sends readers. What you want is for search engines to treat your own site as the original.

That is what a canonical link does. Medium lets you set one on an existing story:

Open the story and choose Edit story from the three-dot menu.
In edit mode, open the three-dot menu again and choose More settings.
Under Advanced Settings, select This story was originally published elsewhere, paste the URL of the post on your new site and save.
Republish the story.

Medium’s page now carries <link rel="canonical"> pointing at your site. Readers on Medium can still read it; search engines are told where the original lives.

For new writing, reverse the flow. Publish on your own site first, then use Medium’s Import a story feature, which copies the post into Medium and sets the canonical link to your original automatically. Your site stays the source; Medium becomes a distribution channel, which is what it is best at.

It is also worth adding a line at the end of each Medium story – “This post lives at yourname.com” – so human readers find their way home too.

Step 7: Tell people

Update your Medium bio to point at your site. Update your social profiles. If you had an email list, send one message explaining where to find you. Then write something new on the new site, because an archive with no fresh posts gives nobody a reason to visit.

Doing the move with Selfish

Selfish has no Medium importer. Posts move the way Step 4 describes: open the exported HTML, paste the text into the composer, attach the images and set the date. Once they are in, Selfish generates your site with canonical links, an RSS feed and a sitemap, and publishes it to your own server or host. It is on the App Store as a one-time purchase, at a £3.99 introductory price, rising to £9.99 in December; the user guide covers writing and publishing, and Selfish vs Medium is the side-by-side.

Selfish vs Substack: a newsletter platform or a site you own

Tue, 25 Aug 2026 10:40:00 +0100

Here’s the honest answer. If you want to send a newsletter, and especially if you want readers to pay for it, use Substack. Selfish doesn’t send email and has no payment features. If what you want is a website, meaning a blog on your own domain made of plain files on hosting you control, Selfish is the better fit. Substack is a newsletter business in a box that also puts your posts on the web. Selfish is a publishing tool that puts your posts on the web and stops there. They overlap less than the “Substack alternative” framing suggests.

At a glance

	Selfish	Substack
Ownership	You own the files and choose the host	Substack hosts your publication. You can export your posts and list
Cost	£3.99 once for the app, introductory — £9.99 from December. Optional premium themes at £1.99 each. You pay for your own hosting	Free to publish. If you charge, 10% of each transaction plus Stripe fees, at the time of writing
Where content lives	On your device (optional iCloud sync), published to your server	On Substack’s servers
Custom domain	Whatever domain you point at your own hosting	One-time $50 fee at the time of writing. Must be a subdomain such as `www`
Email/newsletter	None. Selfish doesn’t send email. It publishes RSS and JSON feeds	Core feature. Every post can go out as an email
Monetisation	None built in	Paid subscriptions through Stripe
Audience/discovery	None built in	Substack network, Recommendations, the Substack app, Notes
Editing	Native app for iPhone, iPad and Mac, with live preview	Web editor and mobile apps
Output	A complete static site: HTML, sitemap, RSS and JSON feeds	Pages and emails on Substack’s platform
Lock-in/export	The published site is standard HTML with no Selfish code in it	Export includes posts, subscriber list and stats. Newsletters are sent from a substack.com address

Where Substack genuinely wins

Email is the product

The biggest difference comes first. Selfish does not send email newsletters. It has no subscriber list, no mailing and no inbox delivery. Substack is built around exactly those things. You write a post and it lands in your subscribers’ inboxes as well as on the web. For a lot of writers, email is the only channel that reliably reaches people, so this matters.

A Selfish site does publish an RSS feed, and some email services can turn a feed into a newsletter automatically. But then you’re running two tools and managing a list yourself. Substack handles all of it for you.

Payments are built in

Substack lets you switch on paid subscriptions and connect Stripe, and readers can then pay monthly or annually. You don’t have to build anything. Selfish has no payment or subscription features of any kind.

Here’s what that convenience costs, taken from Substack’s help centre at the time of writing:

Substack: 10% of each transaction.
Stripe, cards: 2.9% + $0.30 per transaction.
Stripe Billing: 0.7% on recurring payments.

On a $10 monthly subscription that works out as roughly $1.00 to Substack, about $0.59 in card fees and $0.07 in billing fees. You keep a little over $8.30. Stripe’s fees vary by country and payment method, so check your own Stripe dashboard for the real figures. Publishing itself is free however many subscribers you have. Apart from the optional custom domain fee, Substack only earns when you do.

The network

This is Substack’s quiet advantage. Its Recommendations feature lets writers suggest each other’s publications. New subscribers are shown those suggestions right after they sign up, and Substack’s dashboard shows how many subscriptions each recommendation brought in. Add the Substack reader apps, Notes and the network’s search and leaderboards, and a new publication has ways to be found that a standalone site simply doesn’t. A Selfish site has no built-in audience or discovery.

Community features

Substack has threaded comments, subscriber chat, direct messages, podcast hosting and video. Selfish has none of these, and no comments either. If you want conversation to happen where you publish, Substack gives you that from the start.

Where Selfish wins

It’s a website first

A Substack publication is a newsletter with a web archive. A Selfish site is a website. You get posts and standalone pages, categories and tags with their own archive pages, and a choice of themes. Each theme is a single self-contained CSS file with automatic dark mode. The output is a complete static site with a sitemap, feeds and canonical links. That shape suits a blog, a portfolio or a project site better than an inbox-first product does.

Your domain, your root

Substack’s custom domains cost a one-time fee, and they must use a subdomain such as www. You can redirect the root domain, but the publication lives on the subdomain. Substack also sends your emails from a substack.com address, whatever domain you use. With Selfish there’s no platform in the way. Your domain points at your hosting, and your site sits at whatever address you configure.

No platform code on the page

A Selfish site carries no Selfish code, no tracking and no analytics, and its themes phone nothing home. Readers get HTML and CSS. On Substack the page belongs to Substack’s platform and comes wrapped in Substack’s own interface. That’s reasonable for them, but it isn’t your page.

Nobody else’s terms

Your drafts live on your device, optionally synced through your own iCloud account. Selfish has no account and no servers holding your writing. The published site sits on hosting you pay for. No change of platform policy, pricing or ownership can take it down.

Exporting from Substack

Substack is better about exports than its reputation suggests. In your publication’s Settings, open Exports and choose Create new export. Substack builds a .zip with your posts, subscriber list and related statistics, and emails you when it’s ready. You can also export just the subscriber list as a CSV from the Subscribers page.

The subscriber list is the valuable part. Keep a recent copy even if you never plan to leave. Just remember that Selfish doesn’t import Substack exports, and it can’t do anything with an email list, because it doesn’t send email.

The combination some writers use

Plenty of writers don’t choose. They keep a newsletter on Substack or another email service for the inbox, and run their own site for the permanent, linkable, searchable version of their work. The website is the canonical home and the newsletter is how it’s delivered. If email matters to you and so does ownership, that split is often more sensible than forcing one tool to do both jobs. We cover the wider options in Substack alternatives that you actually own.

Choose Substack if…

Email is how you want to reach readers.
You want paid subscriptions without building payments, and 10% plus Stripe fees is a price you’re happy with.
You want to be discovered through Recommendations and Substack’s app and network.
You want comments, chat, podcasts or video in the same place.

Choose Selfish if…

You want a website on your own domain and hosting, not a newsletter with an archive.
You don’t need to send email, or you’re happy to handle email separately.
You want clean static HTML with no tracking, no platform prompts and no account.
You write on an iPhone, iPad or Mac and want to publish straight to SFTP, S3-compatible storage, Netlify, Cloudflare Pages or GitHub Pages.

Where Selfish fits

Selfish is on the App Store as one app for iPhone, iPad and Mac, for a one-time £3.99 introductory price that rises to £9.99 in December. It won’t replace a newsletter platform, and it isn’t trying to. If you want a quiet, durable website that’s entirely yours, the user guide shows how it works and the themes page shows what your site could look like.

Substack alternatives that you actually own

Wed, 19 Aug 2026 09:25:00 +0100

Most “Substack alternatives” lists compare features. That misses the reason people leave. They leave because they want to own the thing they have built, and “own” is a slippery word. Every platform will tell you that you own your content. Fewer will tell you what happens to your readers, your links and your income on the day you walk away.

So before the alternatives, a working definition.

What “own” actually means

Ownership is not a feeling. It is four things you can check.

The domain. If your writing lives at yourname.substack.com, every link anyone has ever shared points at someone else’s address. If it lives at yourname.com, the links are yours, and you can point that domain anywhere you like. This is the single most important item on the list, and it is the cheapest: a domain costs a few pounds a year.

The content export. Can you get every post out, in a format something else can read, without asking permission? HTML or Markdown is good. A PDF of each post is not an export.

The subscriber list. A CSV of email addresses you can take to another tool. Paid subscribers are harder: the billing relationship usually lives in Stripe, and whether it can move depends on the platform.

The URLs. When you move, do the old links keep working? That needs a domain you control and a host that lets you set redirects. Without both, every inbound link you have earned eventually breaks.

Substack, to be fair, does better on this than its reputation suggests. At the time of writing it is free to start and takes 10% of paid subscription revenue, on top of Stripe’s processing fees. It lets you connect your own domain for a one-off $50 fee, and its export gives you your posts (as HTML, with a CSV index) and your subscriber list. What you cannot take with you is the network: recommendations, app followers and the discovery that Substack itself provides. That network is the genuine reason to stay, and it is worth being honest with yourself about how much of your readership came from it.

Ghost

Ghost is the closest like-for-like replacement: a publishing platform with memberships, paid subscriptions and newsletters built in. It is open source under the MIT licence, which gives you two ways to run it.

Ghost(Pro) is the hosted service run by the Ghost Foundation. At the time of writing, plans start at $18 a month billed yearly for the Starter tier, which does not include paid subscriptions; the Publisher tier, which does, is $29 a month billed yearly for up to 1,000 members. Ghost takes 0% of your subscription revenue on the tiers that support it; you pay Stripe’s fees and nothing else. Custom domains are included.

Self-hosted Ghost costs nothing in licence fees, but it is a real server to run: Ubuntu, Node.js, MySQL and a reverse proxy, plus a Mailgun account, because Mailgun is the only bulk email service Ghost supports for sending newsletters. If you already run servers, this is the most complete form of ownership on this list. If you don’t, the maintenance is a job you are signing up for.

Ghost scores well on all four tests: your domain, a JSON content export, a members CSV export, and a redirects file you control.

Buttondown

Buttondown is a small, independent newsletter tool that writes in Markdown and stays out of the way. At the time of writing it is free for up to 100 subscribers, then priced by the number of subscribers you actually send to, with optional features sold as add-ons. Paid subscriptions are one of those add-ons, and Buttondown takes no cut of the revenue.

It hosts a web archive of your issues, and serving that archive from your own domain is an add-on too. That makes Buttondown a very good fit for the “own site plus separate newsletter” pattern described below: let Buttondown do the email, and keep your canonical writing on your own site.

beehiiv

beehiiv is built for growth: referral programmes, a recommendation network, ad placements and detailed analytics. At the time of writing its free Launch plan covers up to 2,500 subscribers and includes a custom domain. Paid subscriptions require a paid plan (Scale, at $43 a month, is the entry point), and on those plans beehiiv advertises a 0% take rate on subscription revenue.

It is a strong choice if growing a list is the point. It is less of a choice if the point is a quiet place to write, because much of what you are paying for is growth machinery.

Kit

Kit (formerly ConvertKit) is email marketing software for creators: automations, sequences, landing pages and digital product sales. At the time of writing its free plan covers up to 10,000 subscribers, with paid plans adding automations and paid newsletters. Kit charges a transaction fee on sales and subscriptions (3.5% plus 30 cents at the time of writing), so it is not a 0% platform.

Kit is the most “business” option here. It is excellent if your newsletter feeds a course or a product. It is heavy if all you want is to send your latest post to people who asked for it.

This is the unfashionable answer, and for many writers the best one.

Split the job in two. Your writing lives on a plain static website at your own domain: HTML files, an RSS feed, nothing to patch. Your email list lives in a newsletter tool – Buttondown, beehiiv, Kit, even self-hosted Ghost used purely for email. The site is the canonical home of every post. The newsletter points readers to it, or carries the full text with a link back.

What you get:

Every URL is yours, on a domain you control, served by whichever host you pick this year.
The archive outlives the newsletter. If you change email tools, the posts do not move. Only the subscriber CSV does.
Your site costs little or nothing to host. Static hosting on Netlify, Cloudflare Pages, GitHub Pages or an ordinary web server is cheap and very hard to break.
Your RSS feed can drive the email. Several newsletter tools can turn a new item in your feed into an email – Buttondown offers RSS-to-email as an add-on, for example – so publishing on the site can trigger the send.

What you give up is integration. Paywalled posts, member-only pages and “subscribe to read the rest” need a platform that controls both the site and the list. A static site cannot gate content by itself. If paid, members-only writing is your model, Ghost or Substack will serve you better, and that is fine.

A quick comparison

	Own domain	Free to start	Platform’s cut of paid subs (at the time of writing)
Substack	Yes ($50 one-off)	Yes	10%, plus Stripe fees
Ghost(Pro)	Yes	No	0% on Publisher and above, plus Stripe fees
Self-hosted Ghost	Yes	Software is free; server and Mailgun are not	0%, plus Stripe fees
Buttondown	Archive on your domain is an add-on	Up to 100 subscribers	0% (paid subscriptions are an add-on)
beehiiv	Yes	Up to 2,500 subscribers	0% on paid plans
Kit	For landing pages	Up to 10,000 subscribers	3.5% + 30c per transaction
Static site + newsletter tool	Yes	Hosting can be free	Depends on the newsletter tool

Check each provider’s current terms before you commit. Pricing in this market changes often.

How to choose

If you need paid subscriptions and do not want to run a server, Ghost(Pro) is the cleanest move away from Substack. If you want the most control and don’t mind administration, self-host Ghost. If you mostly write in public and want email as a delivery channel, put the writing on your own static site and pair it with Buttondown or a similar tool. If growth is the whole game, beehiiv is built for it.

Whatever you pick, buy the domain first. It is the one decision that keeps every other decision reversible. We go into the hosting side in more detail in the best way to self-host a personal blog.

Where Selfish fits

Selfish does not send email and has no subscriber list. It is the site half of “own site plus separate newsletter”: a native app for iPhone, iPad and Mac – £3.99 once – that turns your posts into a complete static site with an RSS feed and publishes it to your own server or host. It is out now on the App Store, at a £3.99 introductory price, rising to £9.99 in December; the publishing guide shows the hosts it supports, and there is a head-to-head in Selfish vs Substack.

Selfish vs WordPress.com: hosted platform or static site you own

Tue, 11 Aug 2026 14:10:00 +0100

Here’s the short answer. WordPress.com does far more than Selfish does. It has comments, newsletters, payments, a plugin catalogue and a large ecosystem. The price of all that is a plan, a dashboard and a site that runs on someone else’s platform. Selfish does one thing: it turns what you write on your iPhone, iPad or Mac into a plain static site and publishes it to hosting you control. If you need features, WordPress.com wins. If you want a small, fast site that’s simply yours, Selfish is the better fit.

First, a distinction worth getting right. WordPress.com is a hosted service. You sign up, pick a plan, and the site runs on its infrastructure. WordPress.org is where the free, open-source WordPress software lives, which you install and run on your own server. This post compares Selfish with WordPress.com. Self-hosted WordPress is a different trade-off, which we cover in WordPress vs a static site.

At a glance

	Selfish	WordPress.com
Ownership	You own the files and choose the host	You own your content. The site runs on WordPress.com’s platform
Cost	£3.99 once for the app, introductory — £9.99 from December. Optional premium themes at £1.99 each. You pay for your own hosting	Free plan with ads. Paid plans are Personal, Premium, Business and Commerce
Where content lives	On your device (optional iCloud sync), published to your server	In WordPress.com’s database
Custom domain	Whatever domain you point at your own hosting	Paid plans only. Annual plans include a domain free for the first year
Email/newsletter	None. Selfish doesn’t send email. It publishes RSS and JSON feeds	Built in. New posts can be emailed to subscribers
Monetisation	None built in	Paid newsletters and payments via Stripe, with a fee that depends on your plan
Audience/discovery	None built in	The WordPress.com Reader, follows and likes
Editing	Native app for iPhone, iPad and Mac, with live preview	The WordPress block editor in the browser
Output	A complete static site: HTML, sitemap, RSS and JSON feeds	A dynamic WordPress site
Lock-in/export	The published site is standard HTML with no Selfish code in it	XML (WXR) export of posts, pages, comments, categories and tags. Media exported separately

Where WordPress.com genuinely wins

Plugins and the ecosystem

This is the headline. According to WordPress.com’s support pages at the time of writing, you can install plugins on every paid plan: Personal, Premium, Business and Commerce. The free plan can’t. The pricing page points to a catalogue of over 60,000 plugins. Forms, memberships, shops, courses, booking, SEO tooling: someone has almost certainly built what you need.

Selfish has no plugin system. You get themes, header and footer snippets, and nothing more. For a blog that’s usually enough. If your site has to do things, it isn’t.

Comments and community

WordPress.com sites come with comments, likes and follows. The WordPress.com Reader pulls public WordPress.com sites and Jetpack-connected WordPress sites into one feed, where readers can discover and follow them. Selfish has no comments and no built-in discovery. Readers find a Selfish site through search, links and RSS.

Newsletters and payments

Every WordPress.com site includes a newsletter feature. Subscribers can get each new post by email, and you can add paid tiers through Stripe. WordPress.com’s support guide lists the payment fee by plan. At the time of writing it’s 10% on Free, 8% on Personal, 4% on Premium, 2% on Business and 0% on Commerce.

Stripe also takes 2.9% + $0.30 per payment in the US, and the fee differs elsewhere. If your plan lapses, WordPress.com says the fee goes back to 10%. It’s a flexible setup, because you can trade a higher plan price for a lower cut. Selfish sends no email and handles no payments.

Growing into more

On the Business plan and above, WordPress.com lists SFTP and SSH access, WP-CLI, Git commands and GitHub deployments, along with real-time backups. A site can start as a blog and grow into a shop or a membership site without moving house. Selfish is deliberately smaller than that.

Where Selfish wins

Nothing to maintain

A WordPress site is software. It has a database, a PHP runtime, a theme and possibly dozens of plugins, all of which change over time. WordPress.com handles much of the maintenance for you, but the moving parts are still there. A Selfish site is a folder of HTML, CSS and images. It has nothing to patch, no admin login to protect on the published site, and no database to back up at the server end.

It’s fast because it’s static

Every page on a Selfish site is pre-built. The themes are single CSS files with automatic dark mode and no web fonts, and they send nothing back to anyone. Pages load quickly on any cheap host because the server only hands over files.

No ads, no plan to keep up

The free WordPress.com plan shows WordPress.com’s ads to your visitors and doesn’t let you connect your own domain. To remove the ads and use your domain, you need a paid plan. At the time of writing, the UK pricing page shows Personal starting at £3 a month billed yearly and renewing at £5 a month. Prices vary by region and change with promotions. Selfish itself is a one-time £3.99 — an introductory price, rising to £9.99 in December — with no subscription and no per-site fee. You pay only for the hosting you choose, and your site carries no ads unless you add them.

Writing in a native app

WordPress’s block editor is powerful, and complicated with it. Selfish’s composer is plain text with light formatting: bold, italic, links, H2 and H3 headings, and quotes. Under the hood that’s stored as a small Markdown subset. You get autosave, drafts, and a live preview that matches the published page exactly. Photos are optimised automatically. It’s a smaller tool, and that’s the point.

Your hosting, your choice

Selfish publishes over SFTP or to S3-compatible storage, Netlify, Cloudflare Pages or GitHub Pages. Credentials stay in Apple’s Keychain. Your content lives on your device, optionally synced through your own iCloud account. You never need a Selfish account.

Exporting from WordPress.com

WordPress.com’s export gives you an XML file, also called a WXR file. It contains your posts, pages, comments, categories and tags, plus links to your media rather than the media itself. You can download the media library separately. The export doesn’t include your theme design, customisations or plugins. The WXR format is widely supported, so moving to self-hosted WordPress or another platform that reads it is straightforward. Selfish doesn’t import WordPress exports, so moving to Selfish means bringing posts across by hand.

Choose WordPress.com if…

You need plugins: shops, forms, memberships, bookings.
You want comments and a community around your posts.
You want newsletters and paid subscriptions on the same site.
You’d rather have a managed dashboard than look after hosting yourself, and a plan price is fine with you.

Choose Selfish if…

You want a blog or personal site, not an application.
You want static HTML on hosting you choose, with no database and no plugins to maintain.
You don’t need comments, email or payments, or you’re happy to handle them elsewhere.
You write on an iPhone, iPad or Mac and want a native app that publishes straight to your own host.

Where Selfish fits

Selfish is on the App Store as one app for iPhone, iPad and Mac, for a one-time £3.99 introductory price that rises to £9.99 in December. It won’t replace WordPress.com for anyone who needs its plugins or community features. If a quiet, fast site that’s entirely yours sounds better, the publishing docs explain each hosting route and the themes page shows the look.

WordPress vs a static site for a personal blog

Thu, 06 Aug 2026 10:30:00 +0100

WordPress runs a vast share of the web, and for good reasons. It is also, for a lot of personal blogs, more machine than the job needs. A static site – plain HTML files generated once and served as they are – sits at the other end of the scale.

This is a comparison for one use case only: a personal blog, written mostly by one person. For a newsroom, a shop or a membership site the answer is different, and usually it is WordPress or something like it.

The fundamental difference

A self-hosted WordPress site is an application. Every page view can run PHP code, query a MySQL or MariaDB database and assemble the page on the fly (caching softens this, but the application is always there). Your writing lives in that database.

A static site is a folder of files. Something – a generator on your computer, a build service, an app – turns your posts into finished HTML, CSS and images once, and a web server hands those files out unchanged. Your writing lives wherever the generator keeps its source.

Almost every trade-off below follows from that one difference.

Security and patching

WordPress is well maintained and its core team takes security seriously. Since WordPress 3.7, minor releases – which carry most security fixes – install themselves automatically, and new installs since 5.6 auto-update major releases too. Since 5.5 you can switch on automatic updates for plugins and themes, one by one.

The exposure comes from what you add. Each plugin and theme is code from a different author, running on your server with access to your database. Most are fine. Some are abandoned. The login page is a permanent target for password-guessing bots. Running WordPress safely means staying on top of updates, pruning plugins you don’t use and keeping good backups, indefinitely.

A static site has almost nothing to attack. There is no login page on the public server, no database, no code running per request. The remaining risk is the server or host itself, and the credentials you use to upload. For a site you might not touch for months, that difference is the main argument.

Verdict: static, clearly, for a solo blog.

Plugins and features

This is where WordPress wins, and it is not close. The plugin directory covers almost anything you can imagine: SEO tools, galleries, events, bookings, shops, memberships, translations. You can add a feature to a live site in a few clicks without writing code.

A static site can only do what its generator, its theme and client-side scripts can do. That covers the essentials of a blog – posts, pages, tags, feeds, sitemaps – very well. It does not cover “add a booking calendar this afternoon”.

Verdict: WordPress.

Comments

WordPress has comments built in, with moderation, threading and email notifications, plus Akismet for spam. It works on day one.

A static site has no server-side code, so comments have to come from somewhere else. The honest options:

A third-party embed. giscus, for example, is free, open source and stores comments in GitHub Discussions – which means commenters need a GitHub account. Fine for a developer blog, a barrier for most others.
A self-hosted comment server such as Remark42. Good, private, and one more service for you to run and patch – which gives back part of the security advantage.
No comments. Many personal blogs now link to an email address or a social post instead. Replies arrive in private, the spam problem disappears and the page stays static.

Verdict: WordPress, if comments matter to you. If they don’t, this stops being a factor.

Forms

WordPress has several mature form plugins, and form submissions go straight into your database or inbox.

A static site needs a form backend. Some hosts provide one: Netlify Forms detects a form marked with data-netlify="true" at deploy time and collects submissions for you. Otherwise a service such as Formspree receives the submission and emails it on. Both work well for a contact form. Both mean someone else handles your readers’ messages, and free tiers have limits, so check them.

The simplest contact form is still a mailto: link.

Verdict: WordPress is more flexible; a static site is fine for a single contact form.

Search

WordPress has search out of the box, querying the database.

Static sites used to be weak here. Not any more: Pagefind builds a search index from your finished HTML and runs entirely in the reader’s browser, with no server. For a blog of a few hundred posts it is fast and good. Some generators do not include it by default, though, and adding it may mean a build step.

Verdict: roughly even, with a little more setup on the static side.

Cost

WordPress needs hosting that runs PHP and a database. Cheap shared hosting can do it; decent managed WordPress hosting, which handles updates and caching for you, costs more, and you will want backups on top. Premium themes and plugins often carry yearly licences.

A static site can be hosted on almost anything: a basic web server you reach over SFTP, object storage such as S3 or Cloudflare R2, or the free tiers of Netlify, Cloudflare Pages and GitHub Pages. For a personal blog the hosting bill is frequently zero, and the domain name is the only fixed cost.

Verdict: static.

Speed

A well-configured WordPress site with page caching and a CDN can be very fast. Many are not well configured, and a heavy theme with a dozen plugins can load a lot of scripts on every page.

A static page is already finished when the request arrives. It is trivially cacheable and, with a light theme, small. It is hard to make a static blog slow.

Verdict: static by default; WordPress can match it with effort.

Backups and portability

Backing up WordPress means backing up two things – the database and the wp-content folder – and testing that you can restore them. Plugins such as UpdraftPlus automate this. It is not difficult, but it has to be done.

A static site’s output is a folder of files. Copy it anywhere and you have a working backup of the published site. The source of your posts needs backing up too, wherever your generator keeps it, but there is no database to dump and nothing to reassemble. Moving host means uploading the same files somewhere else.

Verdict: static.

Editing and multiple authors

WordPress has a proper browser-based editor, user accounts and roles (administrator, editor, author, contributor), drafts, revisions and scheduling. A non-technical co-writer can log in from any computer and contribute. That is a real strength.

Most static generators assume one person with a text editor and a command line, and “multi-author” usually means “everyone uses Git”. Tools exist to put a friendlier editor on top, but they add moving parts.

Verdict: WordPress, especially for teams or non-technical writers.

Summary

	WordPress	Static site
Security upkeep	Ongoing	Minimal
Plugins and features	Vast	What the generator provides
Comments	Built in	Third-party or none
Forms	Plugins	Host feature or third-party service
Search	Built in	Client-side (e.g. Pagefind)
Hosting cost	PHP hosting	Often free
Speed	Good with tuning	Fast by default
Backups	Database + files	Copy a folder
Multi-author editing	Excellent	Limited

Choose WordPress if you need plugins, built-in comments or several non-technical authors. Choose a static site if it is your own writing, you want it fast and cheap, and you would rather not be on call for security updates. For more on the hosting side, see how to host a static blog on your own server.

Where Selfish fits

The usual catch with static sites is the command line. Selfish is a native app for iPhone, iPad and Mac – £3.99 once, no subscription – that writes, builds and publishes a static site – over SFTP or to S3-compatible storage, Netlify, Cloudflare Pages or GitHub Pages – with no terminal involved. It does not do comments or forms. It is out now on the App Store, at a £3.99 introductory price, rising to £9.99 in December; the publishing setup guide and Selfish vs WordPress.com have the detail.

Selfish vs Hugo and Jekyll: static sites, with or without code

Thu, 30 Jul 2026 09:05:00 +0100

The short answer: all three produce the same kind of thing, a folder of static HTML you can host anywhere. Hugo and Jekyll are developer tools. They give you templates, total control and a git-based workflow, and they expect a terminal and a text editor in return. Selfish is a native app for iPhone, iPad and Mac. It gives you a finished writing and publishing workflow and much less control over the machinery. If you enjoy building the site as much as writing on it, use Hugo or Jekyll. If you’d rather just write and publish, Selfish removes the toolchain.

For full disclosure, the site you’re reading is built with Hugo. It’s a marketing site with custom layouts, which is exactly the kind of job Hugo is good at.

At a glance

	Selfish	Hugo	Jekyll
Ownership	Yours: files on your hosting	Yours: files on your hosting	Yours: files on your hosting
Cost	£3.99 once, introductory — £9.99 from December. Optional premium themes at £1.99 each	Free, open source	Free, open source
Where content lives	In the app on your device (optional iCloud sync)	Markdown files in a folder, usually a git repo	Markdown files in a folder, usually a git repo
Custom domain	Whatever domain you point at your hosting	Same	Same
Email/newsletter	None	None built in	None built in
Monetisation	None	None built in	None built in
Audience/discovery	None	None	None
Editing	Native composer with toolbar and live preview	Any text editor	Any text editor
Templating	Choose a theme. Add header and footer snippets	Go templates, fully customisable	Liquid templates, fully customisable
Output	Static HTML, sitemap, RSS and JSON feeds	Static site, whatever your templates produce	Static site, whatever your templates produce
Lock-in/export	Standard HTML output. No Markdown file export	Plain Markdown source files	Plain Markdown source files

None of the three gives you an audience, email or payments. Those are platform features, and all three of these are tools.

Where Hugo and Jekyll genuinely win

Flexibility

This is the big one. Hugo uses Go’s html/template and text/template packages. Jekyll uses Liquid. With either, you control every byte of the output. You can build custom page types, data-driven pages, landing pages, documentation, multilingual sites, or whatever structure your content needs. Hugo describes its taxonomy system as “powerful” and it is. Categories and tags are just the start.

Selfish offers a fixed set of choices. You get posts and pages, categories and tags, a theme, and custom header and footer snippets. The four free themes and three premium ones are each a single CSS file. A custom theme editor is something we’re considering, not something that exists. If you need a layout Selfish’s themes don’t offer, a static site generator is the right tool.

Speed at scale

Hugo is written in Go, and its own documentation says it “renders a complete site in seconds, often less”. For large sites with thousands of pages that speed genuinely matters. Selfish is designed for personal sites and skips unchanged files when it uploads. Hugo is the one to reach for when a site gets big.

Git workflows

With Hugo or Jekyll, your content is Markdown files in a repository. That gets you version history, branches, pull requests, collaborators, CI builds, and deploys triggered by a push. Jekyll has a special relationship with GitHub Pages. GitHub’s documentation describes it as having built-in support there. GitHub Pages can only build a limited set of Jekyll plugins itself, and GitHub now recommends GitHub Actions for anything beyond that.

Selfish can publish to GitHub Pages by committing the generated site into a repository. That repo holds the output, though, not an editable Markdown source tree. If your team reviews posts in pull requests, stick with a generator.

Price

Hugo and Jekyll are free and open source. Selfish is a one-time £3.99 purchase — an introductory price that rises to £9.99 in December — plus optional premium themes. If you’re already comfortable in a terminal, the generators cost you nothing but time.

Portability of source

Your Hugo or Jekyll content is a folder of text files with front matter. Moving between generators is work, but the words themselves are never trapped. Selfish stores your writing as a small Markdown subset inside the app. The published output is standard HTML that belongs to you, but Selfish doesn’t currently export Markdown files. Folder export is on the list of things we’re considering. That’s a real difference, and you should weigh it.

Where Selfish wins

No toolchain

Here’s the Hugo quick start at the time of writing:

hugo new project quickstart
cd quickstart
git init
git submodule add https://github.com/gohugo-ananke/ananke themes/ananke
echo "theme = 'ananke'" >> hugo.toml
hugo server

Jekyll’s getting-started guide asks for Ruby 2.7.0 or later, RubyGems, GCC and Make, then:

gem install jekyll bundler
jekyll new myblog
cd myblog
bundle exec jekyll serve

None of that is hard if you’re a developer. But it happens on a computer, it breaks when versions drift, and it’s the reason plenty of people who’d like a static blog never finish setting one up. Selfish has no installation step beyond the app, no dependencies and no build command.

Writing and publishing from an iPhone

Hugo and Jekyll need a computer to build the site. You can wire up a phone-to-git-to-CI pipeline, but it’s a project in itself. Selfish runs natively on iPhone, iPad and Mac. It has autosave, drafts, automatic photo optimisation, photos placed inline where you put them, and a live preview that matches the published page exactly. You write, you publish, and the upload goes straight from your device.

Deployment is included

With a generator, building and deploying are separate problems. You pick a host, script an upload or set up CI, and manage the credentials. Selfish handles SFTP (password or SSH key, with RSA and Ed25519), S3-compatible storage, Netlify, Cloudflare Pages and GitHub Pages directly. It has a Test Connection button and shows per-file progress. Credentials live in Apple’s Keychain, and SFTP host keys are pinned on first use. The publishing docs walk through each route.

Sensible output by default

Out of the box, a Selfish site has a sitemap, RSS and JSON feeds, canonical links, meta tags, responsive themes and automatic dark mode. The themes use no web fonts and no trackers. Hugo and Jekyll can do all of this and more, but the quality of what you get depends on the theme you pick or the templates you write.

Choose Hugo or Jekyll if…

You want full control of templates and site structure.
Your site is large, multilingual, or more than a blog.
You want your source in git, with branches, reviews and CI.
You want your writing stored as plain Markdown files you can take anywhere.
You’re comfortable in a terminal. For Hugo, prebuilt binaries for most platforms. For Jekyll, the Ruby ecosystem and native GitHub Pages support.

Choose Selfish if…

You want a static site without installing or maintaining a toolchain.
You write on an iPhone, iPad or Mac and want to publish from there.
A good theme and header and footer snippets are all the customisation you need.
You’d rather have publishing, credentials and uploads handled for you.

Where Selfish fits

Selfish is on the App Store as one app for iPhone, iPad and Mac, for a one-time £3.99 introductory price that rises to £9.99 in December. It isn’t trying to replace Hugo or Jekyll for people who want to build their own machinery. It’s for people who want the result without the machinery. If that’s you, the user guide shows the workflow and our post on a static site generator without the command line goes into more depth.

The best way to self-host a personal blog in 2026

Thu, 23 Jul 2026 11:20:00 +0100

“Self-hosting” covers a wide range. At one end, you rent a Linux server and run everything yourself. At the other, you keep your writing on your own machine and hand a folder of HTML to a free static host. Both count, because the thing that matters is the same: your words are in a format you control, and you can move them without asking anyone’s permission.

This is a survey of the real options in 2026, with the trade-offs stated plainly. There are two decisions to make: what software produces the blog, and where the result is served from.

Part one: the software

A static site

A static blog is pre-built HTML files. Nothing runs when a visitor arrives; the server just hands over a file.

You can produce those files two ways. The traditional route is a static site generator: Hugo, Jekyll, Eleventy and Astro are the best known. You write posts as Markdown files, run a build command, and get a folder of HTML. The alternative is an app that does the writing and building for you, which avoids the terminal entirely. There’s a longer look at that in a static site generator without the command line.

Cost: the software is free. Hosting can be free too (see part two).
Maintenance: close to none once it’s running. There’s no server-side software to patch on the blog itself.
Security: the best of the three by a distance. There’s no login page, no database and no code executing per request, so there’s very little to attack.
Limits: anything dynamic needs a third-party service. Comments, search and newsletters are bolted on, not built in. The command-line generators also carry a real learning curve.

Ghost, self-hosted

Ghost is an open-source publishing platform with a polished editor and built-in memberships and email newsletters. You can pay for Ghost(Pro), the official hosting, which starts at $18 a month billed yearly at the time of writing, or run it yourself for free.

Self-hosting it is a proper server job. Ghost’s official Ubuntu guide asks for Ubuntu 22.04, 24.04 or 26.04, MySQL 8, nginx, a supported Node.js version and at least 1 GB of RAM, installed through the Ghost-CLI tool. There’s also a newer Docker Compose method.

Cost: a small VPS, plus a transactional email service if you want to send newsletters in volume.
Maintenance: regular. Ghost, Node.js, MySQL and the operating system all need updating, and major upgrades occasionally need care.
Security: reasonable if you keep up with updates. There’s an admin login and a database, so there’s more surface than a static site.
Where it wins: if you want paid subscriptions and email newsletters from your own domain, Ghost does that well, and a static site doesn’t do it at all.

WordPress, self-hosted

WordPress needs no introduction. The self-hosted version from wordpress.org is free software; you supply a server with PHP and a database. At the time of writing, WordPress recommends PHP 8.3 or newer and MySQL 8.0 or MariaDB 10.11 or newer.

Cost: shared hosting or a small VPS. Plenty of hosts offer one-click installs.
Maintenance: the highest of the three. Core, themes and plugins update constantly, and a plugin that goes unmaintained becomes a liability.
Security: a popular target, precisely because it’s everywhere. Automated attacks on login pages and known plugin vulnerabilities are routine. A carefully maintained install with few plugins is fine; a neglected one is a problem.
Where it wins: the plugin ecosystem is unmatched. If you need something unusual, somebody has probably built it.

Part two: where it’s served from

Ghost and WordPress need a server that runs code, so a VPS or managed hosting is your only option. A static site can go almost anywhere.

Your own VPS

A virtual server from a provider such as Hetzner, DigitalOcean or Linode. At the time of writing, Hetzner’s cheapest cloud server is €5.49 a month excluding VAT in Germany and Finland. You install a web server, point your domain at it, and upload files over SFTP. The steps are in how to host a static blog on your own server.

This is the most independent option. Nobody’s terms of service apply except your provider’s, and moving is a matter of copying a folder. It’s also the one that makes you responsible for operating-system updates.

Object storage

S3-compatible storage (Amazon S3, Cloudflare R2, Backblaze B2 and others) can serve a static site directly from a bucket. Cloudflare R2’s free tier, at the time of writing, includes 10 GB of storage a month and charges nothing for egress. That’s more than a personal blog will ever use.

One catch worth knowing: Amazon S3’s static website endpoints don’t support HTTPS. AWS’s documentation points you to CloudFront or Amplify Hosting in front of the bucket, which adds a layer of setup.

Free static hosts

Three platforms will host a static site for nothing, with HTTPS and a global CDN. Their free tiers differ in ways that matter.

	Free tier at the time of writing	Watch out for
GitHub Pages	1 GB published site, soft limit of 100 GB bandwidth a month	Free accounts must publish from a public repository; not for sites that are primarily commercial
Cloudflare Pages	500 builds a month, up to 20,000 files per site	Cloudflare now also offers static hosting through Workers, with a migration guide from Pages
Netlify	300 credits a month on a hard limit	Bandwidth costs 20 credits per GB and each production deploy 15; the paid Personal plan is $9 a month

The Netlify figures deserve a closer look. Under its credit-based pricing, 300 credits covers roughly 15 GB of bandwidth if you spent them on nothing else, and every production deploy draws from the same pot. For a small blog that’s usually fine. But if a post takes off, the free plan doesn’t bill you; it pauses your projects, all of them on the account, until the next billing cycle or until you upgrade. That’s worth knowing before you rely on it.

The honest trade-off with all three: they’re convenient, fast and free, but you’re on someone else’s platform and subject to their limits and policy changes. Because your site is plain files, though, leaving is easy. That’s the difference between hosting on a platform and publishing on one.

So which should you pick

If you want the least work and the most security, use a static site. Host it on GitHub Pages or Cloudflare Pages if free matters most, or on a small VPS if you want full independence.

If you need paid memberships and newsletters, self-hosted Ghost is the strongest option you can own, as long as you accept the server upkeep. Ghost(Pro) is a fair compromise if you don’t.

If you need a specific plugin or a site that’s really an application, WordPress is still the practical choice. Budget time for updates.

For most personal blogs, the answer is a static site. The writing is the point; everything else should be quiet.

Where Selfish fits

Selfish is a native app for iPhone, iPad and Mac, on the App Store for a one-time £3.99 (an introductory price, rising to £9.99 in December), that writes and builds a static blog and publishes it to your choice of SFTP server, S3-compatible storage, Netlify, Cloudflare Pages or GitHub Pages. Your content stays on your device, and the published site carries no Selfish code. The publishing docs explain each route.

How to publish a website over SFTP

Tue, 14 Jul 2026 08:55:00 +0100

SFTP is the least glamorous way to publish a website and one of the most durable. It works with almost any Linux server, most shared hosting and most home NAS boxes. It needs no account with a platform, no build pipeline and no API token that expires. You have a folder of files; SFTP puts them on a server.

This guide explains what SFTP actually is, how to find the four details every SFTP client asks for, how to set up keys properly, and how to fix the errors you’re most likely to meet.

SFTP, FTP and FTPS are three different things

The names are confusingly similar. The protocols are not.

FTP is the original File Transfer Protocol, from the early days of the internet. It usually listens on port 21 and sends your username and password in plain text. Avoid it.
FTPS is FTP wrapped in TLS, the same encryption HTTPS uses. It fixes the plain-text problem but keeps FTP’s awkward separate data connections, which firewalls dislike.
SFTP is the SSH File Transfer Protocol. Despite the name, it isn’t FTP at all. It runs inside an SSH connection, usually on port 22, so it’s encrypted end to end and authenticates the same way SSH does: a password or, better, a key.

If your server lets you log in with ssh, it almost certainly supports SFTP already. OpenSSH, the SSH server on nearly every Linux system, includes it.

The four details you need

Every SFTP client asks for the same things: host, port, username and remote path. Where you find them depends on the kind of server.

	Host	Port	Username	Remote path
VPS	IP address or domain	22 unless you changed it	the user you created, e.g. `deploy`	wherever your web server’s root points, e.g. `/var/www/example.com`
cPanel hosting	your domain or the server hostname from your welcome email	22, or a custom port some hosts use	your cPanel username	usually `/home/<username>/public_html`
Synology NAS	the NAS’s local IP or a hostname	22 by default, configurable	a DSM user account	the Web Station shared folder, `/web`

A few notes on each.

VPS. You set these up yourself, so you know them. The remote path is whatever root says in your nginx or Caddy configuration. If you haven’t got that far, how to host a static blog on your own server walks through it.

cPanel. Not every host enables SSH, and SFTP depends on it. If there’s an SSH Access page in cPanel, you’re probably fine. If not, ask your host. Some use a non-standard port; it’ll be in your account details or their help pages.

Synology. In DSM, go to Control Panel › File Services › FTP and tick Enable SFTP service. The default port is 22. If you use Web Station, it serves files from a shared folder called web, and Synology’s own guidance is that the http group needs at least read permission on it.

Use an SSH key, not a password

Passwords work, but keys are both safer and more convenient. A key pair has a private half that stays on your machine and a public half that you give to the server.

Create one on your Mac or Linux machine:

ssh-keygen -t ed25519 -C "laptop-2026" -f ~/.ssh/id_ed25519_site

Give it a passphrase when asked. Ed25519 has been ssh-keygen’s default since OpenSSH 9.5; spelling it out makes the command behave the same on older systems. A few older tools and hosts only accept RSA. If you meet one, use ssh-keygen -t rsa -b 4096 instead.

Now install the public half on the server. On a VPS where you can still log in with a password:

ssh-copy-id -i ~/.ssh/id_ed25519_site.pub deploy@example.com

On cPanel, go to SSH Access › Manage SSH Keys › Import Key and paste the contents of id_ed25519_site.pub. Then authorise the key. cPanel won’t use a key until you do, and this is the step people miss.

Test it:

ssh -i ~/.ssh/id_ed25519_site deploy@example.com

Check the host key fingerprint

The first time you connect, SSH shows something like this:

The authenticity of host 'example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:JX+wL0OQDpSU1C1rv2FWspDkZeUv7DI8us/vG8Hppbc.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

That fingerprint identifies the server. Typing yes without checking it means trusting whoever answered, which is almost always your server, but checking is how you know.

Get the real fingerprint through a channel an attacker can’t tamper with. Many VPS providers offer a web console; log in there and run:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

If the two match, accept. You can also fetch the key over the network and fingerprint it:

ssh-keyscan -t ed25519 example.com | ssh-keygen -lf -

Be clear about what that proves. ssh-keyscan trusts the network just as much as your first connection does. It’s useful for recording the fingerprint, or comparing it later, but it’s not independent verification.

If the key ever changes, SSH refuses to connect with a loud REMOTE HOST IDENTIFICATION HAS CHANGED warning. Sometimes that’s legitimate: you rebuilt the server. Confirm that’s what happened, then remove the old entry:

ssh-keygen -R example.com

Upload the files

With sftp

The sftp command comes with OpenSSH. From the folder that contains your built site (public here):

sftp -i ~/.ssh/id_ed25519_site -P 22 deploy@example.com

Note the capital -P for the port; ssh uses lower-case -p. Then, at the sftp> prompt:

cd /var/www/example.com
lcd public
put -r *

lcd changes the local directory; put -r * uploads everything in it, recursively. Two limitations: the * skips hidden files such as .htaccess, and sftp never deletes anything on the server. Remove a page locally and it stays online until you delete it by hand.

With rsync

rsync mirrors a folder over SSH, sending only what changed and optionally removing what’s gone:

rsync -avz --delete --dry-run \
 -e "ssh -i ~/.ssh/id_ed25519_site -p 22" \
 public/ deploy@example.com:/var/www/example.com/

Read the output, then run it again without --dry-run. The trailing slash on public/ means “the contents of this folder”. Without it you get /var/www/example.com/public/. And be careful with --delete: pointed at the wrong path, it’ll empty it.

Two caveats. rsync must also be installed on the server; some locked-down SFTP-only accounts don’t allow it. And since macOS Sequoia 15.4, the rsync that ships with macOS is actually openrsync, which supports fewer options. The command above works with it. For the full feature set, brew install rsync.

Common errors and what they mean

Permission denied (publickey). The server didn’t accept your key. Check that you’re using the right username and the right -i key file, that the public key is in ~/.ssh/authorized_keys on the server (or authorised, on cPanel), and that permissions are tight: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys. OpenSSH ignores keys in files other users can write to.

Permission denied when uploading. You’re logged in, but your user can’t write to that directory. Fix ownership on the server: sudo chown -R deploy:deploy /var/www/example.com.

No such file or directory. Wrong remote path. Some hosts restrict SFTP users to their home directory, so / means your home rather than the real root, and absolute paths from the documentation won’t match. Connect, run pwd and ls, and work from what you see.

Connection refused or a timeout. Wrong port, SSH disabled, or a firewall in the way. On a NAS at home, reaching it from outside also needs port forwarding on your router.

The upload works, but the site shows 403 Forbidden. The web server can’t read the files. This happens when your local umask or the server’s SFTP settings create files readable only by you (600). The web server needs directories at 755 and files at 644. Fix everything in one go:

ssh -i ~/.ssh/id_ed25519_site deploy@example.com \
 'find /var/www/example.com -type d -exec chmod 755 {} + && find /var/www/example.com -type f -exec chmod 644 {} +'

The sftp prompt has a chmod command too, but it isn’t recursive, so it’s only practical for a file or two.

Publishing with Selfish

Selfish, a native app for iPhone, iPad and Mac that’s out now on the App Store, publishes over SFTP with the same four details and either a password or an SSH key (Ed25519 or RSA, with passphrases). It pins the server’s SHA256 host key on first connection and refuses to upload if it changes, skips files that haven’t changed, and keeps credentials in Apple’s Keychain. The publishing docs cover the setup screen by screen.

How to host a static blog on your own server

Thu, 09 Jul 2026 10:15:00 +0100

A static blog is a folder of HTML, CSS and images. That is the whole of it. There is no database to back up, no PHP version to chase and no admin login for bots to hammer. Hosting one yourself is mostly a matter of putting that folder somewhere a web server can read it, and then leaving it alone.

This guide covers the practical steps: where the server lives, which web server to run, HTTPS, where the files go, who owns them, and how new files get there.

Pick where it lives

There are three realistic homes for a self-hosted static site.

A small VPS

A virtual private server gives you a Linux machine with root access and a public IP address. For a static blog, the smallest plan any mainstream provider sells is plenty. A static site serves thousands of visitors on hardware that would struggle to run a busy WordPress install.

Prices move, so check before you commit. At the time of writing, Hetzner’s cheapest cloud server, the CX23, is €5.49 a month excluding VAT in its German and Finnish locations, following a price rise in June 2026. Other providers sit in a similar range.

This is the option the rest of this guide assumes. It’s also the most instructive, because you control every layer.

Shared hosting

If you already pay for shared hosting with a cPanel account, you can put a static site there today. You won’t configure the web server yourself; you’ll upload into a folder the host already serves, usually public_html. Many shared hosts now provide free certificates automatically, but check your control panel rather than assuming. The trade-off is less control and occasionally slower support for things like SSH keys.

A box at home

A Raspberry Pi or an old laptop can serve a blog perfectly well. The difficulties are all networking: residential IP addresses change, some broadband providers put you behind carrier-grade NAT so inbound connections never reach you, and some forbid running servers in their terms. If you want to try it anyway, a tunnelling service such as Cloudflare Tunnel runs a small daemon that makes outbound-only connections, so you don’t need to open ports on your router. Your electricity, your uptime, your problem.

Point your domain at it

Before HTTPS will work, your domain has to resolve to the server. In your DNS provider’s panel, create:

an A record for example.com pointing to the server’s IPv4 address
an AAAA record if the server has IPv6
the same records, or a CNAME to example.com, for www

DNS changes can take a while to propagate. Check with dig +short example.com from your own machine before moving on.

Choose a web server

For a static site you want something small, fast and boring. Two sensible choices:

Caddy

Caddy’s selling point for this job is automatic HTTPS. If your domain resolves to the server and ports 80 and 443 are reachable, Caddy obtains certificates from Let’s Encrypt (falling back to ZeroSSL) and renews them in the background. There’s nothing else to install.

Install it from Caddy’s official package repository (the instructions on caddyserver.com cover Debian, Ubuntu and others), then put this in /etc/caddy/Caddyfile:

example.com {
	root * /var/www/example.com
	encode zstd gzip
	file_server
}

www.example.com {
	redir https://example.com{uri} permanent
}

Reload it:

sudo systemctl reload caddy

That is a complete, production-ready configuration for a static blog, HTTPS included.

nginx

nginx is everywhere and extremely well documented. It needs a separate tool for certificates, but that tool does most of the work. On Debian or Ubuntu, install it with sudo apt install nginx, then create /etc/nginx/sites-available/example.com:

server {
 listen 80;
 listen [::]:80;
 server_name example.com www.example.com;

 root /var/www/example.com;
 index index.html;

 location / {
 try_files $uri $uri/ =404;
 }

 error_page 404 /404.html;
}

Enable it, test the configuration and reload:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Add HTTPS

With Caddy, you already have it. With nginx, use Certbot, the Let’s Encrypt client from the EFF. The snap package is the method Certbot recommends:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx -d example.com -d www.example.com

Certbot edits your nginx configuration to add the certificate and an HTTP-to-HTTPS redirect. It also installs a timer that renews certificates before they expire. Confirm renewal works with:

sudo certbot renew --dry-run

Open the firewall, and only that

If you use ufw, allow SSH first so you don’t lock yourself out, then the web ports:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Port 80 stays open even though you serve everything over HTTPS. Certificate challenges and the redirect both use it.

Where the files go, and who owns them

Convention on Linux is /var/www/<domain>. The directory that holds your site should be:

owned by the account that uploads, so publishing never needs sudo
readable by the web server, which runs as its own user (www-data for nginx on Debian and Ubuntu, caddy for Caddy’s packages)

Create a dedicated upload user rather than publishing as root:

sudo adduser --disabled-password --gecos "" deploy
sudo mkdir -p /var/www/example.com
sudo chown deploy:deploy /var/www/example.com
sudo chmod 755 /var/www/example.com

The permissions you want are 755 for directories and 644 for files: the owner can write, everyone else can read. The web server doesn’t need to write anything, and it shouldn’t be able to. If uploaded files arrive as 600, visitors will see 403 Forbidden. Fix them in one go:

find /var/www/example.com -type d -exec chmod 755 {} +
find /var/www/example.com -type f -exec chmod 644 {} +

Add your public SSH key to /home/deploy/.ssh/authorized_keys so the deploy account can log in without a password. Once key login works, consider setting PasswordAuthentication no in /etc/ssh/sshd_config.

Getting files onto the server

Your static site generator, whatever it is, produces a folder: public/, _site/, dist/. Publishing means making the server’s /var/www/example.com match that folder.

The standard ways to do that are SFTP and rsync, both of which run over SSH, so the key you set up above is all the authentication you need. For a one-off copy:

rsync -avz --delete public/ deploy@example.com:/var/www/example.com/

The trailing slash on public/ matters: it copies the folder’s contents rather than the folder itself. --delete removes files on the server that no longer exist locally, which is what you want for a mirror, and exactly what you don’t want if you point it at the wrong directory. Add --dry-run the first time.

SFTP has more to it than fits here: host keys, fingerprints, paths on shared hosting and NAS boxes, and the errors you’re likely to meet. That’s all in how to publish a website over SFTP.

Keeping it running

A static server needs very little maintenance, but not none.

Security updates. On Debian and Ubuntu, sudo apt install unattended-upgrades applies security patches automatically.
Backups. Your source of truth is the copy on your own machine, not the server. If the VPS disappears, you rebuild and re-upload. Keep that local copy backed up.
Monitoring. A free uptime checker that emails you when the site stops responding is worth the two minutes it takes to set up.

That’s it. No plugin updates, no database dumps, no admin panel to secure. This is the quiet reward of static hosting.

Where Selfish fits

Selfish is a native app for iPhone, iPad and Mac that writes your blog and generates the static site for you, then publishes it over SFTP to a server like the one above, with the host key pinned on first connection. It’s on the App Store as a one-time purchase, at a £3.99 introductory price, rising to £9.99 in December. The publishing docs show what it needs from your server: the same host, user, key and path you’ve just set up.

A static site generator without the command line

Thu, 02 Jul 2026 09:40:00 +0100

Static sites are the best way to publish most personal writing. They’re fast, cheap to host, close to unhackable and easy to move. The trouble is that the usual way to make one assumes you’re comfortable in a terminal, and plenty of good writers aren’t. Nor should they have to be.

This post explains what a static site generator actually does, where the friction comes from, and the realistic ways to get the result without the toolchain.

What a static site generator does

A static site generator (SSG) is a program that turns your writing into a finished website before anyone visits it.

You give it three things:

Content, usually posts written as Markdown files, each with a little metadata at the top: title, date, tags.
Templates, which describe how a post page, the home page and an archive page should look.
Configuration: the site’s name, its address, how URLs should be structured.

It gives you back a folder of plain HTML, CSS and images. It also generates the pieces a blog needs around the posts: index pages, tag archives, an RSS feed, a sitemap.

You upload that folder to any web server or static host, and you’re done. Nothing runs when a reader arrives. There’s no database and no admin panel. That’s why static sites are so fast and so hard to break.

Why the toolchain puts people off

The concept is simple. The tooling is not, at least for anyone who hasn’t spent time as a developer. Each popular generator brings its own ecosystem.

Hugo is written in Go and ships as a single executable, which is about as easy as it gets. But themes are commonly installed as Git submodules or Hugo Modules, and Hugo’s documentation lists both Git and Go as prerequisites for modules. If your theme uses Sass, you’ll need the extended edition.

Jekyll is a Ruby gem. Its installation guide asks for Ruby 2.7 or newer with development headers, RubyGems, and the GCC and Make build tools. Getting a working Ruby environment on a Mac is a rite of passage many people would happily skip.

Eleventy needs Node.js 18 or newer and is installed with npm. Astro needs Node.js 22.12 or newer, and its documentation specifically notes that odd-numbered releases such as v23 aren’t supported.

None of that is unreasonable for a developer. But look at what a non-developer has to learn before writing a single post:

installing a language runtime, and later keeping it at a supported version
a package manager, and what to do when it prints forty warnings
Git, at least enough to add a theme
where the content folder is, and what the front matter at the top of each file must look like
running a local preview server, then a build
deploying: SFTP, rsync, or connecting a Git repository to a host that builds for you

And then, six months later, updating something and finding the theme no longer builds. That’s the real cost. It’s not the first afternoon; it’s the maintenance tax on something that was meant to be low-maintenance.

The options that avoid the terminal

There are three broad approaches. Each moves the complexity somewhere else rather than removing it, so it’s worth knowing where it goes.

A CMS front-end on top of an SSG

Git-based content management systems give you a web editor for a site that’s still built by Hugo, Jekyll, Eleventy or similar. Two open-source examples:

Decap CMS (formerly Netlify CMS) adds an editing interface that saves your posts as commits to a GitHub, GitLab or Bitbucket repository.
Pages CMS does the same for GitHub repositories, with no database or extra backend. It’s free and MIT-licensed.

Once set up, these are pleasant for writing. The catch is “once set up”. Someone still has to create the repository, choose and configure the generator, configure the CMS and connect a host that builds on every commit. They’re excellent when a developer sets up a site for a writer. They don’t help much if you’re both.

A hosted builder

Services like CloudCannon take on the whole pipeline: they connect to your repository, build your site, host it, and give you a visual editor. It’s a serious product aimed at agencies and teams, and it’s priced accordingly. At the time of writing its Standard plan is $55 a month, or $49 a month billed annually. That’s good value for a business, and a lot for a personal blog.

A native app

The third approach puts the generator inside an application on your own computer. You write in the app, it builds the site locally, and it uploads the result.

Publii is the established example: a free, open-source desktop app for Windows, macOS and Linux. It includes themes, works offline, and publishes to an SFTP server, Amazon S3, Netlify or GitHub Pages, among others. If you want a desktop tool on any operating system, it’s well worth a look.

The appeal of this model is that the complexity really does disappear rather than moving to a server you have to operate. There’s no runtime to install, no repository to manage and nothing to build in the cloud. The output is a normal static site you can host anywhere.

The limits are real too. You get the themes and features the app provides, not the unlimited flexibility of writing your own templates. You can’t install a plugin to add something the app doesn’t do. And your writing lives in the app’s own storage, so it matters how open that app’s output is.

Where Selfish fits

Selfish takes the native-app approach on Apple devices. It’s a single app for iPhone, iPad and Mac (running iOS 26, iPadOS 26 or macOS 26), on the App Store as a one-time purchase, at a £3.99 introductory price, rising to £9.99 in December.

You write in a plain-text composer with a small formatting toolbar, or type a small subset of Markdown directly. The preview matches the published page exactly. Selfish generates a complete static site, with an RSS feed, a JSON feed, a sitemap and category and tag archives. It then publishes to your own server over SFTP, to S3-compatible storage, or to Netlify, Cloudflare Pages or GitHub Pages. Four themes are free; three more are optional one-time purchases. The themes page shows them all.

It’s fair to be clear about what it doesn’t do. There’s no custom theme editor (it’s being considered, not built), no plugins, no comments and no email newsletters. It’s Apple-only. And if you enjoy crafting templates in Hugo, you’ll find a curated set of themes more limiting than a blank canvas. For that, Hugo is the better tool, and we’d say so.

But if what you want is to write a post on your phone and have it appear as plain HTML on a server you control, without ever opening a terminal, that’s the job Selfish is built for. The user guide shows how it works.

Selfish Blog

A blogging app for iPhone that publishes plain HTML

What to look for

The landscape

WordPress and Jetpack apps

Micro.blog

Ghost in the browser

Working Copy and a static site generator

iA Writer and other writing apps

Summary

Where Selfish fits

Selfish vs Medium: your own site or a borrowed audience

At a glance

Where Medium genuinely wins

Distribution

Getting paid for words

Zero setup

Email to followers

Where Selfish wins

The address is yours, unconditionally

The reader gets a web page

The files are the site

Cost is predictable

Leaving Medium, if you decide to

Choose Medium if…

Choose Selfish if…

Where Selfish fits

Own your blog: leaving Medium for good

Step 1: Download your Medium archive

Step 2: Understand what’s in the archive

Step 3: Choose where the posts are going

Step 4: Move the posts

Step 5: Accept what you can’t redirect

Step 6: Keep a Medium mirror that points home

Step 7: Tell people

Doing the move with Selfish

Selfish vs Substack: a newsletter platform or a site you own

At a glance

Where Substack genuinely wins

Email is the product

Payments are built in

The network

Community features

Where Selfish wins

It’s a website first

Your domain, your root

No platform code on the page

Nobody else’s terms

Exporting from Substack

The combination some writers use

Choose Substack if…

Choose Selfish if…

Where Selfish fits

Substack alternatives that you actually own

What “own” actually means

Ghost

Buttondown

beehiiv

Kit

A static site plus a separate newsletter tool

A quick comparison

How to choose

Where Selfish fits

Selfish vs WordPress.com: hosted platform or static site you own

At a glance

Where WordPress.com genuinely wins

Plugins and the ecosystem

Comments and community

Newsletters and payments

Growing into more

Where Selfish wins

Nothing to maintain

It’s fast because it’s static

No ads, no plan to keep up

Writing in a native app

Your hosting, your choice

Exporting from WordPress.com

Choose WordPress.com if…

Choose Selfish if…

Where Selfish fits