Your biggest prospect wants it self-hosted: say no, go single-tenant, or build it?

When an enterprise customer wants a self-hosted version of your SaaS, don't build an edition for one deal. Find out which rule they're answering to, then offer the cheapest option that satisfies it: a dedicated instance you run, then your software in their cloud account, then a packaged release they operate. Price the rung you say yes to so that one deal pays for it, and name one owner before you sign.

Each rung up that ladder adds permanent work, and declining is a fourth answer. The skill is stopping at the lowest rung the requirement allows.

What is the customer actually asking for?

"On-prem" is usually shorthand for a rule somebody else wrote. Ask the prospect's security or procurement contact which one it is. It costs you one call and can save you a quarter of engineering.

InfoQ's article on cloud-prem architecture names three common drivers: data sovereignty and compliance, security and trust, and data gravity (the data is already inside their environment and moving it is the problem). Residency usually points to a dedicated instance in an accepted region, security and trust to your software in their cloud account, and data gravity to a self-hosted edition.

If the rule is where data may sit, you may be able to meet it with a regional deployment on a provider they accept, and our guide to European cloud providers and who runs them covers that case. If the real block is a missing report, not a hosting model, getting the SOC 2 report they ask for is the cheaper fix.

Ask three questions on the call. Must it run inside their network? May your staff access the data? Is a dedicated instance in their own cloud account enough?

Which of the four options fits, and what does each cost to keep running?

Option	Who runs it	Main catch
Say no	Nobody	You may lose the deal
Single-tenant instance	You	One more environment to patch
Their cloud account (BYOC)	You, inside their account	Access you can lose
Self-hosted edition	They do	Releases, old versions, blind support

Say no (or "not yet")

Pick this when the requirement is a preference, the deal is small, or nobody on the team could own the result. Every customer-run copy is an instance you can't see into or upgrade on your own schedule, and you'd carry that for one account. A forum answer on Yo Motherboard adds that demand often fades once buyers see the real price. Telling them you're not ready yet, and what it will cost when you are, is a legitimate answer.

A dedicated single-tenant instance you run

The AWS SaaS Lens calls this the silo model: each customer gets its own infrastructure stack or database, but sign-up and operations stay shared, which AWS says is what keeps it SaaS and not a managed service. You keep your own release train and your own access.

You pay for infrastructure per customer and one more environment to patch. It satisfies a rule that data can't share a database with other customers. It usually doesn't satisfy a rule that your staff can't touch it.

Your software in their cloud account

InfoQ defines BYOC (bring your own cloud) as cloud-prem in the customer's cloud account: you run the control plane (the part that manages and updates the software), and their data stays in their data plane (the part that holds and processes it). The customer pays for their own infrastructure.

Your costs are in the environment. You'll need to test across AWS, GCP, Azure and sometimes OpenShift, run pre-flight checks before an install, and hold least-privilege access that the customer can revoke. When something breaks, you work from a support bundle, a packaged set of logs and diagnostics the customer sends you, not from a console you control.

A self-hosted edition they operate

This is the rung where most of the horror stories live. Lago's engineering post describes customer instances as a black box: they couldn't see running jobs or when a migration finished. Adding an organization_id to every table meant a customer who upgraded mid-migration could break data integrity, and Lago couldn't see when migrations finished on their instances. Lago's fix was bridge versions where the old and new schemas coexist.

You also owe a supported-versions policy (InfoQ suggests the current and previous release), a consent-based telemetry set, few dependencies, and support boundaries written into the contract. A Replicated survey of 584 software companies in 2022, sponsored by a vendor that sells on-prem tooling, found 96% had six or more people dedicated solely to on-prem deployment. The sample covered software companies of all sizes, so don't read it as your headcount. Read it as a warning about what shipping a quick installer turns into.

How do I price it so one deal pays for it?

Charge a premium over the cloud plan, sized so the first year's fee covers the build. InfoQ gives the reason: single-tenant setups are less efficient than multi-tenant, so vendors need higher software margins, even though the customer pays its own infrastructure.

Practitioner anecdotes put a number on it. A Hacker News commenter (raydenvm) says self-hosted pricing is often 2-3x cloud. One Yo Motherboard answer says charge at least twice what it costs you to manage, and another a 10x minimum on the SaaS contract.

Put the premium in the contract, with a term long enough to cover the build. List what the fee doesn't cover, such as the customer's proxy configuration and their database performance, so the first support ticket doesn't become an argument.

A worked example

Take a seed-stage B2B SaaS (illustrative) whose bank-adjacent prospect says it wants on-prem or nothing. You ask which rule.

In the first outcome, the rule is that the data must be isolated from other customers and sit in an approved region. Offer a dedicated single-tenant instance, priced above the cloud plan. The packaging work is small because you already run the software.

In the second, the rule is that it must run inside their network. Now you need an installer and an upgrade path. Cost it with a contractor at EUR 45-105 an hour. Assume 8 weeks at 40 hours, which is 320 hours, or EUR 14,400 to EUR 33,600. The 8 weeks is an assumption, a time-box to replace with your own spike's result.

The contract has to cover that, plus the support work after launch. At 2x the cloud plan, the fee clears EUR 14,400-33,600 in the first year only if the cloud plan is about EUR 7,200-16,800 a year or more. If it isn't, say no to the second.

What does it do to my roadmap, and who builds it?

Name one owner before you sign. Packaging is bounded work: an installer or Helm chart, an upgrade path, a support bundle. Once it runs, the job turns into releases and support.

Nobody publishes a per-customer cost for a team your size. To find yours, time-box a packaging spike of a few weeks and count the manual steps that remain.

Our rule: if the engineer who owns your roadmap also owns the install, the roadmap stalls on the first customer incident. Give the packaging to a dedicated engineer or a bounded DevOps engagement, and treat the money as part of the deal, the way you would in a Series A engineering budget.

What goes in the contract before you start?

Keep it short and specific:

A supported-versions policy and an upgrade cadence.
Who has access to the environment, and when.
What happens if they stop upgrading.
Exit terms and source access: what the customer keeps if you shut down, and whether they get your code or only the binaries.

If the customer asks for escrow, read when a customer asks for source code escrow first. For the support terms and response tiers, see what a software maintenance contract should say.

What to tell the prospect on Monday

You don't have to answer an on-prem request with yes or no. Answer with a question about their rule, then with the lowest rung that meets it and a price.

Before you sign anything, settle three things: which rung, what it costs the customer, and who on your side owns the packaging and upgrades. If you can't name the owner, tell them you're not ready yet and keep the deal warm. For the neighbouring decisions that come with a first enterprise customer, our startup scaling guides for engineering leaders are the next stop.

Hiring DevOps help for the packaging job

If nobody on the team can own the installer and the upgrade path, hire for that bounded packaging job alone and keep your roadmap engineers on the roadmap. DevOps engineers through HighCircl come with no minimum hour commitment, so you can buy a fixed packaging block and stop when it's done. Matching takes 72 hours, which fits a prospect who's waiting on your answer.

FAQ

What's the difference between self-hosted and SaaS?

In SaaS, the vendor runs the software and every customer shares one onboarding and operations experience. Self-hosted means the customer runs it on their own infrastructure, so they own the upgrades and you lose sight of how it behaves.

What is BYOC?

BYOC, bring your own cloud, is cloud-prem in the customer's cloud account. The vendor runs the control plane and the data stays in the customer's data plane.

Can we offer single-tenant instead of on-prem?

Often, yes. A dedicated instance you run meets rules about data not being shared with other customers. It won't meet a rule that the software must run inside their network, or that your staff can't access it.

How much should we charge for a self-hosted version?

Practitioner anecdotes range from 2-3x the cloud plan to a 10x minimum. Whatever you charge, the contract term has to cover the build and the support afterwards.