How publishing works
Postwright publishes for you — so it needs a destination to publish to. This is the most important page to read before buying Pro. It lays out exactly where your blog can go, what works out of the box, and what takes extra work.
The model: destinations you own
Postwright is self-hosted and local-first. It runs on your machine, drafts your posts, and then hands each one to a publisher — a small adapter that knows how to deliver a post to one kind of destination. Postwright ships four publisher types, and each brand you run is pointed at one of them:
- Git — writes the post as Markdown/MDX into a repo, commits it, pushes, and waits for your host to deploy. The primary, zero-config path.
- Folder — writes the post into an output directory for a static-site generator (Astro, Hugo, Jekyll, Eleventy, Next.js) that you build and deploy yourself.
- Webhook — sends the rendered post as a signed
POSTto any endpoint you run. This is how a CMS like WordPress connects: your site receives the payload and creates the post. - None — drafts stay in Postwright for you to copy out by hand.
The common thread: the destination is something you own and can point Postwright at. There is no Postwright-hosted blog in the middle.
Blog destinations at a glance
| Destination | Support | What’s involved |
|---|---|---|
| Self-hosted site (Git repo → GitHub → Vercel) | Works out of the box | Point Postwright at your repo checkout and its public URL. Commit → push → deploy → done. This is the reference stack below. |
| Static-site folder (Astro, Hugo, Jekyll, Eleventy…) | Works out of the box | Postwright writes Markdown into your content folder; you build and deploy the site with your own tooling. |
| WordPress (or Ghost, or a custom CMS) | Some setup | Use the webhook publisher: build a small endpoint (or plugin) that receives the signed post and creates it. No prebuilt WordPress plugin ships today. |
| Beehiiv | Custom work | No built-in adapter. You’d write a custom publisher against Beehiiv’s API. (As a newsletter tool, it also isn’t a Postwright email provider — see the newsletter page.) |
| Go High Level | Custom work | No integration. In theory it could receive the webhook, but you’d be building and maintaining that yourself — plan on real effort. |
| Substack | Not supported | Not supported. Substack has no publishing API or import hook Postwright can target — there’s nothing to plug into. |
The reference stack (works out of the box)
This is the exact stack Postwright was built and run on. If you set it up this way, blog publishing works with zero custom code:
- GitHub — a repo that holds your site and its blog content (Markdown/MDX). Postwright commits each post here.
- Vercel — connected to that repo, so every push to
maindeploys automatically. Postwright pushes, Vercel builds, your post goes live. (Netlify or any push-to-deploy host works the same way.) - Resend — for the newsletter side, a verified sending domain for your emails. (Mailgun is also supported.)
A static-site generator (the reference is Next.js with MDX; Astro, Hugo, Jekyll, and Eleventy all work) turns that content into your live site. You own every piece — the repo, the deploy, the domain, the subscriber list.
What actually happens when you publish (Git path)
- Postwright writes
your-post.mdxand a hero image into your repo’s content folder. - It commits just that post’s files (nothing unrelated) with a message like
publish: Your Title. - If pushing is enabled, it runs
git push origin main, which triggers your host’s deploy. - It then polls the post’s live URL until the page responds — so a newsletter that links to the post never goes out pointing at a page that isn’t live yet.
If a commit or push fails, Postwright surfaces the failure instead of recording a phantom success — you always know the real state.
Where this leaves you
If you already run (or are happy to run) a self-hosted site on GitHub + Vercel, everything just works. If you live entirely on Substack, Pro isn’t the tool for your blog. If you’re on WordPress or something in between, budget a little engineering time for the webhook bridge — then it’s automatic from there.