After this lesson, you will be able to:
- Map a customer's security constraints to the deployment model they imply
- Explain how each model changes releases, debugging, and model access for LLM systems
- Start the security review early enough that it does not become the schedule
- Prepare for air-gapped work, where every habit that assumes internet dies
On your laptop, deployment is a solved problem: push, and a platform does the rest. Forward deployment breaks this in a specific way. You do not choose where your code runs. The customer's constraints choose, and your job is to deliver the same working system in whichever world you are handed.
There are four worlds. Each one takes away something you currently assume is free.
#The four worlds
Work through the constraints below before reading on. The exercise to notice: each toggle is something a security review says to you, and each one closes doors.
Vendor SaaS is your home turf. Customer data comes to your platform, you operate everything, and shipping feels like normal engineering. The security conversation is about your certifications and your data handling, not your architecture.
Customer VPC moves your software into their cloud account. Data never leaves their walls, which unblocks most residency requirements. The price: you deploy through their pipelines, wait on their approvals, and debug over audit-logged screen shares. Your access is a privilege they grant, scoped and revocable.
On-premises means their hardware. Capacity becomes a negotiation, GPUs may be older than your model assumes, and releases stop being deploys you push and become versioned artifacts they install. Every dependency your build casually pulls from the internet must now be vendored, pinned, and shipped inside the artifact.