Self-hosting your sales data

Self-hosting usually means one of two things, and they are very different commitments. Running the whole application — database, migrations, upgrades, backups, uptime — is a genuine operations project, which is why most teams who say they want it do not end up doing it.

The other version is narrower and much more practical: the account, the interface and the shared data pool stay with the vendor, and the work layer moves to a machine you control. That layer is the part that touches your data and your domain — sending, crawling and enrichment, background jobs, model calls.

Stays with the control plane

Your account, the interface, the shared signal and prospect pool, the record itself.

Runs on your node

Sending, crawling and enrichment, background jobs, calls to your model key.

What you operate

One service, on one machine, kept reachable and patched.

What you do not operate

Schema migrations, application upgrades, the web tier.

That is the arrangement this guide is about, and it is the one SalesShift’s Self-Hosted plan implements.

• Data residency and control. Prospect notes, reply bodies and call context are commercially sensitive, and the honest answer to where does this go is architectural rather than contractual when the answer is your own machine.
• Reputation ownership.Mail leaving your own mailboxes builds reputation for your domain, and it is unaffected by other senders on someone else’s shared infrastructure.
• Cost at the margin. Per-seat pricing charges you for a teammate; running the work yourself does not. For a small team with an existing server, the difference is most of the bill.
• No vendor lock on the expensive parts. Your mailboxes are yours and your model key is yours, so the two ongoing costs of running outbound are contracts you hold directly.

The reason that is not on that list is features. A self-hosted arrangement worth choosing is not a reduced product — it is the same product with the work happening somewhere else.

A free tier is usually one of two things: a trial with a longer expiry, or a crippled edition designed to be annoying. There is a third possibility, and it is worth being able to recognise, because it is the only one that is stable.

Look at what a vendor genuinely pays for in this category: compute to run the work, sending capacity and the reputation behind it, prospect data, and model tokens. A workspace that brings its own node, its own mailboxes and its own model key consumes almost none of them. What is left is a control plane and some database rows.

So the free tier is not generosity and it is not a loss leader — it is an accurate bill. The corollary is equally useful to know: what such a plan can reasonably limit is the parts the vendor pays for, which is why a metered allowance of prospect reveals from a shared pool is a coherent limit and a cap on how many contacts you may store is not.

SalesShift’s Self-Hosted plan is free on exactly this basis, and it includes the whole CRM — pipeline, contacts, tasks and activity history — sequences and campaigns through your own mailboxes, quotes, invoices and e-signature, and unlimited stored contacts. The paid plans are the same product with the sending infrastructure and the compute run by us; see pricing.

This is the part that changes day-to-day behaviour most. Mail leaves the mailboxes you connect, over your own infrastructure, which means the reputation you build belongs to you and travels with you.

It also means the consequences are yours. Nobody else’s bad list affects your placement, and your bad list affects nothing but your own domain — which is an argument for caps, ramps and automatic pauses, not against them. Those controls apply identically whether the node is yours or ours.

Reply detection follows from the same design: replies land in the mailbox that sent the original, so a product that sends through your mailbox can read them, categorise them and stop the sequence. The rotation guide covers how several mailboxes share the load.

Bring your own key means the software calls a model provider with credentials you supply rather than reselling inference through the vendor’s account. The consequences are commercial before they are technical: you pay the provider’s rate, you choose the model, and the prompts go to a provider you have a contract with.

The local option is the interesting one. Pointing the same integration at a model running on your own machine turns where does the data go from a policy question into an architectural one — nothing leaves. The trade is quality against control, which is why being able to choose per task matters more than the choice itself.

SalesShift’s assistive features use the key you connect — OpenAI, Anthropic, or a local Ollama. With no key configured they fall back to a deterministic template and say that is what happened, rather than erroring or implying a model wrote it.

Being straightforward about the downside is what makes the rest credible.

• Availability is yours. A node that is down is a queue that is not moving. Sending and background work stop until it is reachable; the record itself is unaffected.
• Patching is yours. One service on one machine, but it is a machine somebody has to keep current.
• Deliverability is entirely yours. There is no shared reputation absorbing a mistake, which is the point and also the risk.
• Support is narrower by nature. Half of a problem is on infrastructure the vendor cannot see.

For a team of one or two with a server they already run, that is a small price. For a fifteen-person sales org with no infrastructure practice, it usually is not — and the honest recommendation there is the managed version.

Every claim about data ownership resolves to one question: can you leave with your data, without asking anyone? A full export, in a format something else can read, obtained without a support ticket. Ownership that requires a request is not ownership.

The second question is mobility between plans. If the difference between self-hosted and managed is whose infrastructure runs the work, moving is an account change. If the difference is which features exist, moving is a migration — and the direction you can move is the direction the vendor prefers.

The third is the right of the people in your database. A prospect record is personal data, and a right-to-erasure request has to reach every copy — including the ones held by other workspaces — and survive the next crawl of the same public source. SalesShift stores the request as a hash, deactivates the pool record, strips saved copies across every workspace, and checks that hash before any subsequent insert.

If self-hosting appeals for the reasons above, the developer-tools and founder-led sales pages describe the two situations where it most often turns out to be the right call.