# The Self-Host Upgrade Score: Ranking Open-Core Accounts From Their Repos

*You can read any self-hoster's public repos and produce a defensible upgrade-potential score that sorts it into chase-now, nurture, or ignore.*

- Canonical URL: https://www.refolk.ai/guides/self-host-upgrade-score
- Pillar: Sales and go-to-market
- Format: Framework
- Published: 2026-09-14
- Last reviewed: 2026-09-14
- Reading time: 16 min
- Keywords: score self-host to paid conversion, which open source users will buy enterprise, detect enterprise need from github repo, rank open core accounts to chase, self-hosting deployment scale signals

## Key takeaways

- High-availability config is the single most trustworthy repo signal, because nobody sets ha.enabled=true with a 3-replica Raft quorum for a toy deployment.
- Absence of SSO config proves nothing: OpenObserve ships enterprise stubs not code, and PostHog moved SAML out of env vars from version 1.35.0+, so an empty search is a data gap.
- The conversion math forces ruthless tiering: only 9% of free accounts ever convert to paid, and PQL-qualified accounts convert 3x higher, so chasing the top decile beats working the whole list.
- Company-affiliated committer count beats stars for estimating scale, because stars include hobbyists and competitors who create no seats.
- In Refolk's index the US Kubernetes-plus-Helm operator pool is 5,309 people, roughly 4.2x Germany's 1,274, so a lookalike list thins fast outside the US and each qualified account there deserves more effort.
- The score is perishable: license boundaries drift between releases, so a chase-now verdict must be re-audited on every version bump.

You found a list of companies whose public repositories show they self-host your open-core tool, and now you have to decide which ones are worth a paid or managed-tier conversation and which will sit on free forever. This guide is for founders selling their own product, account executives, SDR leads, and partnerships teams working an open-core motion. It gives you a weighted scoring model with named, repo-readable dimensions and fixed cutoffs, so you can rank forty look-alike self-hosters in an afternoon and route the top ones to a buyer.

Most published guidance on scoring free-to-paid conversion assumes you own the product-usage telemetry inside your app. An open-core rep does not. Before the account ever signs up, all you can see is what the company exposes in its public repos. So this is a framework for one repeated judgement call, made from the outside: read the repositories, score four dimensions, and sort the account into chase-now, nurture, or ignore.

## Why score from repos instead of usage data

Because for a self-hoster, the repo is the only telemetry you get. When a company runs your open-core tool on its own infrastructure, none of its usage flows back to you. The public repository, its Helm values, its docker-compose files, its workflow YAML, and its committer graph, is the entire evidence base you have before a sales conversation exists.

That constraint is also an advantage. A repo shows you things an in-app trial never would: the actual production topology, whether CI is shared across the org, and how many engineers from the same company are touching the deployment. The job is to turn those artifacts into a single defensible number.

The reason to score rather than to eyeball is the conversion math. It argues for ruthless tiering, not volume outreach.

**9% - Share of free accounts that ever convert to paid**

ProductLed's benchmark across 600+ companies; freemium alone converts at 5%, free trials at 17%.

If only 9% of free accounts convert, and product-qualified accounts convert three times higher than the rest, then the return comes from finding the top decile, not from working the whole list. A rank you can defend beats a list you can only work.

## The four dimensions that carry the score

The model scores four repo-readable dimensions, in descending order of trust: deployment topology, enterprise-feature intent, company-affiliated committer breadth, and firmographic fit. Each proves something specific, and each has a way it lies.

No canonical repo-scoring standard is published, so this is a model built from the strongest documented signals, not a citation of one. The dimensions and weights below are the defensible construction; the cutoffs come later.

### Deployment topology, weight 40

High-availability config is the single most trustworthy signal because it is expensive and intentional. Multi-replica settings such as `global.ha.enabled=true`, `replicaCount` above 1, and consensus components running three replicas are the anchor. Dapr's recommended production control plane runs three replicas per component so the Raft consensus algorithm holds quorum even when one replica fails. Nobody sets that up for a toy. It implies a workload someone is paid to keep up.

What it proves: a real production deployment worth insuring against node failure. What it looks like when it lies: a default single-replica install (Appcircle and Redis charts ship one replica by default) scores low but may hide its real production values in a private overlay, and a tutorial repo can contain full HA config that describes nobody's deployment.

### Enterprise-feature intent, weight 25

The presence of SSO, SAML, SCIM, or audit-log configuration proves the account is already reaching for the features you gate behind a paid tier. Supabase enables SAML through a small set of env vars in `.env` and docker-compose; GitLab surfaces SAML as kubectl secrets plus Helm omniauth provider values.

What it proves, when present, is intent to run enterprise controls. What it looks like when it lies is absence: some products move this config out of the repo by design, so an empty search is a data gap, not a no. Treat this dimension as a strong positive when present and a null when absent, never as a negative.

### Company-affiliated committer breadth, weight 25

Distinct company-affiliated committers beat stars for estimating internal dependence, because stars include hobbyists and competitors who create no seats. The documented practice is to check whether multiple users from the same company are active in the repo, review the org's tech stack, then compute calculated fields like open engineering headcount. A refined pattern targets developers who forked the repo and committed regularly for 30 or more days, at companies above a headcount threshold, not yet in the paid customer database.

What it proves is a lower bound on internal users. What it looks like when it lies is overstatement: three committers may front a 200-person org, or may be the entire company. Never convert committers to seats without a headcount cross-check.

### Firmographic and momentum fit, weight 10

ICP fit filters out accounts that will never buy regardless of topology. Apply filtering by company size, domain, funding status, and role, and down-weight hobbyist accounts, competitors, and archived projects.

What it proves is that the account belongs in your pipeline at all. What it looks like when it lies is a beautiful HA setup on a personal org, or a competitor self-hosting to benchmark you. This dimension mostly subtracts.

#### The four scoring dimensions by trust

1. **Deployment topology** - HA config, replica counts, external managed DB. Expensive, intentional, hard to fake.
2. **Enterprise-feature intent** - SSO/SAML/SCIM/audit config. Strong when present, null when absent.
3. **Company-affiliated committers** - Distinct work-email committers over 30+ days. A lower bound on seats.
4. **Firmographic fit** - Size, domain, funding, role. Mostly subtracts; filters out non-buyers.

*Read from the top; the highest layers are the hardest to fake and carry the most weight.*

## What each product actually gates, and whether the repo shows it

The features you sell are often invisible in the repo by design, so before you score enterprise intent you need to know where the gating sits for your product. The table below shows how four well-documented open-core products split their features and how much of that split is repo-visible.

| Product | Gated behind paid | In OSS/self-host | Repo-visible? |
|---|---|---|---|
| Langfuse | project RBAC, audit logs, SCIM, SSO enforcement | org RBAC, SSO | Partly (license key) |
| OpenObserve | code absent from repo | SSO+RBAC free to 50GB/day | Stubs only |
| Supabase | none of the above | SAML self-host | Yes (env vars) |
| HuggingFace | SAML/SCIM (cloud Teams+) | SAML/SCIM in self-host Enterprise Server | Config outside repo |

The lesson is that repo-visibility varies by product, not by account. Langfuse gates project-level RBAC, audit logs, SCIM, and SSO enforcement behind an Enterprise license key, while SSO itself is available in both versions. Supabase puts the SAML engine behind env vars you can read directly. OpenObserve's `src/enterprise/` holds stubs for private crates, not implementations, so you will never find enterprise code there. HuggingFace bundles SAML and SCIM in its cloud Teams tier and its self-hosted Enterprise Server, configured outside the repo.

Before you trust the enterprise-intent dimension for your own tool, confirm which row you resemble. If you are the OpenObserve or HuggingFace row, absence of config in the repo carries no information at all.

> **Watch out:** Absence of SSO config is not a "no"
>
> PostHog deprecated env-var SAML from version 1.35.0+, and OpenObserve ships enterprise stubs rather than code. Scoring an account low because you found no SAML env vars produces false negatives on exactly the accounts most likely to buy.

## The scoring procedure, account by account

Run these eight steps per account. The first seven belong to the rep; the eighth belongs to the SDR lead. Budget roughly 45 minutes of rep time per account, or less once you have templated the greps.

#### Scoring one self-hosting account

1. **Confirm the license boundary** - Clone or open the repo, search for proprietary directories, and read which paths carry a source-available header. You now know which paid features the account cannot legally get for free. Re-check on version bumps.
2. **Read deployment topology** - Grep Helm values and docker-compose for replica counts, ha.enabled, anti-affinity, and external managed Postgres or RabbitMQ. Classify the deployment as single-node, multi-replica, or HA-clustered.
3. **Read the CI and runner footprint** - Check workflow YAML for runs-on self-hosted labels and whether runners are org or enterprise-scoped. Decide whether CI infrastructure is shared across the org.
4. **Detect enterprise-feature intent** - Search for SSO, SAML, and SCIM env vars, omniauth secrets, and audit-log config. Produce a binary flag per gated feature, noting where config lives outside the repo.
5. **Count company-affiliated humans** - Count distinct committers with a company email or org membership on repos that touch the tool, and pull open engineering headcount as a calculated field. Produce an estimated internal user base as a lower bound.
6. **Apply firmographic and momentum filters** - ICP-match on size, domain, and funding, and flag hobbyist, competitor, and archived repos. Keep or discard the account.
7. **Score and tier** - Sum the weighted dimensions and assign chase-now, nurture, or ignore against fixed cutoffs. Produce one integer score plus a tier.
8. **Route to a buyer** - Because frontline developers rarely hold budget, use a prospecting tool to find above-the-line stakeholders and the economic buyer. Attach a named contact to each chase-now account.

An org- or enterprise-scoped self-hosted runner is worth a note in step three, because an enterprise-level runner serves multiple organizations under a single GitHub Enterprise account. That is a strong scale signal that the deployment topology dimension can miss.

**Per-dimension scoring rubric (0 to 100)**

```
Deployment topology (weight 40):
  HA-clustered, 3+ replicas or ha.enabled=true .......... 40
  Multi-replica (>1) but not full HA .................... 24
  Single-node, external managed DB present ............... 12
  Single-node, all-default ................................ 4

Enterprise-feature intent (weight 25):
  SSO/SAML AND (SCIM or audit-log config) present ....... 25
  SSO/SAML config present ............................... 15
  Config lives outside repo for this product ............ null (skip, do not zero)
  Searched, genuinely absent ............................. 0

Company-affiliated committers (weight 25):
  5+ distinct work-email committers, 30+ active days .... 25
  3-4 distinct work-email committers .................... 16
  2 committers .......................................... 8
  1 committer (verify not hobbyist) ..................... 2

Firmographic fit (weight 10):
  ICP company, funded, above headcount threshold ........ 10
  In-ICP but small or unfunded .......................... 5
  Out of ICP / hobbyist / competitor / archived ......... discard account
```

*Adjust the deployment-topology anchors to your tool's chart. Keep the weights fixed so two reps agree.*

> **Rule:** Committer count is a lower bound, never a seat count
>
> Do not convert distinct committers to seats. A refined signal is five or more engineers at a large enterprise committing Kubernetes config, which is enough to trigger an ABM campaign, but always cross-check against open engineering headcount before you size the account.

## Reading the score into a tier

Sum the four weighted dimensions into one integer from 0 to 100, then cut it into three tiers: chase-now at 70 and above, nurture from 40 to 69, and ignore below 40. Any account failing the firmographic filter is discarded before scoring, not tiered.

The cutoffs are deliberately blunt so that two reps scoring the same account land in the same tier. This is the point at which the model earns its keep: it turns a subjective impression into a number a second rep can reproduce.

#### Topology versus committer breadth

Horizontal axis runs from Few committers to Many company committers. Vertical axis runs from Single-node deployment to HA-clustered deployment.

| Quadrant | What it means |
| --- | --- |
| Solo HA setup | Verify it is a company, not a person, before spending effort. |
| Chase-now | HA topology plus committer breadth. Route to a buyer this week. |
| Ignore | Little scale and little internal dependence. Leave on free. |
| Nurture | Real team, small footprint. Watch for topology to grow. |

*The two hardest-to-fake dimensions decide the tier; enterprise-feature intent and firmographics adjust it.*

The chase-now quadrant is where deployment topology and committer breadth both run high. Those are the accounts where the two signals you can least fake both fire, and they justify the effort of finding an economic buyer.

> A rank you can defend beats a list you can only work, because 91% of free accounts never convert.

Once you can describe the top-right quadrant in your own tool's terms, the sourcing becomes a single query rather than an afternoon of manual grepping.

Ask me this: `Companies whose public repos contain Helm values with replicaCount above 1 or ha.enabled=true, with 3 or more committers using company email addresses` - [run the search](https://www.refolk.ai/start?q=Companies%20whose%20public%20repos%20contain%20Helm%20values%20with%20replicaCount%20above%201%20or%20ha.enabled%3Dtrue%2C%20with%203%20or%20more%20committers%20using%20company%20email%20addresses).

*Returns self-hosting orgs that already show HA topology and committer breadth, the two chase-now signals, ready to score.*

Manual GitHub prospecting scales only to about 50 leads before the cost becomes prohibitive, so when your look-alike list runs past that, describing the account you want in plain English is what keeps the work moving. [Refolk](/) takes the repo-readable dimensions from this model and returns the matching companies directly, so you spend your afternoon scoring rather than searching. When a tier fills up, ask Refolk for the next slice of the pattern instead of re-crawling by hand.

## How this goes wrong: the false positives that cost you the afternoon

The scoring model fails in eight documented ways, and every one of them is a false positive or false negative that a cross-check catches. This is the most valuable part of the standard, because a score that overclaims is worse than no score.

| Failure mode | What you see | Cross-check before scoring |
|---|---|---|
| Default-replica false positive | replicaCount: 1, looks tiny | Look for a separate prod values file or external managed DB references |
| Tutorial repo | Full HA config, nobody's deployment | Verify the repo is owned by the target org, not a docs fork |
| Absent SSO read as "no need" | No SAML env vars found | Confirm where the current release stores SSO config |
| Hobbyist scored as account | Impressive HA on a personal org | Check committer email domains and org membership |
| Competitor deployment | Your tool self-hosted at scale | Check the org's own product against your category |
| Archived/abandoned repo | Last commit 18 months ago | Check archival status and recent commit dates |
| Committer count overstates seats | 3 committers scored as a big team | Cross-check against engineering headcount |
| License boundary drift | Score from last quarter | Re-run the proprietary-directory check every version bump |

Two of these deserve special attention because they invert the score. The **absent-SSO false negative** hits your best accounts hardest, since the products that move config out of the repo are exactly the mature ones. The **tutorial-repo false positive** is seductive because a quickstart guide can contain textbook HA config; verify ownership before you get excited, because that config describes a demo, not a workload.

Archival is its own tripwire. Detection tooling exists precisely because archiving a repo can signal abandonment or preparation for deletion, so an archived flag plus a stale commit date means the deployment likely died. Score it zero and move on.

> **Tip:** Build the greps once, run them per account
>
> The topology, runner, and enterprise-intent searches are the same regex every time. Save them as a scriptable checklist so scoring an account is grep, count, and tier rather than fresh investigation each pass.

## Where the market thins, and why geography changes the effort

The same repo signal is worth chasing differently by geography, because the operator pool outside the US is far smaller and a look-alike list exhausts faster. This matters for how much effort a single qualified account justifies.

| Segment (DevOps/SRE/Platform titles) | People |
|---|---|
| US, Kubernetes + Helm | 5,309 |
| Germany, Kubernetes + Helm | 1,274 |
| US, Terraform | 4,884 |

In Refolk's index of professional profiles, the US Kubernetes-plus-Helm operator pool is 5,309 people, roughly 4.2 times Germany's 1,274. The US Terraform pool is 4,884, about 0.92 of the Helm pool. The operational read: in a smaller market like Germany, your list of self-hosters running HA Kubernetes will run out sooner, so each chase-now account there deserves more effort and more persistence before you retire it. In the US you can afford to be strict with the cutoffs because the next look-alike is close behind.

This is why the tier is not the end of the work. A German chase-now account that goes quiet is worth a second and third touch; a US nurture account can wait until its topology grows, because there are thousands more where it came from.

## Keeping the score current

A chase-now score is perishable, so treat it as a snapshot with an expiry rather than a permanent verdict. Two mechanisms decay it: license boundaries move between releases, and deployments change topology as companies grow or abandon them.

Re-audit on version bumps. The proprietary-directory check from step one is the one most likely to go stale, because vendors move features behind source-available licenses release by release. A boundary you audited last quarter may sit under a new license today, which changes what the account can legally get for free and therefore what you are selling them.

Before you hand a chase-now list to sales, run this final verification.

#### Before you route a chase-now list

- [ ] The repo is owned by the target org, not a fork of docs or a quickstart
- [ ] HA config lives in a real prod values file, not a tutorial or an example
- [ ] Committer count is cross-checked against engineering headcount, not read as seats
- [ ] Committer emails resolve to work domains, not personal accounts
- [ ] The org's own product is not a competitor in your category
- [ ] The repo is not archived and has commits within the last few months
- [ ] Enterprise-intent absence was confirmed against where this product stores config
- [ ] The license boundary was re-checked against the current release
- [ ] Each chase-now account has a named above-the-line buyer, not just a committer

The last item is the one reps skip and regret. Frontline developers self-host and configure, but they rarely hold budget. Once an account clears the checklist, use a prospecting tool to uncover the above-the-line stakeholders and identify the economic buyer, so the conversation starts with someone who can sign. A perfect score routed to a committer with no budget is a wasted afternoon; the same score routed to the buyer behind them is a pipeline.

## Frequently asked questions

### Can I score self-host to paid conversion without any product telemetry?

Yes, and this guide is built for exactly that. Published PLG scoring assumes you own in-app usage data, but an open-core rep sees only the public repo before signup. You score on what the repo exposes: deployment topology, enterprise-feature config, company-affiliated committer counts, and firmographic fit. It is a lower-bound estimate, not telemetry, but it ranks look-alike self-hosters well enough to tier forty of them in an afternoon.

### How do I detect enterprise need from a GitHub repo when the SSO config is missing?

Treat absence as a data gap, not a no. Some products move SAML config out of the repo: PostHog deprecated env-var SAML from version 1.35.0+, and OpenObserve ships enterprise stubs rather than code. Cross-check where the current release stores its config before scoring a blank search as no enterprise need. Rely instead on the signals that cannot hide, chiefly HA topology and company-affiliated committer count.

### Which single repo signal is most trustworthy for scale?

High-availability config. Multi-replica settings such as ha.enabled=true, replicaCount above 1, and three-replica consensus components are expensive and intentional. Dapr's documented production control plane runs three replicas per component so Raft can hold quorum through a node failure. Nobody configures that for a toy, so it implies a workload someone is paid to keep running. It is the strongest positive in the model and carries the most weight.

### How many committers does it take before an account is worth chasing?

A usable practitioner trigger is five or more engineers at a large enterprise committing Kubernetes configuration, which is enough to launch an ABM campaign. But committer count is a lower bound on seats, not a conversion rate: three committers may front a 200-person org or may be the whole company. Always cross-check against open engineering headcount before turning committers into a seat estimate.

### Why tier so aggressively instead of working the whole list?

Because the conversion math is brutal. Only 9% of free accounts ever convert to paid, freemium converts at 5%, and PQL-qualified accounts convert three times higher. Working a flat list wastes effort on the 91% that never buy. Ranking to chase the top decile, where HA topology and committer breadth concentrate, returns far more than volume outreach across undifferentiated self-hosters.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/self-host-upgrade-score*