If a customer does not trust JoinLayer with a database credential, nothing else matters. Security is not a secondary feature for this product. It is the condition for using the product at all.
Our posture is simple: JoinLayer is a managed pipeline service, not a warehouse, not a data broker, and not a place where customer rows become a JoinLayer asset.
The short version
What JoinLayer does not do
Credentials
Connection credentials are production secrets. JoinLayer stores connection configuration in encrypted form and keeps credentials scoped to the workspace and connection that owns them. A runtime component uses those credentials only for the action the workspace requested: connection test, schema discovery, preview, validation, lookup enrichment, snapshot, realtime read, or target write.
Credentials must not appear in URLs, browser history, frontend state, raw backend errors, screenshots, support messages, prompts, application logs, or monitoring events. A useful error says the target write failed because a permission is missing. It does not print the password or connection string.
Customer rows
JoinLayer processes customer rows to execute the pipeline: read from the source, apply mapping and enrichment, validate the target shape, and write to the destination the customer controls. JoinLayer does not store a replicated copy of your source tables as a product feature and does not keep the destination output as its own analytical dataset.
Some operations necessarily hold bounded customer content. Preview returns sample rows to authorized workspace users. Failed-row diagnostics can retain the record payload, key, and message for up to 30 days before that content is scrubbed. Materialized lookup mode keeps selected reference fields in a managed DuckDB cache while an active pipeline needs them. These mechanisms support execution and recovery; they do not turn customer rows into a JoinLayer-owned report, warehouse, or analytical dataset.
Logs and monitoring
Customer row payloads and credentials do not belong in logs or monitoring. JoinLayer telemetry is for operating the service: run status, worker health, throughput, timing, counters, failure stages, and actionable diagnostics. JoinLayer application logs and monitoring exclude credentials and customer row payloads.
This matters because monitoring systems often have broader retention and access patterns than the product database. Keeping customer payloads out of that path reduces blast radius if an observability tool, alert, or log export is mishandled.
Tenant isolation and access
JoinLayer workspaces are tenant boundaries. Connections, pipelines, runs, credentials, usage, diagnostics, worker claims, OAuth grants, agent scopes, and approvals are scoped to the workspace. Workspace roles control who can inspect configuration, run previews, start work, review diagnostics, or manage access.
Support access is scoped to diagnosis, follows the workspace and role model, and leaves an audit trail. Customers do not need to send credentials or customer rows through support email. Security reports go to [email protected] with a subject that starts with Security:, without including secrets or customer records.
Network access
JoinLayer supports SSH tunnel settings for PostgreSQL and MySQL/MariaDB source, target, and lookup connections. The same tunnel configuration is used across connection tests, schema discovery, preview/runtime enrichment, snapshots, realtime readers, backfill chunks, and target writers.
Some pipelines run through customer-approved public endpoints and least-privilege credentials. For PII-heavy, private-network, or regulated deployments, JoinLayer reviews SSH tunnels, bastion access, IP allowlisting, private networking, and deployment model before connecting production systems.
Operational correctness is part of security
A secure pipeline must also avoid false success. JoinLayer's processing order is conservative: read from source, transform and enrich, write to target, durably checkpoint, then confirm source progress. A checkpoint must not advance before the target write succeeds.
This is not just reliability language. It protects customers from a dangerous class of failure where a system marks source progress as complete before the destination actually has the row.
Current scope
| Area | Current posture |
|---|---|
| Operational sources | PostgreSQL and MySQL/MariaDB support snapshots and CDC; Kafka supports JSON or Avro streams; ClickHouse supports finite snapshots. |
| Destinations | JoinLayer writes to PostgreSQL, MySQL/MariaDB, BigQuery, append-only ClickHouse tables, and Kafka topics under connector-specific consistency contracts. |
| Network access | SSH tunnel settings are supported for PostgreSQL and MySQL/MariaDB source, target, and lookup connections. |
| Expansion areas | Snowflake, Redshift, and customer-driven connector coverage remain roadmap expansion areas. |
| Higher-review deployments | PII-heavy, regulated, private-network, enterprise SSO, strict data residency, and customer-managed key requirements go through security and deployment review before production connection. |
JoinLayer asks for sensitive access, so it must keep the boundary clear: encrypted credentials, no customer row payloads in logs or monitoring, customer-owned destinations, tenant-scoped access, and pipeline correctness that does not mark progress before a target write succeeds.