Run an open-source churn scan where the customer data already sits
A self-hosted churn tool moves the compute and the credentials; the join key between usage, support and billing is what changes hands. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers.
The schedule is a file; the network is a setting
The scan is defined in the repo, and a self-hosted install keeps its instance and its credentials on your own infrastructure.
triggers:
- slug: daily-churn-scan
name: Daily churn-risk scan
on:
cron: "0 0 6 * * *"
run:
agent: churn-risk
prompt: Load the churn-signals skill and run one complete churn-risk scan.On Kortix Cloud, in your VPC, or on your own on-prem network. Sessions run on Platinum cloud computers in every topology. For an isolated topology, talk to us: we scope it with you.
Self-hosting answers a custody question
Churn prediction ranks accounts by how likely each is to cancel or fail to renew, using evidence that already exists in three systems. A self-hosted churn prediction system is one where that ranking is produced on infrastructure the buyer controls, by a process the buyer can read. Nothing in that definition mentions the model, which is why two products can both call themselves self-hosted and behave in opposite ways.
An account leaves three traces before it goes. A usage curve flattens in the product database. A support thread changes tone in the helpdesk. A payment fails, or a renewal date comes close. Reading all three means recognizing one account in three places that name accounts differently: a domain in billing, a workspace slug in the product, a customer number in the helpdesk. The mapping between those keys is the join key, and whoever holds it can score your customers. Whoever holds the credentials can read them.
The server is the least interesting part of that sentence. What self-hosting changes is custody. The questions that follow are which company holds the credentials into your three systems, which holds the rules that decide what counts as risk, and which keeps the record of who was flagged, and why.
Two things move, and two do not
Hosting moves compute and credentials. It does not move the customer records, because a scan reads them where they sit: usage from the product database, support from the helpdesk, money from the payment provider. What also does not move is the join, and the join is the part that breaks.
Hosting itself is a setting. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.
Three topologies that all get called self-hosted
Each one answers the same question differently: when the sources are joined, where does the joined row exist? Inside a vendor's platform, on a laptop built from three exports, or in memory during a scan that reads each system once. That is the choice a buyer is actually making, and it decides who ends up holding the account mapping a year later.
The vendor holds the platform
Pecan AI builds churn models from historical event-level data in a warehouse such as Snowflake, BigQuery, Redshift or Databricks, and pushes the predictions into a CRM such as Salesforce. Its pricing page lists three plans and states no price (Pecan). Customer-success suites answer the same question inside their own data model. Gainsight includes Health Scorecards in both its plans (Gainsight), ChurnZero sells ChurnScores, a Renewal Hub and machine-learning risk factors (ChurnZero), and Pendo sells Predict as an add-on with custom prediction volume (Pendo). All four are sold as hosted platforms and none publishes a self-hosted option; Pecan takes special deployment requests.
None of these is a bad product, and a team with no engineer is often right to buy one. It is not self-hosting. The joined row exists inside a product you do not operate, the scoring logic is a configuration inside that product, and the account mapping belongs to whoever runs the sync.
The model is yours, and the pipeline belongs to one person
The second shape is the one most tutorials describe: export three tables, join them in a notebook, fit a model, write a score back. The model is genuinely yours, and it can be as good as the data you feed it. The pipeline is the fragile part. A join script owned by one person breaks in the week that person is away, and it breaks quietly, producing an empty column rather than an error.
There is a second cost. The export is a copy. Three tables of usage, support and billing now sit on a laptop or in object storage, outside the access rules written for the systems they came from. The governance problem that self-hosting was meant to close has moved, not disappeared.
The instance and its connections are yours
That leaves the shape where the scan reads each system directly. The agent, the thresholds and the schedule are files in a repo the company owns, the connectors into Postgres, Plain and Stripe are read-only, and the single output is a Slack post. The Kortix churn-risk setup is a working version of it, with the account mapping written as a rule in the skill file, so a wrong join arrives as a diff someone reviews.
One limit survives all three topologies. A self-hosted install keeps its instance, its connectors and its credentials on infrastructure you control, and its sessions run on Platinum cloud computers (Kortix). If the case for self-hosting were the CPU, that would end the argument. The case is the join key, the credentials and the rules, and all three stay with you.
What the first run needs
Five things, in roughly the order they turn out to be missing.
- A repo you control. The agent prompt, the skill that holds the thresholds, and the cron line that starts the run. On Kortix these arrive together as a change request a person approves before the first run.
- Three read-only connections. Product database, helpdesk, billing. Read-only keeps a wrong score a nuisance rather than an incident.
- Somewhere to post the list. A channel the customer team already reads. A dashboard nobody opens is the way these projects die.
- One person who reads it. The scan proposes and a person decides. Without an owner the list becomes another unread report.
- A network path. Sessions run on cloud computers that call back to a self-hosted instance, so budget for that route rather than assuming an isolated one.
The rules are files, and files can be argued with
Thresholds are where a general churn model becomes this company's churn model. The churn-signals skill holds them one to a line. Usage is declining when core activity drops 20% or more against the prior 30 days, and dormant after 14 days with almost no activity. Support friction is rising when thread volume climbs or threads stay unresolved, and cancellation language counts as escalated. Billing is at risk after a missed or failed payment, or a renewal inside 30 days. Under those sits the combination rule. No single signal is high risk on its own, and accounts with declining usage, rising support friction and an imminent renewal or failed payment rank first. Every listed account gets a reason and one next step.
Nothing in this setup writes back. The connectors into Postgres, Plain and Stripe are read-only, so the agent can report on an account but cannot change one, reply to a ticket or touch a subscription. One isolated sandbox per session. Each session has its own isolated machine and branch. The Postgres, Plain and Stripe credentials are encrypted in the Secrets Manager and injected into the sandbox at runtime, scoped to the agents you grant them to. Connector credentials are brokered server-side and never enter the machine.
What that buys is an address for a bad decision. When a threshold turns out to be wrong, the wrongness has a line number, it is changed through a change request, and the reviewed version runs the next morning.
Where a hosted tool is the better buy
Sometimes paying a vendor is right, and those cases are common. A team with no engineer and no repo gets further with a suite that arrives configured. A book of forty accounts is small enough that the person who owns it already knows which three are unhappy, so a ranking adds a dashboard instead of a decision. A buyer who wants the vendor to carry model quality and support has a fair reason to choose one.
The case that does not hold together is choosing self-hosting for the label while keeping the export. That buys the compute and leaves the join key and the credentials where they were.
Self-hosting questions, answered plainly
What buyers ask before they decide where the scan runs.
- What does self-hosted mean for a churn tool?
- It means the instance that runs the scan, holds the connection credentials and stores the scoring rules sits on infrastructure you control instead of the vendor's. The customer records stay in your usage, support and billing systems, and only the ranked list leaves them.
- Can you self-host a churn prediction system?
- Yes. Kortix is open source, and its churn-risk setup is a repo holding an agent, a scoring skill and a daily cron. You run the instance yourself and give the scan read-only access to Postgres, Plain and Stripe.
- Where does the customer data go?
- It stays in the three systems that already hold it. The scan reads them through read-only connectors and writes one Slack post with each flagged account's reason and next step, so the export a hosted tool would ask for is not part of the design.