Deployment

Designed for self-hosted, scoped per environment

Two deployment shapes — single-tenant on your infrastructure or multi-tenant SaaS. Either way: your CI/CD plugins, your identity provider, your LLM. Implementation timeline is sized to your environment, not a marketing number.

Book Demo See platform security

Two deployment shapes

Self-hosted (single tenant)

For who: Regulated industries: BFSI, healthcare, government. Anyone whose security policy bars sending API specifications to third-party services.
Runs on: A Windows server you control, on-prem or in your cloud account. The installer sets up the backend as a Windows service plus the desktop client, against your own MongoDB, connected to your internal network. SSO is configured against your identity provider on Enterprise and the Trial.
Data posture: API specs, credentials, prompts, generated tests, and audit logs all stay within your infrastructure boundary.

Multi-tenant SaaS

For who: Teams that don't need data residency or air-gapped operation. Faster onboarding, no infrastructure overhead.
Runs on: Hosted by us with subdomain-based tenant isolation and per-tenant database segregation.
Data posture: API specs and audit logs stored in a database per tenant; credentials AES-256-GCM encrypted at rest.

SaaS · Private cloud · On-prem · Air-gapped

Same platform, four deployment shapes. Pick the one that fits your authorization boundary — not your vendor's preference.

Dimension	Multi-tenant SaaS	Private cloud (single-tenant)	On-prem	Air-gapped
Where it runs	Our infrastructure (multi-tenant)	Your AWS / Azure / GCP account, single-tenant	Your data center (single-tenant)	Your isolated / classified network; testing and AI with a local model need no internet access
Who manages it	We do	You operate; we support	You operate; we support via approved channels	You operate; updates via approved one-way transfer
AI inference path	BYO LLM key (cloud) or self-hosted endpoint you control	Self-hosted LLM inside your account; or BYO key	Self-hosted LLM inside your network; no required egress	Self-hosted LLM only (Ollama / vLLM / LM Studio)
Outbound network egress	Standard SaaS egress to your published API endpoints	Your VPC controls; testing and AI with a self-hosted LLM need no vendor egress. Licence validation and updates contact us unless arranged otherwise	Testing and AI with a local model need no vendor egress. Licence validation and updates contact us unless arranged otherwise	None for testing or AI with a local model; telemetry is off by default; licence validation and updates contact us, so ask about offline licensing for air-gapped installs
Updates	Continuous (we deploy)	You install updates on your cadence (installer with update and rollback)	You install updates on your cadence (installer with update and rollback)	You import installers via approved offline transfer
Typical regulatory context (yours, not an authorization of ours)	B2B SaaS, less-regulated workloads	GDPR, NYDFS Part 500, NAIC, mid-tier regulated	HIPAA, PCI-DSS, BFSI core	FedRAMP High / IL5 / IL6, sovereign cloud, classified
Time-to-live	Hours	Days to a few weeks	2–6 weeks depending on IdP / network	4–12 weeks; bounded by your offline transfer cadence

For deeper detail on the air-gapped pattern see the air-gapped API testing guide; for on-prem buyer evaluation see the on-prem buyer checklist.

Stack at a glance

Backend
Node.js 20 + Express, installed as a Windows service against your own MongoDB (4.4 or later). License + edition system gates features per tier. There is no Docker or Kubernetes image for the backend and no HA / clustering configuration today.
Frontend
React 18 SPA (CRA + CRACO), MUI v7 + Tailwind CSS. Served by the same Node process or a separate Nginx front-end.
Local Runner
Bun-compiled native binary plus an Electron desktop wrapper (NSIS installer for Windows). Runs Tests-table tests on the user's machine; it still connects to the platform for its session token, auth profiles and result upload.
Self-hosted LLM runtime (Trial and Enterprise)
Any OpenAI-compatible endpoint — Ollama (default localhost:11434), vLLM, LM Studio, or your internally-hosted inference service. Configured per-user or system-wide via AI Settings.
CI/CD plugins
A GitHub Action, Jenkins plugin (Maven) and Azure DevOps task (VSTS), all calling the same /api/v1 contract. The CircleCI orb, Bitbucket pipe and GitLab component are written and public in source but not yet on their registries, so those platforms connect via the same public REST API for now.
MCP server
Model Context Protocol server, available since the September 2026 release (build 2.0.96.231). Connect Claude, Cursor, or another MCP client to Shift-Left API.

Bring your own LLM

Self-hosted LLM inference is included on the Trial and Enterprise plans. Any of the runtimes below — or any OpenAI-compatible endpoint — works as a drop-in. Cloud providers (OpenAI, Anthropic, Azure OpenAI, Gemini and others) are available too, always bring-your-own-key.

Ollama

Default localhost:11434 endpoint. Most common pick for self-hosted local LLM serving.

vLLM

High-throughput inference server. Recommended when serving a centralized LLM to many users.

LM Studio

GUI-based local model server with OpenAI-compatible API.

Any OpenAI-compatible endpoint

Bring your own internally-hosted inference service. Configurable base URL, optional API key, and model namespace prefix (ollama/, local/).

CI/CD integration: two plugins, one REST API

GitHub Actions, Jenkins and Azure DevOps get real, vendor-native integrations — not generic webhooks. Each integrates the test run lifecycle (trigger, poll, JUnit/JSON artifact) and supports quality gates. Every other CI/CD system, including the ones below, connects through the same public REST API.

GitHub Actions
First-party action on the node20 runner, with quality gates and JUnit/JSON artifact output.
Jenkins
Java/Maven plugin with quality gates and JUnit/JSON artifact output.
Azure DevOps
VSTS task (TypeScript) for Azure Pipelines, on the Visual Studio Marketplace.
GitLab CI
Component written and public; not in the CI/CD Catalog yet — call the public REST API from a pipeline job.
CircleCI
Orb written and public; not on the registry yet — call the public REST API from a job step.
Bitbucket Pipelines
Pipe written and public; image not on Docker Hub yet — call the public REST API from a pipeline step.

How an enterprise rollout works

Implementation is scoped per environment. The shape below is what we run for regulated-enterprise deployments. Timelines depend on your IdP, network constraints, and how aggressively your team wants to roll out CI/CD plugins.

01
Architect call (30 min)
A working call with the engineer who will run your deployment. Topology, identity provider, network egress posture, runtime constraints. We leave with your requirements and a draft architecture diagram.
02
Sandbox install
Stand up a non-production deployment matching your target topology. Validate AI provider configuration (cloud or self-hosted LLM), import a representative spec, generate and run tests end-to-end.
03
Security questionnaire + integration review
Your security team reviews the questionnaire response, deployment diagram, and reference architecture in parallel. We address gaps and confirm CI/CD integration points.
04
Production cutover
Production install, IdP integration where applicable, CI/CD plugin rollout, runner provisioning. Post-cutover, a dedicated success engineer (Enterprise) supports onboarding.

For data-flow specifics and identity controls, see the platform security page.

Plan your deployment with the engineer who'll run it

A 30-minute working call. Topology, IdP, network egress, runtime constraints — discussed, not pitched. We leave with your requirements; you leave with a draft architecture.

Book Demo See pricing