RankMeFast: a self hosted SEO platform that calls vendors with your own keys

The pitch is bring your own keys, not bring your own crawler

Most SEO suites are closed SaaS with per-seat pricing, and your data stays on their servers. RankMeFast takes the opposite position on both counts, and the design decision that follows from that is the one thing to understand first.

RankMeFast does not crawl the web or scrape Google itself. It calls data vendors, namely DataForSEO, Google APIs, Firecrawl and optionally an LLM provider, with your API keys, and there is no markup on top. So the platform is the orchestration layer, the dashboards, the reports and the scheduling, and the actual data acquisition is billed by whoever you have an account with.

The second point in the same list is where your data goes. Everything lands in your own MongoDB and PostgreSQL, and users can export their data or schedule account deletion themselves. That is what self hosted means in practice here, as opposed to running a copy of a vendor's software against a vendor's API and a vendor's server.

The third point is the one that decides whether the software is worth your time before you spend a cent. Every provider has a fake backend that returns fixed demo data, so you can try the whole product before paying any vendor. A platform that lets you click through audits, ranks and keyword research with no keys at all is unusual, and it makes the first hour of evaluation cheap.

The fourth point is the one to read carefully, because it cuts across the privacy claim. Vendor responses are cached across users, so you do not pay twice for the same keyword or URL while the cached copy is still fresh. That is a real cost saving for a team auditing the same competitive keywords. It also means a cached vendor response can be served to you from a copy originally fetched by another user of the same instance.

Feature flags decide which vendors you actually pay for

The feature table is long, and the important part is not any single row.

Site audits crawl a site, run 26 automated checks and produce a Fix now / Watch / Passed report with an optional AI summary. Rank tracking covers Google organic positions over time plus Bing, YouTube and Amazon, with SERP features, confirmed-drop alerts and a local geogrid. Keyword research gives volume, difficulty, trends, SERP-overlap clustering and cannibalization reports from Search Console data. Links and competitors covers backlink profiles, link-gap analysis, toxic-link review, competitor discovery and content comparison. Google integrations pull in Search Console for performance, URL Inspection and sitemaps, along with GA4, PageSpeed Insights and CrUX.

The AI visibility area tracks prompts in AI Overviews and LLM answers, measures share of voice and sends a weekly digest. Content tools generate briefs, suggest internal links, produce schema.org markup and monitor changes to public pages. Local and app SEO covers business listings, reviews, local-pack ranks and App Store and Google Play optimisation. Reporting includes PDF and CSV exports, scheduled white-label client reports, read-only share links, a Looker Studio connector, a read-only REST API and an MCP server for AI assistants. Teams get seats, invites and alert rules delivered by email, Slack or signed webhook.

What makes that tractable is stated plainly: each vendor-backed feature has its own feature flag and provider setting, so you only turn on the ones you have keys for. You are not billed for the whole catalogue the moment you deploy it. You pay for the vendors you connect, and nothing else.

The interface is available in seven languages, English, Arabic with right to left layout, French, German, Spanish, Russian and Chinese, across the UI, the emails and the docs.

The stack is three databases, and Postgres is the deliberate exception

The Compose file is the clearest statement of the architecture, and it runs three stores rather than one.

Mongo runs as the default document store on image mongo:7, with a healthcheck that runs mongosh with a ping evaluation, a 512m memory limit and its own volume. Redis runs as redis:7-alpine with appendonly enabled and a 256m limit. Postgres runs as postgres:17-alpine, and the comment in the compose file explains its role precisely: it holds ordered time-series data, which the comment lists as rank history, keywords, backlinks, competitors, subscriptions and usage counters, while Mongo stays the default document store and Postgres is the deliberate, scoped exception.

That is a defensible choice rather than an accident. Rank history and keyword time series are queried by range and ordered, which relational storage handles naturally, while the rest of the domain is document shaped. The cost is a third stateful service to back up and a split data model that a maintainer has to keep in mind.

The services also carry hard resource limits, 512m for Mongo and Postgres, 256m for Redis, and log rotation is configured with a 10m maximum size and three files kept. Postgres has no published host port, the comment says internal network only, and the compose networks section defines a bridge network named rankme that the service hostnames resolve on.

The compose header states the configuration rule outright: the root .env only, never Docker secret files, never baked into images. The .env.example repeats it, calling the root .env the single source of truth and saying it is consumed by docker compose at compose time and by the api runtime container, with no .env files in subdirectories.

Getting it running, and the two secrets you must not lose

The requirement is Docker with the Compose plugin, and the whole stack comes up with one command. The quick start is:

git clone https://github.com/SelmiAbderrahim/rankme.fast.git
cd rankme.fast
cp .env.example .env

Then you edit .env. The minimum for a local install is a small set of variables. BETTER_AUTH_SECRET and MASTER_ENCRYPTION_KEY each take the output of openssl rand -hex 32, and they must be different values. POSTGRES_PASSWORD and DATABASE_URL need the same random password in both places, and the three URL variables, CLIENT_URL, APP_URL and VITE_SITE_URL, point at http://localhost:3000 while SERVER_URL points at http://localhost:8080.

One instruction is worth repeating. Back up MASTER_ENCRYPTION_KEY. Losing it makes every stored secret, including OAuth tokens and channel credentials, unreadable. That is not a recoverable accident, because the key encrypts data that only the key can decrypt.

Starting the stack is:

make build-up            # or: docker compose up -d --build
make ps                  # every service should be healthy

You then open http://localhost:3000 and create an account. The Makefile wraps Compose in a control plane, with the project name rankme set in the compose file and every target going through docker compose against the root .env. The build-up target builds, starts detached and then waits until all containers are healthy, with a HEALTH_TIMEOUT defaulting to 300 seconds.

The operational targets are worth learning early. down stops and removes the containers while preserving the volumes, ps shows container status, logs follows the last 100 lines, and there are backup and restore targets that write logical dumps into a BACKUP_DIR defaulting to backup.

Fake providers are a demo mode, and production refuses them

The fake backends are guarded, and the guard matters more than the feature.

With NODE_ENV=production the fakes are refused unless you opt in explicitly:

ALLOW_FAKE_PROVIDERS=true
EMAIL_TRANSPORT=fake

The instruction attached to that block is unambiguous: never enable this on a public deployment. The .env.example ships ALLOW_FAKE_PROVIDERS=false, with a comment saying production rejects every PROVIDER_*=fake selector and EMAIL_TRANSPORT=fake unless the escape hatch is true, and to keep it false for real deployments.

This design is better than the usual alternative. A demo mode that silently serves fixed data in production produces audits that look real and are fiction, and the person reviewing them has no way to tell. Here the failure mode is inverted: an instance without credentials refuses to start and names the missing variable, and it never quietly falls back to the fake data.

Setting a provider and leaving out its credentials is a startup error rather than a runtime surprise. The documentation is explicit that the app refuses to start and tells you which variable is missing.

Two more environment entries are worth knowing. SUPERADMIN_EMAIL and SUPERADMIN_PASSWORD seed an operator account on first boot. And the email transport is a separate concern from the data providers, so you can have real vendor data and a fake mailer, or the reverse, which is how you can test alert rules without sending real email to anyone.

Where this platform does not fit

The boundaries here are structural rather than incidental, so it is worth stating them plainly.

If you want a crawler of your own, this is the wrong tool. RankMeFast does not crawl the web or scrape Google itself. The audit feature exists, with 26 automated checks, but the crawl and the data acquisition are done by the vendors you connect. Teams that need to crawl sites the vendors will not touch, or that need raw HTML capture at scale, will find the platform dependent on what DataForSEO and Firecrawl will do for them.

Second, the shared cache cuts both ways. It saves you paying twice for the same keyword or URL while a cached copy is fresh, which is a genuine saving on a team auditing the same competitive terms. It also means responses are shared between users of the same instance, so if you run a multi tenant instance and consider vendor response data sensitive, that is a design choice you inherit rather than configure.

Third, the project says so itself. The status is public beta, with an expectation of rough edges and breaking changes between releases, and bugs are reported through GitHub issues. There are no GitHub releases for the repository at all, so the version marker in the README, 0.1.0, is a label rather than a release you can pin and diff.

Fourth, operating the stack is real work. Three stateful services, a job layer, and encrypted vendor credentials that must survive a migration. For a single consultant or a small team that wants its audit data to stay in its own database, that is a good trade. For an organisation that just needs reports, it is a lot of surface area to own.

The comparisons this project wants, and where it actually differs

The repository topics list Screaming Frog and Semrush among others, alongside terms like semrush-alternative and semrush-free, so it is clear which tools it is positioning against. The README itself only makes one comparison directly, about closed SaaS suites with per-seat pricing where data stays on the vendor's servers.

The honest way to place it is along two axes that the code confirms.

On data acquisition, a desktop or desktop-style crawler takes its own approach: it fetches pages itself with its own crawler and computes most metrics locally, so the recurring cost is your own infrastructure and the analysis is under your control, but the data coverage is limited to what you crawl and rank data often comes from elsewhere anyway. RankMeFast delegates acquisition to DataForSEO, Google APIs and Firecrawl, which means broader coverage of search and AI results for a per-call vendor bill, and less of the analysis is yours to own.

On operation, a hosted suite is zero to run and closed to inspect. RankMeFast is the opposite end of that axis: you run the containers, you hold the keys, you hold the data, and you read the source under AGPL-3.0.

The part of the comparison that is often left out is that the vendor accounts and their pricing still exist. This is not a free replacement for a paid suite. What changes is where the bill goes and whose servers hold the data, and the fake backends make that difference testable before you commit a cent.

Editorial conclusion

Adopt RankMeFast if you want an SEO platform on your own infrastructure, if you already hold vendor API keys, and if you are willing to run the Mongo, Redis and Postgres stack it needs. Skip it if you expect a crawler of your own, because the platform does not crawl the web or scrape Google itself, it calls vendors on your behalf. Verify first that you can set MASTER_ENCRYPTION_KEY and keep a backup of it, since losing it makes every stored secret unreadable, and leave ALLOW_FAKE_PROVIDERS at false on any deployment reachable by other people.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. SelmiAbderrahim/rankme.fast on GitHub