Deployment overview
Zingle AI runs inside your environment. It connects to two systems you already own - your dbt Git repository and your data warehouse - and adds an AI layer that proposes changes as pull requests you review and merge.
This page explains what Zingle is made of, what it reads and writes, and - just as importantly - what it does not do.
Where it runs
Zingle supports two deployment models:
| Model | Where Zingle runs | Best for |
|---|---|---|
| Customer VPC (primary) | Inside your own cloud account / VPC | Teams that require code, credentials, and data to stay within their boundary. |
| Zingle-managed | Zingle-operated cloud | Teams that want the fastest path to value without running infrastructure. |
In the Customer VPC model, all Zingle components run in your environment and connect to your warehouse and Git over your internal network.
Components
A Zingle deployment is composed of the following services:
| Component | Role |
|---|---|
| Web app | The browser UI analysts and admins interact with. |
| Backend / API | Serves the API, orchestrates agents, runs background jobs (repo sync, validation). |
| Agent runtime | Runs the AI agents that read your project and draft SQL/YAML changes. |
| Metadata store | A database holding metadata: dbt models, columns, lineage, sessions, and configuration. |
| Warehouse connector | Connects to your warehouse to run SQL, introspect schemas, and validate models. |
| Git connector | Connects to your Git provider to read the repo and open pull requests. |
The exact packaging and orchestration for a Customer VPC install is handled together with the Zingle team. See Customer VPC.
What Zingle reads
- dbt project metadata - the repository contents and the parsed dbt manifest (models, columns, tests, semantic layer).
- Warehouse metadata - schemas, tables, columns, and statistics, read through your warehouse's information schema.
- Query results - rows returned by the SQL it runs to preview data, validate models, and answer questions (capped per query).
What Zingle writes
- Pull requests - generated SQL, schema YAML, tests, and documentation are committed to a dedicated branch and opened as a pull request.
- Suggestions - optimization and refactor proposals, cost estimates, and validation reports surfaced in the UI for your review.
Every change to your dbt project lands as a pull request that a human reviews and merges. See the Production safety model.
What Zingle does not do by default
- Does not merge to your default branch. Zingle opens pull requests; it does not merge them or push directly to your default/main branch.
- Does not auto-deploy to production. Deployment of merged changes stays in your existing CI/CD and orchestration.
Zingle runs SQL against your warehouse using credentials and a role that you provision. Validation of large refactors may create and drop temporary, disposable objects (for example, short-lived validation databases and temporary tables) to compare results safely. Zingle does not require, and should not be granted, permissions to modify your production tables. Scope the role to least privilege - see the Production safety model.