Architecture
One connector, run it wherever you want
A connector is a container: configuration from the environment, credentials from a secret manager, data written over the network. Nothing about it cares whose infrastructure it is on — which is what makes where it runs a decision you can change later rather than an architecture you are stuck with.
Where it runs
Four substrates, one artifact
The same container in every case. Pick the row that matches what your team already runs — each step up buys observability and resilience at the cost of something to operate.
Who operates it
A separate question from where it runs
The substrate above is what the connector runs on. This is who operates it and who holds the credentials — the two are chosen independently.
| Hosted | Integrated | Self-hosted | |
|---|---|---|---|
| Runs on | Our cloud | Our cloud | Your infrastructure |
| Data lands in | Your warehouse | Your warehouse | Your warehouse |
| Your data on our infrastructure | In transit | In transit | Never |
| Source credentials held by | Us | You | You |
| We are a data processor | Yes | Yes | No |
| Moving to another level | Redeploy | Redeploy | Redeploy |
What is inside it
Two-thirds of every connector is not about your API
Health, metrics, logs, configuration, retries, inbound events. Written once and shared, so the work we bill for is the part that is specific to your source.
| Health | A readiness endpoint your load balancer or scheduler can check |
|---|---|
| Metrics | One scrape target per container: run counts, rows, freshness, failures |
| Logs | Structured JSON to stdout, collected by whatever already collects logs |
| Identity | An endpoint that states the version actually running, not the one intended |
| Inbound events | Webhook delivery is verified and receipted before it is acknowledged |
| Configuration | From the environment. Credentials by reference, never a value in a file |
| Supervision | A connector that exits is restarted; a clean exit is not treated as a fault |
A container runs one connector, built against our SDK. The connector does the extracting, transforming and loading for one source system; the SDK gives every connector the same health checks, metrics and log format, so a fix to health checking is not a fix to twelve connectors. You never have to care about that split unless you want to.
Ownership
What you own, and what we maintain
Everything in the container is yours. The difference is between what you already have and what you keep receiving.
You own the connector
The integration itself: how your API is authenticated and paginated, incremental state, the transformation, the warehouse load. Source in your repository from the first commit, yours permanently and unconditionally. If you leave, a scheduled connector carries on running.
We maintain the SDK
The library your connector is built against — health, metrics, logs, configuration. It is deliberately small, and it is in your repository like everything else. While you are under contract we keep it current. When the contract ends, the version you have is yours, as-is and free to use, for as long as you like. Nothing expires and nothing switches off.
What this is not
There is no platform to buy into
No engine, no builder interface, no control plane, no runtime you must keep paying for to keep your pipeline alive.
Every part of a connector is assembled from components you already run or could hire for: a container, a scheduler, a secret manager, your warehouse. That is a deliberate limit on what we build, and it is the reason the lock-in answer is demonstrable rather than a promise — here is the image, here is the repository, here is the command to run it.
If a vendor connector already covers your API, use it — we will tell you. We build the ones that don't exist, or don't do what you need.
Send the architecture question you actually have
If your platform team needs to know how a connector behaves in your environment specifically, ask. A concrete answer is faster than a diagram.
Ask us