The Glover Deployment Model: Bring AI to Your Data, Not Your Data to AI
Article
The Glover Team
There's a slide that shows up in every enterprise AI pitch. The words vary — SOC 2 certified, encrypted at rest and in transit, zero-retention policy — but the ask is identical. Send us your source code. Trust us with it.
For organizations running regulated workloads or core banking infrastructure, that ask is a non-starter. Not because the vendor is untrustworthy, but because the compliance frameworks governing those environments were never designed to accommodate it. The CISO responsible for explaining data handling to the OCC isn't going to introduce a new external dependency so you can try a modernization tool. The procurement team that spent nine months negotiating your cloud provider's BAA isn't starting that process over again.
The standard industry response has been to add more certifications, more audit reports, more contractual language. Some companies have solved it differently. Palantir built Apollo, a deployment control plane that puts their software inside whatever infrastructure the customer already operates — including air-gapped classified networks. GitHub launched Enterprise Server for organizations that need to run their entire development platform on-premises. Snowflake moved toward customer-managed keys and private connectivity. Databricks launched serverless compute that runs within customer cloud accounts.
The pattern is clear: for high-sensitivity workloads, the AI has to move to the data. Not the other way around. Glover Labs was built from day one on this assumption.
What VPC-Native Actually Means
"We deploy in your VPC" has become a checkbox claim. Half the vendors who say it mean they'll spin up a dedicated tenant in their cloud and peer it to yours. That's not the same thing.
When Glover deploys the Archaeologist, the customer pulls an OCI-compliant container image and runs it on their own orchestrator — ECS, Azure Container Apps, Kubernetes, whatever they already operate. There is no Glover-managed infrastructure in the loop. No sidecar phoning home. No telemetry endpoint outside the customer's network.
The application connects to four things, all inside the customer's environment: a PostgreSQL database with pgvector, a secrets provider, a model endpoint, and an object store. That's the entire dependency surface. At startup, the container pulls secrets from whatever the customer already uses — AWS Secrets Manager, Azure Key Vault, or plain environment variables for air-gapped environments. Database connections authenticate through IAM tokens on Aurora or managed identity on Azure, re-authenticated on every connection cycle. No long-lived credentials exist anywhere in the deployment.
The result: Glover Labs has zero runtime access to customer data. The source code being analyzed, the embeddings generated from it, the knowledge graph, the Living Spec artifacts — all of it is created and stored inside the customer's perimeter. We never see it. We can't see it. The container doesn't contain outbound connection logic to Glover infrastructure because there is no Glover infrastructure for it to connect to. Your security team can verify this through network policy, traffic analysis, or container image inspection — the answer will be the same.
Bring Your Own Model, Your Own Cloud, Your Own Everything
Most AI platforms are quietly opinionated about infrastructure. They support one cloud, one model provider, and one embedding strategy — and the documentation describes the others as "coming soon" indefinitely. Enterprise customers have existing cloud commitments and procurement relationships that a modernization vendor has no business asking them to renegotiate.
The Archaeologist implements a provider abstraction layer so the same application code runs identically across environments. Customers on AWS use Bedrock for embeddings (Cohere Embed Multilingual V3) and S3 for storage. Customers on Azure use Azure OpenAI and Blob Storage. An air-gapped deployment using environment variables and a fully managed AWS deployment using Secrets Manager run the exact same binary. The difference between them is a configuration profile — not a fork, not a different build.
The LLM layer follows the same principle. The platform uses Anthropic's Claude models for analysis and code generation — that's what produces the best results on the benchmarks that matter for legacy modernization. But customers route inference through their own API keys, stored in their own secrets infrastructure. The interface is designed so that integrating additional model providers is a configuration change, not a rewrite. Model flexibility isn't a philosophical position. It's an architectural decision that protects customers from vendor lock-in at the intelligence layer.
The Egress Economics Nobody Talks About
The security argument for VPC-native deployment is well understood. The cost argument deserves equal attention.
Legacy modernization is embedding-intensive work. The Archaeologist chunks source code, generates vector embeddings in batches, stores them, and runs similarity searches against them continuously during analysis. In a SaaS model, all of that source code would need to leave the customer's network, get embedded on the vendor's infrastructure, and have the results returned. At scale — millions of lines of COBOL, JCL, copybooks, and associated documentation — the cloud egress costs alone become a material line item.
In a VPC-native deployment, embedding calls travel over AWS PrivateLink or Azure Private Endpoints. They never hit the public internet. No cross-region data transfer fees. No latency penalty from external round-trips. The AI sits next to the data it's analyzing — what infrastructure engineers call data gravity, and what finance teams call not burning money on egress.
This compounds across the pipeline. Embedding generation is only the first pass. The Archaeologist re-queries the vector store during spec generation, code analysis, dead code detection, and every subsequent stage. Each query would be another external round-trip in a SaaS model. In a VPC-native deployment, they're local database reads. The cost difference isn't linear — it's multiplicative across every stage of the modernization pipeline.
For a customer with a multi-million-line codebase, this isn't an abstract comparison. It's the difference between a project budget that survives procurement review and one that doesn't.
Production in Hours, Not Quarters
Shipping a container image is the easy part. Making it operational inside an environment governed by networking rules you didn't write, connected to infrastructure you don't control, reviewed by a security team with high standards — that's where vendor deployments usually stall.
When a customer begins deployment, a Glover Forward Deployed Engineer works alongside the platform team in real time: configuring the application for the specific cloud provider and environment, validating IAM policies for database access and model endpoints, tuning embedding batch sizes and connection pools for the customer's specific quotas, and verifying that container health checks and networking policies are satisfied.
The target is production readiness within 24 hours of first container pull. A single container with four well-defined integration points doesn't require a six-month integration roadmap. The FDE connects four things, verifies they work, and gets the team ingesting code on day one.
There's no SOW negotiation for a "Phase 1 discovery." No twelve-week professional services engagement that produces a deployment plan for a subsequent twelve-week implementation. An engineer shows up, the container goes live, and modernization begins. If something breaks during the first ingestion run, the FDE is there. Not a Level 1 support agent. Not a ticket queue. An engineer who knows the system, working in your environment, in real time.
The FDE model also solves a problem that pure self-serve deployment can't: knowledge transfer. By the time the engagement wraps, the customer's platform team understands how the system is configured, how to scale it, and how to upgrade it. They own the deployment — not just operationally, but intellectually. There is no ongoing "call the vendor" dependency for routine maintenance.
What This Means for Enterprise Buyers
The deployment model question is often treated as an infrastructure detail — something the platform team handles after the business case is approved. That's backwards. The deployment model determines what data you can analyze, which compliance frameworks you can satisfy, what your ongoing cost structure looks like, and how fast you can get to production.
If your modernization target sits behind compliance boundaries, inside regulated infrastructure, or simply represents intellectual property that your board considers a strategic asset, the relevant question isn't whether the vendor's cloud is secure enough. It's whether you should have to ask that question at all.
We built Glover so you don't.