Hosting and architecture
Where ShopAssist runs, how stores are isolated from each other, and how backups and incidents are handled.
Hosting
The application, database and backups run at Hetzner in Falkenstein, Germany. Uptime monitoring runs in Helsinki, Finland, and processes no personal data. The full list of sub-processors is on the sub-processors page.
Components
- Web (
shopassist.coec.dk): marketing, docs and the dashboard. - API (
api.shopassist.coec.dk): the widget, merchant and connector APIs. - Workers: catalog sync, knowledge crawling, handoff delivery, webhooks and emails.
- CDN (
cdn.shopassist.coec.dk): the versioned widget files, immutable and served with Subresource Integrity hashes.
All outbound requests (to your store, feeds, AI providers, helpdesks and webhook endpoints) go through an egress proxy that only allows public HTTPS destinations. Internal addresses and cloud metadata endpoints are blocked, including after redirects and DNS changes.
Tenant isolation
- Every store's data carries its organization and store id.
- The application opens every database session for one tenant, and PostgreSQL row-level security rejects rows of any other tenant, even if a query forgets a filter.
- Ids of another store's resources answer
404, never revealing that they exist. - Isolation tests run in CI on every change.
Logging
Logs contain no message content and no personal data. Client IP addresses are removed from web logs before they are stored, and token-carrying URLs are rewritten to their route pattern.
Backups
Encrypted backups are kept in two locations for 30 days. Restores are tested monthly.
Incidents
We notify affected merchants of a personal-data breach without undue delay and within 48 hours of becoming aware of it, then update them as we learn more. Service status is on the status page.
Last updated on