FDE · Deployment

Where Can It Run?

The most consequential decision in a forward-deployed project usually isn’t about the model or the UI — it’s where the thing is allowed to run. That answer lives on a spectrum from your own multi-tenant SaaS, through the customer’s cloud/VPC, to on-prem, to a fully air-gapped network with no internet at all. And it’s driven not by your preference but by the customer’s reality: can their data leave the network, is it regulated, is there internet, how fast must you ship updates. Toggle those four constraints and watch the four targets score against each other — with the reasoning that produces the recommendation. This is the “where can this run?” conversation from the deployment handbook, made playable.

four constraints · four targets · SaaS → VPC → on-prem → air-gapped · the recommendation falls out
data egress

Whether the customer’s data is allowed to leave their network. The single biggest driver of the decision.

VPC

The customer’s own cloud account / virtual private cloud — you deploy into their environment, under their rules.

on-prem

The customer’s own datacenter or servers. You manage installs and updates; no managed cloud services.

air-gapped

A network with no internet connection at all. Everything ships in by hand; the hardest target.

chooser.js — score the targets against the constraints
Answer the four constraints
Toggle the customer’s constraints below. Each answer re-scores the four deployment targets, and the recommended one lights up green with the reasoning. There’s rarely a “perfect” target — just the best fit for the reality you’re handed.
recommended
its score

How it works

The chooser is a tiny constraint-satisfaction model, and building it makes the real decision legible. Each of the four targets starts from a neutral baseline, and each constraint answer pushes the targets up or down according to how well they fit. The most decisive constraint is data egress: if the customer’s data may not leave their network, your own SaaS is essentially ruled out no matter how convenient it is, because SaaS means you host and therefore the data leaves. Regulation nudges toward the customer-controlled end (on-prem, air-gapped), because keeping regulated data inside a boundary the customer already audits is easier to get approved than exporting it. Internet access is nearly binary: no internet forces air-gapped and its manual, brought-in-by-hand everything; plenty of internet makes air-gapped’s friction pure overhead. And update cadence trades against control — if you must push fixes anytime, SaaS and VPC shine; if scheduled maintenance windows are fine, on-prem and air-gapped become viable. The point of the model isn’t a precise number; it’s that the decision is derivable from a handful of constraints you can surface in discovery. The instant you can name those constraints, the architecture stops being a matter of taste and becomes a matter of fit — which is exactly why an FDE asks “where can this run, and who approves that?” before drawing a single box.

1

Start from a neutral baseline

Every target — SaaS, VPC, on-prem, air-gapped — begins equally plausible. Nothing is ruled in or out until the constraints speak.

2

Data egress dominates

If data can’t leave the customer’s network, your SaaS collapses: SaaS means you host it, so the data leaves. The customer-hosted targets rise.

3

Regulation & internet narrow it

Regulated data pushes toward on-prem/air-gapped (easier to approve inside a boundary they audit). No internet forces air-gapped; abundant internet makes air-gapped pure friction.

Update cadence breaks the tie

If you must ship fixes anytime, SaaS/VPC win; if scheduled windows are fine, on-prem/air-gapped become viable. The highest-scoring target is the recommendation — and the reasoning is the derivation.

Biggest driver
can data leave?
Forces air-gapped
no internet
Favors SaaS
ship updates anytime
Ask in
discovery

The code

# The chooser is a constraint model, not a vibe targets = {"SaaS": 50, "VPC": 50, "OnPrem": 50, "AirGapped": 50} if not data_can_leave: targets["SaaS"] -= 40 # you host it → data leaves. Ruled out. if regulated: targets["SaaS"] -= 20; targets["OnPrem"] += 10; targets["AirGapped"] += 15 if not internet: targets["SaaS"] -= 50; targets["VPC"] -= 30; targets["AirGapped"] += 40 else: targets["AirGapped"] -= 20 # air-gap friction with no benefit if updates_anytime: targets["SaaS"] += 20; targets["VPC"] += 10; targets["AirGapped"] -= 15 recommendation = max(targets, key=targets.get) # fit, not taste

Quick check

1. A customer says their data cannot leave their network. Which target is essentially ruled out?

2. What forces an air-gapped deployment?

3. Why does an FDE ask "where can this run?" during discovery, not after building?

FAQ

What are the deployment options for delivering software to a customer?

Four targets on a spectrum: your SaaS (multi-tenant, you host), the customer’s cloud/VPC (you deploy into their environment), on-prem (their datacenter), and air-gapped (an isolated network, no internet). Left is fastest to ship/update, right is most locked-down; the customer’s security and data-residency rules usually dictate which.

What decides which deployment target you use?

Mostly the customer’s constraints: whether data can leave the network (if not, SaaS is out), whether it’s regulated (pushes toward on-prem/air-gapped), whether there’s internet (no internet forces air-gapped), and how fast you must ship updates (fast favors SaaS/VPC). You surface these in discovery, because the answer reshapes the whole architecture.

Why is air-gapped deployment the hardest?

There’s no connection to the outside world: every image, dependency, and model weight is brought in deliberately, updates ship as signed bundles installed in maintenance windows, and you often can’t reach the system to debug it — you work through a customer engineer. That pushes every decision toward self-containment and makes observability and a runbook essential, not optional.

Can you change deployment targets later?

Possible but painful if unplanned, which is why FDEs build portably: containerize everything, avoid cloud-only managed services when on-prem is possible, externalize config, and keep a path to self-hosting the model. Then moving right (e.g. VPC → on-prem) is a repackaging job, not a rewrite. Bake in one cloud’s managed services and assume internet, and a target change threatens the project.

Keep going

Finished this one? 0 / 49 Labs done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

More Labs

Cite this page

Reference it in your work, paper or an AI's context window.

APASingh, S. (2026). The Deployment Target Chooser. Vibe Engines. https://vibeengines.com/lab/deployment-target-chooser
MLASingh, Saurabh. “The Deployment Target Chooser.” Vibe Engines, 2026, vibeengines.com/lab/deployment-target-chooser.
BibTeX
@online{vibeengines-deployment-target-chooser,
  author       = {Singh, Saurabh},
  title        = {The Deployment Target Chooser},
  year         = {2026},
  organization = {Vibe Engines},
  url          = {https://vibeengines.com/lab/deployment-target-chooser}
}