FDE · Deployment

Where Can It Run?

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

Four main targets on a spectrum: your own SaaS (multi-tenant, you host everything), the customer’s cloud account or VPC (you deploy into their environment), on-prem (their own datacenter), and air-gapped (an isolated network with no internet). They range from fastest-to-ship-and-update on the left to most-locked-down on the right, and the customer’s security and data-residency rules usually dictate which one you get.

Q: What decides which deployment target you use?

Mostly the customer’s constraints, not your preference. The biggest is whether data can leave their network — if not, your SaaS is out. Then whether the data is regulated (pushing toward customer-controlled on-prem/air-gapped), whether there’s internet access (no internet forces air-gapped), and how quickly you need to ship updates (fast updates favor SaaS/VPC). You surface these in discovery, because the answer reshapes the whole architecture.

Q: Why is air-gapped deployment the hardest?

Because there is no connection to the outside world. Every container image, dependency, and model weight has to be brought in deliberately through approved channels; updates can’t be pushed and instead ship as signed, versioned bundles installed during maintenance windows; and you often can’t reach the running system to debug it, so you diagnose problems through a customer engineer on a call. That pushes nearly every architectural decision toward self-containment and makes observability and a good runbook essential rather than optional.

Q: Can you change deployment targets later?

It’s possible but painful if you didn’t plan for it, which is why FDEs build portably from the start. If you containerize everything, avoid cloud-only managed services when on-prem is a possibility, externalize config, and keep a path to self-hosting the model, then moving right on the spectrum (say, from VPC to on-prem) becomes a repackaging job rather than a rewrite. If you baked in a single cloud’s managed services and assumed internet access, a target change can threaten the whole project.

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.

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.

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.

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 / 61 Labs done

Explore the topic

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

Forward Deployed Engineering

Where Can It Run?

How it works

Start from a neutral baseline

Data egress dominates

Regulation & internet narrow it

Update cadence breaks the tie

The code

Quick check

FAQ

Keep going

Explore the topic

More Labs

Explore more from Vibe Engines

How it works

Start from a neutral baseline

Data egress dominates

Regulation & internet narrow it

Update cadence breaks the tie

The code

Quick check

FAQ

Keep going

Deploying in Customer Environments →

Deployment Targets →

Security & Compliance for FDEs →

Forward Deployed Engineering →

Explore the topic

More Labs

Explore more from Vibe Engines