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, and calls to a model key if you connect one.

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 node registration implements — on any plan, as an option rather than a tier.

• 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 vendor that lets you run the work layer and charges you the same as a customer whose work it runs is charging you for something it did not do. Whether a provider passes that saving on is the fastest way to tell an architecture apart from a marketing position.

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.

The corollary is equally useful to know: what a plan can reasonably meter is the parts the vendor pays for, which is why an allowance of prospect reveals from a shared pool is a coherent limit and a cap on how many contacts you may store is not. A capability you supply yourself should not be metered at all.

SalesShift works exactly this way. Register a node and the work that touches your data runs on it; connect your own mailboxes or your own model key and that usage stops drawing on your plan allowance entirely — connected model keys spend no AI credits at all. It is available on every plan, including the 7-day free trial, and it changes what you operate rather than which tier you are on. 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 runs the assistant for you by default and meters it in credits, so there is nothing to configure. Connect your own key and it uses that instead — on any plan, and those requests spend no credits. Either way, nothing you write is used as training data and prompts are not retained after the request that made them.

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.