Lock-in is a fair thing to worry about. If a tool holds your drafts hostage in a proprietary editor, or ships posts through an integration that only publishes to one CMS, you are one product decision away from losing your content library. That fear is one of the most common objections we hear from buyers evaluating RankMill, and it is worth answering directly instead of hand-waving it away.

The short version: every post RankMill produces is plain markdown with a frontmatter block. The CLI is a thin wrapper around that same data. There is no proprietary format, no vendor SDK to install in your app, no webhook lock. If we vanished tomorrow, your posts would still be a folder of .md files that any static site generator or headless CMS can read.

This post is the practical version of that promise. How the export actually looks, where it drops into common stacks, which CLI commands are worth turning into aliases, and how to keep a review workflow intact once the content has left the RankMill workspace.

What comes out of a run

An approved post exports as one markdown file with YAML frontmatter at the top. Something like:

title: "How to structure a technical blog" slug: "structure-technical-blog" description: "A working outline for practitioner-focused posts." tags: ["content", "seo"] publishedAt: "2026-09-19" approvedBy: "you@yourdomain.com"

How to structure a technical blog

Body content in standard GitHub-flavoured markdown...

The frontmatter fields are configurable per project, so if your site uses pubDate instead of publishedAt, or wants a canonical key, you set that once and every export inherits it. Body content is standard GitHub-flavoured markdown: fenced code blocks, tables, task lists, everything a normal markdown parser handles.

That is the entire artifact. No hidden IDs, no reference tokens, no post-processing needed to render it.

Git-based docs sites and static site generators

If your blog lives in a repo with Astro, Docusaurus, Hugo, Next.js MDX, Eleventy, Jekyll, or anything similar, the workflow is short:

rankmill export --post <id> --out content/blog/

That drops the file into your content directory. Commit, push, let your existing build pipeline take over. There is no runtime dependency on RankMill. The site would keep working if you deleted your account.

A few commands worth aliasing:

alias rm-pull='rankmill export --approved --out content/blog/' alias rm-status='rankmill runs list --status in_progress' alias rm-log='rankmill runs logs --follow'

rm-pull grabs every approved post you have not yet exported and drops it into your content folder. rm-log streams the live agent log for a running job, which is useful if you are watching a research or writer agent work and want to jump in for the human approval checkpoint the moment it opens.

For teams that want the pull to happen without a human running it, a GitHub Action on a schedule works fine. Point it at the same --out folder, open a PR when new posts land, and let a reviewer merge. The important part: the artifact lives in Git the moment it is exported, which is where you want your source of truth anyway.

Headless CMS setups

Contentful, Sanity, Payload, Strapi, Hygraph, and Directus all accept markdown as either a rich text field or a raw string field. The export is the same, but instead of writing to disk you pipe it through the CLI into the CMS API:

rankmill export --post <id> --stdout | your-cms-import-script

Most CMS platforms have a small ingest script pattern already documented for their SDK. The frontmatter maps to CMS fields, the body maps to the content field, and you are done. This is a five-line script in most cases, not an integration project.

A pattern that works well for agencies running multiple clients: one shared import script per CMS, and per-project frontmatter mappings so a client on Sanity and a client on Payload can share the same RankMill workflow without either team knowing the other exists.

Notion

Notion is the one that surprises people, because Notion does not accept raw markdown through its API in a lossless way. The pragmatic answer is a converter. martian and similar libraries turn markdown into Notion's block format cleanly, including headings, lists, code blocks, and callouts.

rankmill export --post <id> --stdout | node import-to-notion.js

One catch: Notion's block model does not have a one-to-one mapping for every markdown feature, so nested tables and complex code fences can lose fidelity. If your team drafts in Notion and publishes elsewhere, the cleaner pattern is to keep the markdown file as the canonical source and use Notion for review only. That keeps the export honest.

Ghost

Ghost accepts markdown natively through its Admin API. The CLI export can be piped straight into a Ghost import script that hits /admin/posts/:

rankmill export --post <id> --format ghost --stdout | ghost-import

The --format ghost flag adjusts the frontmatter keys to match what Ghost expects, so description becomes custom_excerpt, tags gets shaped the way Ghost wants, and you do not need to write a translation layer. Similar format flags exist for other common targets, so you are not constantly reshaping YAML.

The review workflow after export

Human approval inside RankMill is one gate. Most teams want a second gate in their own stack, whether that is a PR review, a CMS scheduling step, or a copy editor's pass. The export is designed to survive both.

For Git-based sites, the natural pattern is:

1. Approve the post inside RankMill so it becomes exportable.
2. rm-pull writes it to a new branch and opens a PR.
3. Your team reviews the diff in GitHub or GitLab, requests changes if needed.
4. Merge triggers the deploy.

When changes are needed, there is a split worth being explicit about. Small edits (a typo, a link fix, a tighter sentence) belong in the PR. Substantive revisions (a section that missed the mark, a tone that drifted) belong back in the editor agent inside RankMill, because that is where the brand voice rules and writing rules live. If you edit the markdown in your repo, that change does not flow back into the pipeline, and the next post will make the same mistake.

For CMS setups, the pattern is similar but the review happens in the CMS's own preview UI. Same rule applies: fix small things where they are, push substantive fixes back through the editor agent.

Commands worth having in muscle memory

A shortlist of the CLI verbs that come up most often:

• rankmill runs list shows the state of every research and writing run
• rankmill runs logs <id> --follow streams the live agent log
• rankmill runs approve <id> accepts a research proposal or a draft
• rankmill runs revise <id> --message "..." sends a change request to the editor agent
• rankmill export --post <id> --out <path> writes an approved post to disk
• rankmill export --approved --since 7d bulk-exports everything approved in the last week
• rankmill projects config opens the writing rules, brand voice, and banned words for the current project

None of these are essential to using RankMill. The web app covers all of them. They exist because a lot of practitioners live in a terminal, and if a script can do it, a script should be able to do it.

Why the export exists at all

The honest reason to build an escape hatch into your own product is that the buyer objection is a real one and the answer needs to be structural, not verbal. A promise that you will not lock customers in is worth nothing if the file format is proprietary. A markdown export with a documented CLI means the promise is enforceable by the customer, without asking anyone's permission.

The side effect, which turned out to matter more than the objection itself, is that markdown and a CLI slot into how content teams already work. Version control, PR reviews, CI checks, scheduled deploys, editorial calendars in Notion, custom import scripts for whichever CMS a client happens to be on. None of that requires special integration work, because the artifact is a text file and the interface is a shell.

Your content stack is already good at moving text files around. RankMill just produces text files that fit.