Deployment Targets (Cloud → Air-Gapped)

Q: What is the difference between SaaS, VPC and on-prem deployment?

In SaaS, the vendor runs the software in its own cloud and customers send their data to it, which is the fastest to ship and update but means data leaves the customer’s network. In a VPC deployment, the software runs inside the customer’s own cloud account, so data stays within their boundary while they still get cloud services, though the vendor works within their network and IAM rules. On-prem means the customer’s own servers or data center, with no managed cloud services; the vendor delivers installable packages, and upgrades and debugging go through the customer’s team.

Q: What is an air-gapped deployment?

An air-gapped environment has no connection to the internet at all, and sometimes none to other internal networks either. It is common in defense, intelligence, critical infrastructure and some financial and healthcare settings. Everything the software needs, including container images, model weights, language packages, license files and documentation, must be carried in on approved media and verified with checksums. Nothing can call home, so there is no remote telemetry or license server, and updates arrive as scheduled, versioned bundles. It is the most expensive target to support, so price and plan it accordingly.

Q: What is BYOC (bring your own cloud)?

BYOC is a hybrid model in which the vendor operates the software, but it runs inside the customer’s cloud account. Typically the vendor keeps a control plane in its own environment for upgrades, monitoring and configuration, while the data plane that touches customer data runs in the customer’s account, reached through a narrowly scoped cross-account role or an outbound-only agent. Customers get data residency and their own security controls without operating the software themselves, and vendors keep most of the operational speed of SaaS. The trade-off is a more complex permissions and support model.

Q: How do you update software in an air-gapped environment?

Build a complete, versioned bundle on a connected machine: container images saved as archives, Helm charts or installers, database migrations, model files and dependencies, plus a checksum file and ideally signatures. The customer moves it across through their approved transfer process, verifies the checksums, loads the images into their internal registry and runs the upgrade with their site configuration. Support upgrades from every version you still maintain, test migrations and rollback beforehand, and rehearse the whole process on a disconnected machine, because anything that silently downloads at runtime will fail on site.

Where will it actually run? The tradeoffs across SaaS, the customer’s cloud/VPC, on-prem, and air-gapped — and what each costs you.

Where software runs decides most of what follows: who holds the data, how updates ship, which models you can use, and how you debug at 2 a.m. The targets form a spectrum from your SaaS to air-gapped; each step toward the customer hands them more control and costs you more effort to deliver and support.

Ask “where can this run, and who approves it?” in the first meeting. Then build for the most restrictive target you might face — containers, configuration instead of forks, no hidden internet dependencies — because retrofitting portability is far harder than starting with it.

The targets

Your SaaS (multi-tenant): Fastest to ship + update. Blocked when data can’t leave the customer’s network.
Customer cloud / VPC: Runs in their account. You get cloud tooling but their network + IAM rules.
On-prem: Their hardware/datacenter. You manage installs + updates; no managed services.
Air-gapped: No internet at all. Everything (models, deps, images) ships in by hand. Hardest.
Single-tenant SaaS: a dedicated stack per customer in your cloud — isolation without shipping them software
BYOC: bring your own cloud: your control plane, their data plane in their account, run remotely by you

What changes as you move right

Data egress: SaaS: leaves. VPC: stays in their account. On-prem/air-gap: never leaves.
Updates: SaaS: you push anytime. Air-gap: scheduled, manual, versioned bundles.
Model hosting: Cloud APIs fine on SaaS/VPC; on-prem/air-gap → self-host an open model (vLLM etc.).
Secrets: Their vault, their KMS, their rotation policy — not your .env.
Observability: Your dashboards on SaaS; on-prem you ship logs to their stack or a local one.
Your access: Full on SaaS; on-prem you may get a screen-share and someone else’s hands.
Internet egress: expect an allowlist or none — model APIs, license checks and telemetry may all be blocked
Proxies and custom CAs: set HTTPS_PROXY / NO_PROXY and trust their root certificate, or TLS calls fail
Identity: their SSO (SAML or OIDC) and their directory groups, not your user table
Compliance: a SOC 2 report covers SaaS; FedRAMP, HIPAA or data residency can force VPC or on-prem

Connecting to their network

Private connectivity: AWS PrivateLink, Azure Private Link, GCP Private Service Connect — no public internet
VPC peering: simple routing between two networks — breaks when their IP ranges overlap yours
Cross-account role: an IAM role they create for you, with an external ID and only the permissions you need
Outbound-only agent: software in their network dials out to you — no inbound firewall rules to approve
Customer-managed keys: their KMS key encrypts your data at rest; revoking it cuts you off, by design
Egress allowlist: document every domain your software calls, so their firewall team opens exactly those

Packaging & delivery

Containers + Helm chart: the common denominator for VPC and on-prem Kubernetes installs
Their registry: mirror images into their ECR, ACR, Artifact Registry or Harbor — never pull from yours
Pin by digest: reference images as name@sha256:…, not tags that can move
Signatures and SBOM: sign images (for example with cosign) and ship an SBOM — reviewers increasingly ask
Air-gap bundle: images, charts, model weights, Python wheels and checksums in one versioned archive
Offline licensing: signed license files with an expiry, verified locally — no phone-home
Config, not forks: one values file per site and one codebase — never a customer-specific branch

Operating it

Support bundle: one command that collects logs, versions and config, secrets redacted, to send you
Version support policy: support the current and previous release; on-prem sites lag months behind
Upgrade path: tested upgrades from every supported version, with migrations and a rollback plan
Backups and DR: agree up front who backs up the data and who tests a restore — usually them
Telemetry: opt-in, documented and minimal; air-gapped sites get none, so ship local dashboards
Remote access: agree on a bastion host or supervised screen-share, with session recording, before you need it

De-risk early

Ask in discovery: “Where can this run, and who approves it?” — it reshapes the whole architecture.
Package portably: Containerize; avoid a single cloud’s managed-only services if on-prem is possible.
Plan the update path: How do you ship v2 to an air-gapped site? Decide before v1.
Least privilege: Request the minimum access; security says yes faster to a small ask.
Environment checklist: OS, Kubernetes version, GPUs, proxy, DNS, registry, storage class — collect before designing
Install early: a week-one install in a copy of their environment beats polished code that never deploys

Cost, effort & pricing

Effort ramp: Each step right roughly multiplies deployment + support effort: SaaS ≪ VPC < on-prem ≪ air-gapped.
Who pays for compute: SaaS: you (bake into price). VPC/on-prem: the customer’s cloud/hardware bill — price the software, not the infra.
Support model: SaaS: you see everything and fix fast. On-prem/air-gap: you debug blind through their team — budget for it.
Price the friction: Air-gapped and on-prem deals should carry a premium — they cost far more to deliver and maintain.
GPU reality: Self-hosting an open model on-prem means sizing, buying, and babysitting GPUs — a real project, not a checkbox.

Recipes

Ship a release to an air-gapped site

# connected side
docker pull registry.example.com/app:2.4.0
docker save registry.example.com/app:2.4.0 -o app-2.4.0.tar
helm package ./charts/app                            # writes app-2.4.0.tgz
shasum -a 256 app-2.4.0.tar app-2.4.0.tgz > SHA256SUMS

# move the files across on approved media, then on the customer side
shasum -a 256 -c SHA256SUMS
docker load -i app-2.4.0.tar
docker tag registry.example.com/app:2.4.0 registry.internal/app:2.4.0
docker push registry.internal/app:2.4.0
helm install app ./app-2.4.0.tgz -f site-values.yaml --set image.repository=registry.internal/app

Rehearse the bundle on a disconnected machine first. What breaks is always something that quietly downloaded at runtime — a model file, a tokenizer, a pip package, a font.

Pick the target from the customer’s answers

Can data leave their network?               no  -> VPC, on-prem or air-gapped
Is there any internet egress at all?        no  -> air-gapped
Do they run Kubernetes, and have GPUs?      no  -> a managed VPC deployment, or they buy hardware
Do they want you to operate it?             yes -> single-tenant SaaS or BYOC
None of these blocks it                         -> multi-tenant SaaS: fastest to ship and update

Ask these in the first meeting and write the answers down with who gave them — a security team overruling a business sponsor in month three is the classic way a deal stalls.

Set up a BYOC cross-account role (AWS, high level)

1. publish a role template: trusted principal = your AWS account, ExternalId = unique per customer
2. the customer creates the role in their account, with only the permissions you document
3. your control plane assumes it:
   aws sts assume-role --role-arn arn:aws:iam::<their-account-id>:role/vendor-deploy \
     --role-session-name deploy --external-id <their-external-id>
4. every action lands in their CloudTrail; they revoke access by deleting the role

The external ID prevents the confused-deputy problem, where another customer tricks your service into assuming this one’s role. Keep the permission list short — it is exactly what their security review will read.

Collect a support bundle from an on-prem install

kubectl -n app get pods -o wide > pods.txt
kubectl -n app get events --sort-by=.lastTimestamp > events.txt
for p in $(kubectl -n app get pods -o name); do
  kubectl -n app logs "$p" --all-containers --since=24h > "logs-$(basename "$p").txt"
done
helm -n app get values app > values.yaml            # review for secrets before sending
tar czf support-bundle-$(date +%Y%m%d).tgz *.txt values.yaml

Ship this as a script with the product so their team can run it without you on the call. Redact before anything leaves their network: Helm values often contain passwords.

Questions about Deployment Targets (Cloud → Air-Gapped) Cheat Sheet

What is the difference between SaaS, VPC and on-prem deployment?

In SaaS, the vendor runs the software in its own cloud and customers send their data to it, which is the fastest to ship and update but means data leaves the customer’s network. In a VPC deployment, the software runs inside the customer’s own cloud account, so data stays within their boundary while they still get cloud services, though the vendor works within their network and IAM rules. On-prem means the customer’s own servers or data center, with no managed cloud services; the vendor delivers installable packages, and upgrades and debugging go through the customer’s team.

What is an air-gapped deployment?

An air-gapped environment has no connection to the internet at all, and sometimes none to other internal networks either. It is common in defense, intelligence, critical infrastructure and some financial and healthcare settings. Everything the software needs, including container images, model weights, language packages, license files and documentation, must be carried in on approved media and verified with checksums. Nothing can call home, so there is no remote telemetry or license server, and updates arrive as scheduled, versioned bundles. It is the most expensive target to support, so price and plan it accordingly.

What is BYOC (bring your own cloud)?

BYOC is a hybrid model in which the vendor operates the software, but it runs inside the customer’s cloud account. Typically the vendor keeps a control plane in its own environment for upgrades, monitoring and configuration, while the data plane that touches customer data runs in the customer’s account, reached through a narrowly scoped cross-account role or an outbound-only agent. Customers get data residency and their own security controls without operating the software themselves, and vendors keep most of the operational speed of SaaS. The trade-off is a more complex permissions and support model.

How do you update software in an air-gapped environment?

Build a complete, versioned bundle on a connected machine: container images saved as archives, Helm charts or installers, database migrations, model files and dependencies, plus a checksum file and ideally signatures. The customer moves it across through their approved transfer process, verifies the checksums, loads the images into their internal registry and runs the upgrade with their site configuration. Support upgrades from every version you still maintain, test migrations and rollback beforehand, and rehearse the whole process on a disconnected machine, because anything that silently downloads at runtime will fail on site.

Go deeper

Docker cheatsheet →Security & compliance quick-ref →