Where your data lives
Everything you send us is stored and processed in Denmark. All of it runs at a single site on hardware we operate, not on a public cloud.
| Data | Where it's held |
|---|---|
| Events | ClickHouse, Denmark |
| Events being written | Valkey write buffer, Denmark. Held in memory and on disk until flushed to ClickHouse, normally under a second. |
| Accounts, stream settings, destination credentials | PostgreSQL, Denmark |
| Events held for an offline destination | PostgreSQL, Denmark. Kept for up to 7 days while the destination is unreachable, then dropped from the queue. The stored copy in ClickHouse isn't affected. |
| AI schema detection | A local model (Ollama), Denmark. It receives field names and inferred types, not field values. |
What goes elsewhere
Event data leaves Denmark only when you configure a forwarding destination outside it. A small amount of account data goes to one service provider:
| Provider | Purpose and data |
|---|---|
| Resend | Sends account and notification email. Receives your email address and the content of those messages, which can include stream names, field names and types, and delivery error text. Never event values. |
| Paddle | Will handle payments once paid plans launch. Not in use during the free beta. |
OVHcloud hosts our DNS and Let's Encrypt issues our certificates. Neither receives customer data.
Encryption
| What | How it's protected |
|---|---|
| Site, API, dashboard, WebSocket | TLS 1.2 and 1.3. Older versions are refused. HSTS for one year, including subdomains. |
| MQTT | TLS on port 8883. Port 1883 is also open for constrained devices and is not encrypted: the API key and data travel in the clear. Use 8883 unless you can't. |
| Destination credentials | Bearer tokens, HMAC secrets, API keys, passwords and custom header values are encrypted with AES-256-GCM before storage, with a random IV per value and a key kept outside the database. |
| API keys | 256 random bits, shown once, stored only as a bcrypt hash. |
| Passwords | Stored only as a scrypt hash. |
| Session cookies | Signed, HttpOnly, Secure, SameSite=Lax. Sessions last 30 days. |
| Webhooks we send | Optional HMAC-SHA256 signature so you can verify they came from us. |
| Events at rest | Not encrypted by Conduit. Events are stored compressed but readable by the database. If a field must stay unreadable to us, encrypt it before you send it. |
| Between app and databases | Not TLS. These connections stay on a private container network on one machine and aren't reachable from outside it. |
How tenants are kept apart
All customers share one deployment, so each layer below enforces the boundary on its own. A bug in one shouldn't be enough to expose another customer's data.
Identity comes from your credential
Your tenant is derived from a verified API key or session, never from a URL, header or payload. A
tenant_idfield inside an event is stored as ordinary data.Postgres row-level security
Every table holding tenant data has a policy, and requests run as a restricted database role bound to one tenant per transaction. With no tenant bound, a query sees no rows. That role has no access to login tables at all.
ClickHouse tables and row policies
Each stream has its own table, and a row policy limits every read to the bound tenant. With no tenant bound, the read fails. The application's database user can't reach other databases or external sources such as URLs and files.
Real-time channels
MQTT topics and client IDs are namespaced per tenant, so even a
#subscription only reaches your own topics. WebSocket and dashboard updates are routed per tenant and stream.Sandboxed transforms
Your JavaScript transforms run in a fresh QuickJS WebAssembly sandbox for every event, with 8 MB of memory, a 50 ms limit, and no network or file access. If a transform fails, that event isn't forwarded, so a broken redaction can't send raw data onward. It stays stored and can be replayed.
Controlled outbound requests
Forwarding only connects to public addresses. Targets are checked when saved and again before each connection, and redirects aren't followed, so a destination can't be used to reach our internal network.
Checked continuously
Cross-tenant tests run against a full stack before every deployment, and the application refuses to start if the database isolation above isn't in place.
Accounts and access
| Sign-in | Email and password with required email verification, or a magic link valid for 10 minutes. |
| API keys | Up to 10 active keys per account. Revoking a key takes effect immediately and closes any MQTT or WebSocket connection using it. |
| Rate limits | Applied per client address and per account, with a stricter limit on sign-in endpoints. |
| Browser protections | Content Security Policy, frame blocking and no third-party scripts on the dashboard. |
Your data
It stays yours. You can read everything you've stored through the events API at any time.
Deletion is self-service. Deleting a stream removes its events, destinations and transforms. Deleting your account from Settings also removes your API keys and login. Both happen immediately in the live system, not on a schedule.
Retention. Events are kept until you delete them. There is currently no automatic time-based expiry.
Logs. Request logs record the client IP address, path, status and timing. Sessions store the IP address and browser user agent.
Privacy questions and data processing agreements: privacy@usecondu.it. Our Terms are governed by Danish law.
Not there yet
If any of these is a requirement for you, talk to us before you send production data.
- No certificationsWe don't hold SOC 2 or ISO 27001.
- No independent penetration testOur security reviews so far have been done internally, with automated tooling.
- Single site, no SLAThere's no geographic redundancy, and no uptime or restore guarantee during the beta.
- No encryption of events at rest by ConduitAnd no customer-managed keys.
- No multi-factor sign-in or SSOSign-in is by password or magic link only.
- No audit log, and no restricted API keys in the dashboardKeys are issued with full access to their account.
Report a vulnerability
Email security@usecondu.it with what you found and how to reproduce it. Please test only with accounts and data of your own, and give us a chance to fix the problem before you publish. Our contact details are also in security.txt.