On-prem, VPC or SaaS: FDEs need a map of what runs where

Picture the third meeting with a bank. The demo went well and the business team is on board. Then the head of security asks: can your system run inside the bank’s VPC?

Many engineers new to forward deployed work answer “yes” straight away. That is a risky answer. The customer is asking whose infrastructure the software will run on, where the data will live and what control the vendor keeps.

If you cannot yet describe that setup, “yes” is just a promise, and the security team will later check every detail of it.

Answering that question is part of the job description for many FDE roles. Sierra’s job posting for a Forward Deployed Infrastructure Engineer spells out the scope: designing deployment architecture in customer environments, including VPC configuration, permissioning, networking and infrastructure provisioning.

Anyone who wants this role has to be able to hold a conversation with the customer’s infrastructure team.

Three models, one question: what sits where?

With SaaS, everything runs in the vendor’s account and the customer sends its data across. At the other end is on-prem. Northflank’s documentation describes it as software running on hardware in the customer’s own data centre or private infrastructure. The biggest difference from customer VPC is that on-prem does not sit on a cloud provider.

Customer VPC sits in between: the software runs in the customer’s cloud account. Northflank notes that BYOC (Bring Your Own Cloud) is the same model, described from the customer’s side. So when the customer says “BYOC” and sales says “deployed in the customer VPC”, both sides mean the same thing.

The key detail is this: even when the software runs in the customer’s cloud, the control plane usually stays in the vendor’s account. The control plane handles orchestration, CI/CD, configuration, monitoring and update delivery. So “runs in the customer’s VPC” almost never means that everything sits in the customer’s VPC.

Databricks shows where the boundary lies

Databricks is the easiest example to learn from because its documentation draws the boundary clearly. The control plane consists of backend services that Databricks manages in its own account. The part that runs computation is kept separate as the compute plane.

With classic compute, compute resources run in the customer’s AWS account. With serverless, compute runs in a compute layer inside Databricks’ account. One product gives two different answers to the question “where does computation happen?”. If the customer chooses serverless, it gets more convenience but has to accept that compute no longer sits in its own account.

This is exactly the kind of trade-off you will have to explain to customers. The table below compares the three models against the questions security teams tend to ask.

Question	SaaS	Customer VPC / BYOC	On-prem
Who owns the infrastructure	Vendor	Customer’s cloud account	Customer’s data centre
Control plane	Vendor	Usually still the vendor	Depends on design; sometimes no route back to the vendor
Sensitive data	Leaves the customer	Can stay in the customer VPC	Stays on customer infrastructure
Hardest part for the FDE	Contracts and data flows	Networking, permissions, peering	Updates and support without the cloud

The on-prem column deserves the closest reading. When the control plane has no route back to the vendor, the hard part is no longer the first install but getting updates in. The common mistakes section below comes back to this.

Example: a deployment map for the bank

Back to the bank’s question. Instead of saying “yes”, you promise to send a deployment map. E2B’s BYOC documentation is a good model for writing one, because it lists exactly what stays and what leaves.

According to E2B, sandbox templates, snapshots and runtime logs are stored in the customer’s BYOC VPC. Only anonymised metrics are sent back to E2B’s cloud for observability, and VPC peering allows private connectivity. The BYOC cluster is provisioned with Terraform configuration and machine images.

Your map might look like this (an illustrative template, not the real configuration of any product):

deployment_model: customer_vpc   # the customer calls it BYOC
control_plane:
  location: vendor_account
  responsibilities: [orchestration, ci_cd, config, monitoring, updates]
compute_plane:
  location: customer_aws_account
data_at_rest:            # stays inside the customer's VPC
  - templates
  - snapshots
  - runtime_logs
egress_to_vendor:        # everything that crosses the boundary
  - type: metrics
    anonymized: true
    purpose: observability
connectivity: vpc_peering
provisioning: [terraform, machine_image]
iam: least_privilege_role_for_vendor

(The inline comments read: “the customer calls it BYOC”, “stays inside the customer VPC” and “everything that crosses the boundary”.)

The most valuable part of this file is the egress_to_vendor section. The security team does not need to hear “data never leaves the system”. It needs a complete list of what does leave, in what form and for what purpose.

Five steps to do it yourself

1. Ask the customer which data may live where. Identify which sensitive data must stay on the customer’s infrastructure.
2. Split the product into a control plane and a compute plane, as Databricks does. If your product team has never separated the two, you have just found a project risk.
3. Choose the model and write the map as in the example above, paying particular attention to the egress list.
4. Provision as code. Terraform plus machine images let you rebuild the same cluster for a second and third customer without manual work.
5. Prepare for the work after go-live. Sierra describes the deployment lifecycle as initial deployment, regular upgrades, scaling and incident support, backed by runbooks. Write the runbooks from day one, before the first incident.

Mistakes that stall projects at security review

The most common mistake is treating security review as paperwork. Sierra asks for candidates with experience getting through security reviews, compliance requirements and change management processes. At a large enterprise, a single firewall rule change can wait a full approval cycle, so your plan has to allow for that delay.

The second mistake is assuming there is always a network route back to the vendor. On an air-gapped network there is none. As a direct result, the vendor-side control plane can no longer push updates on its own: every upgrade has to be packaged in advance, transferred into the customer’s network and taken through the customer’s change management process.

Palantir wrote in its IPO filing that its Apollo platform let it deploy into air-gapped or on-prem networks at practically the same speed as in the cloud. That shows the job takes an entire purpose-built platform, not a few extra lines of configuration.

The third mistake is focusing on deployment and forgetting upgrades. A system that runs in the customer’s account without a clear update path slowly falls behind, and every patch becomes a project of its own.

How to show employers you have this skill

When you read FDE job descriptions, look for keywords such as VPC, permissioning, networking, Terraform, BYOC and air-gapped. They signal an infrastructure-heavy role. If your current job does not give you a chance to do this work, a personal project using two AWS accounts is enough to practise.

On your CV, avoid vague lines such as “cloud experience”. Be specific: wrote Terraform to stand up a system in a customer’s account, designed a least-privilege IAM role for the vendor, configured VPC peering, wrote an upgrade runbook. Be ready to explain each of these in detail when asked.

The next time you hear “can this run in our VPC?”, do not rush to answer. Open a blank file and start drawing the map.