Trust
What runs Bridgekit, where, and on whose terms.
Trust pages on most SaaS sites are vague badges. This one is a checklist of every component you depend on by depending on us, with the legal entity that operates each one.
Status
Bridgekit is currently in active development. Nothing on this page describes a live, customer-serving production. We're publishing it now so the architecture is open from day one, and so the gap between 'in development' and 'in production' is something you can read directly rather than guess at.
Legal entity
- Bridgekit is a product brand of Greenmango.
- Customer contracts, data-processing agreements (DPAs) and invoices will be with Greenmango. Bridgekit is not a separate legal entity.
Production stack (planned)
These are the components Bridgekit will run on at production launch. Nothing here is a vague 'AWS or compatible' — the choice is committed and the jurisdiction is named.
| Component | Provider | Jurisdiction |
|---|---|---|
| Application servers | Hetzner Cloud (Falkenstein primary, Nürnberg secondary) | Germany |
| Database | PostgreSQL self-hosted on Hetzner | Germany |
| Background jobs | Hangfire on Postgres | Germany (same database) |
| Identity (auth) | Keycloak (open source) self-hosted on Hetzner | Germany |
| Off-site backups | Scaleway Object Storage | France |
| Transactional email | Mailjet | France |
| CDN / edge | BunnyCDN | Slovenia |
| DNS | deSEC (non-profit) and / or Hetzner DNS | Germany |
Source-of-truth: docs/adr/ADR-0002 in the Bridgekit repository. We update this page when the ADR changes.
Pragmatic exceptions
We name the places where we don't reach the EU-sovereign bar, why we accept them, and how we mitigate.
- GitHub for code hosting: Source code lives on GitHub during the bootstrap phase. Customer data never reaches GitHub. We plan to mirror to a self-hosted Git on Hetzner; existing GitHub remains the public face for transparency. Mitigation: nothing in customer-data scope crosses this boundary.
- NuGet, npm, Docker Hub: Build-time dependency registries are US-located. We plan a self-hosted package proxy (Verdaccio / Nexus) for production builds. Mitigation: customer data never traverses these registries; they only carry library bytes.
Architectural properties we commit to
- Multi-tenant data isolation at three layers: EF Core query filters, a save-changes interceptor that refuses cross-tenant writes, and integration tests against a real Postgres that prove the isolation. Today: covered by an automated test suite. Production-verified once we deploy.
- Database-backed authorisation. A valid JWT alone is never enough; every authorised request is checked against an active membership row in our database before proceeding.
- Audit events on every state change in the workflow engine. Tenant-scoped, queryable, designed to be the answer to 'what happened, when, on whose behalf?'
- Crash-resilient engine: state is persisted after every step, so a worker that dies mid-run resumes from the last checkpoint without re-running completed work or losing what was in-flight.
Each of these has an Architecture Decision Record (docs/adr/ADR-0003 multi-tenancy, ADR-0005 flow engine, ADR-0006 identity) backed by tests in the public repository.
What we don't have yet
- A formal SOC 2, ISO 27001, or equivalent third-party certification. We design with the controls these certifications expect, but we haven't been audited.
- A signed Data Processing Agreement template ready to circulate. We'll publish one when we hit production launch; it'll be reviewed by counsel.
- Live production deployment. The engine works in tests; it isn't running for customers yet.
We list these because the worst version of this page would be one that lets you assume things that aren't true. If any of these are blockers for your procurement, please tell us — that signal helps us prioritise.
Reach us
If you want to dig into any of this — DPA review, custom procurement questions, a particular regulatory framework — write to bryan@greenmango.eu. Direct line, not a form.