No vendor lock-in isn't just a marketing phrase — here's what it actually means
Lock-in is data gravity, runtime dependency, and exit cost—not a slogan. Self-hosted control plane, portable gateway core, and APIs you can operate without a vendor's cloud.
- platform
- architecture
- operations
Every vendor claims “no lock-in.” Buyers are right to be skeptical: the phrase is often decoration. Useful due diligence asks what would break if you stopped paying next month—data export, identity integration, traffic paths, and whether your policies live in your network or theirs.
This article names lock-in dimensions platform engineers actually feel—not to score points, but to decide what you optimize for: portability of config, ownership of audit and secrets, and whether your gateway runtime depends on a proprietary hosted control plane.
Lock-in is not “using software”
Using a product deeply is not lock-in by itself—that is called getting value. Lock-in shows up when exit costs are structural:
| Dimension | What traps you | What reduces exit pain |
|---|---|---|
| Data | Config, credentials, audit only in vendor SaaS | Your database, your backups, your region |
| Runtime | Proprietary agent required to serve traffic | Binaries you run on your OS or in your cluster |
| Identity | Only the vendor’s IdP or keys | Standards-based SSO and client credentials you control |
| Egress | Required callbacks to vendor cloud for policy | Policy evaluated inside your perimeter |
| Skills | One vendor’s arcane DSL nobody else knows | Open patterns (HTTP, OpenAPI, Kubernetes) |
“No lock-in” should map to at least one row you care about—not a sticker on a slide.
What Zerq emphasizes by architecture
Zerq’s architecture centers on running in your environment:
- Gateway core as a Go binary—high performance without vendor-specific runtime lock-in on the data plane (see Architecture).
- Management UI, developer portal, config and audit in stores you operate—MongoDB and optional Redis—not only in an opaque multi-tenant control plane.
- Deployment flexibility—on-prem, hybrid, cloud tenant, including fully offline where policy requires it.
That does not mean zero switching cost—migrating any serious platform has cost. It means the cost is yours to engineer around open building blocks, not hidden in someone else’s SaaS accounting.
Honest limitations buyers should still probe
No honest vendor should promise “free exit in a week with no work.” Ask:
- What format is config and audit in—can you export without a professional services project?
- What happens to in-flight sessions and rate limit state during migration?
- Which integrations are standard (OIDC, Prometheus) versus custom?
The Compare page frames Zerq on control, workflows, and deployment flexibility—use it as a starting checklist, not as a substitute for your own architecture review.
For platform engineering leaders
Treat “lock-in” as a risk register item with owners: who can reproduce routing and policy if the vendor disappears? Who owns the data in MongoDB? Who tests restore from backup?
If the answer is “we’d have to reverse-engineer the console,” you are already locked in—regardless of marketing.
Summary: Real portability is provable exit criteria: your data, your cluster, your identity, policy enforced inside your boundary. Demand specifics—not slogans.
Request an enterprise demo to walk architecture, deployment, and operational ownership with your constraints.