Ship it where they
can actually run it.

Most engineers design a system and then think about where to host it. FDEs invert that, because the hosting environment isn’t a detail you bolt on — it’s the constraint that determines the design. A solution that assumes a hosted model API, a managed database, and your own observability dashboards is elegant and fast to build. It also becomes impossible the moment the customer says “our data can’t leave our network.”

So the highest-value question in discovery is deceptively simple: “Where can this run, and who approves that?” The answer lands on a spectrum, and every step along it tightens what you’re allowed to do — while the customer’s security posture, not your preference, decides where you land.

Think of it as a dial from convenience to control. Your SaaS is maximum convenience for you and minimum control for them; air-gapped is the reverse. Most enterprise AI deployments land in the middle two — the customer’s cloud/VPC or on-prem — where you get some tooling but live inside their rules. The deployment-targets cheatsheet is the quick decision aid.

Each step toward air-gapped changes the same set of concerns. Internalize this table and you can predict what a given target will demand before you start.

The defense against target uncertainty is portability. If discovery hasn’t nailed down the target yet — or if it might change — build so that moving right is a repackaging job, not a rewrite. In practice that means a small set of habits.

Portability isn’t free — it can cost you some of the convenience of a cloud’s managed magic. But paid up front, it turns “we need this on-prem now” from a project-threatening surprise into an afternoon of repackaging.

In the customer’s environment, security stops being your convention and becomes their policy. Secrets live in their vault or KMS with their rotation rules; identity flows through their SSO; and every credential you hold should be scoped to the absolute minimum the job needs. This isn’t bureaucracy for its own sake — it’s exactly what gets a security team to approve you, and approval is often the critical path of the whole deployment.

The question new FDEs forget until it bites them: how do you ship v2? On your SaaS it’s a deploy. On-prem it’s a coordinated release. Air-gapped, it might mean handing someone a signed, versioned bundle they carry in on approved media and install during a maintenance window. Decide this before v1, because an architecture that can’t be updated is a liability disguised as a delivery.

Pair the update path with real observability in their world. You may not be able to watch your own dashboards, so wire structured logs, a genuine health check, and alerts into the stack the customer actually uses — and into a channel their team monitors. On a locked-down deployment, knowing the system broke before the customer tells you is often the difference between a quick fix and a lost account. Once it’s deployed and observable, the work turns to hardening and handoff — making the thing durable and then making it theirs.

The single question that determines your architecture is: can a machine in this environment reach a public IP address, and if so, through what? Ask it in week one, of an operator rather than an architect. The answer moves you along a spectrum, and each step removes a convenience you have never had to think about before.

In a no-egress environment the failures do not appear at provisioning time, which is what makes them expensive. Terraform applies cleanly; the pod schedules; then the image pull times out, the certificate check hangs, and the clock drifts until token validation starts failing in a way that looks like an auth bug. The defence is half an hour of work on day one:

Two items on that list are the ones people miss. STS, because workload identity fails with an error message that names none of this. And NTP, because clock drift produces token-validation failures that look exactly like an authentication bug and will cost you a day the first time.