01Reliability & security

Engineered to keep running
— and to keep your data yours.

This is the page for your security and platform teams. How the suite holds up under failure, how we ship updates without dropping a request, how data is protected in transit and kept in Europe, and where it all runs. The mechanisms behind the claims — written for people who want the detail.

Enterprise deployment

02what keeps it standing

Robustness isn’t one feature. It’s built into every layer.

“How likely is it to break on me?” is the question this page exists to answer. Below is the machinery — redundancy, failover, edge protection and a delivery pipeline — that together keep the suite serving even when individual parts don’t.

// every mechanism here is in production, not on a roadmap.

WAF & DDoS at the edge

All ingress passes a web application firewall with volumetric DDoS protection and real-time attack detection before it reaches an app.

balancer
×2 live

Elastic load balancing

Dynamic load balancing spreads traffic across instances and scales capacity up or down on a live deployment — no maintenance window, no user disruption.

TLS · auto-rotate 60d

Encrypted in transit

HTTPS from device to server — TLS certificates rotated automatically every 60 days.

Site A
Site B
primary

Two offsite backup sites

Beyond live redundancy, data is replicated to two geographically separate EU backup sites. A lost primary is a restore, not a disaster.

resilience

Triple-redundant hot-failover

Every workload runs in triplicate across independent nodes. If one drops, traffic is already on the other two — no cold start, no manual cutover.

resilience

Graceful degradation

Under partial failure or a load spike, non-critical paths shed first while the core keeps serving. The system is built to bend before it breaks.

security

Isolated environments

Development, testing and production are fully isolated, with tight access control enforced internally too. Least privilege is the default, not a setting.

delivery

CI/CD with sealed secrets

Every change ships through an automated pipeline with encrypted secrets management — no credentials in code, no hand-edited production.

03zero-downtime delivery

Updates land without anyone noticing.

We deploy continuously. Each new build is brought up alongside the running one and has to pass its own health checks before it takes a single request. Only then does routing switch atomically — the old version drains while the new one serves, so updates don’t interrupt anyone mid-task.

// If a health check fails, traffic never moves and the release is held — the running version simply keeps serving.

  1. 1

    Build & stage

    A new version boots beside the live one, fully isolated.

  2. 2

    Self health-checks

    It must pass its own checks before receiving any traffic.

  3. 3

    Atomic route switch

    Routing flips in a single step — no half-served requests.

  4. 4

    Drain & retire

    The old version finishes in-flight work, then steps down.

04systems architecture

Fewer moving parts, fewer ways to fall over.

Most platforms scatter a single request across a dozen network services. Ours doesn’t. Our Vertical Slice Micro-Monolith keeps each capability’s logic together and cuts the network hops between them — lower latency, a smaller failure surface, and far less that can go wrong in the gaps between services.

Vertical slices, not service sprawl

Each feature owns its full slice end to end, so there’s no fragile web of cross-service calls to keep alive.

Minimised network hops

Fewer hops between components means lower latency and fewer independent things that can fail mid-request.

Runs anywhere, fails over everywhere

The same architecture deploys to our European cloud, your own on-prem hardware, or a hybrid — with automatic failover and recovery built in.

// on-prem, EU cloud, or hybrid — same architecture, your choice of ground.

// request path comparison

Typical microservice mesh5 network hops
Vertical Slice Micro-Monolith2 network hops

05law & standards

GDPR compliant.
Designed under EU law.

We are GDPR compliant. Every deployment is designed under EU law and the strictest European standards. Technical details, the sub-processor register and on-prem hardware requirements are something we walk through on a call.

GDPR

General Data Protection Regulation

GDPR compliant. Purpose-binding, data minimisation and right-to-erasure designed into the architecture.

EU law

European legal standards

Designed under EU law and the strictest European data-protection and AI standards. Human oversight and transparency are built in.

06data residency & sub-processors

Your data has an address — and it’s in Europe.

On self-hosted deployments your data never leaves your hardware. On our European cloud it stays on EU-resident infrastructure under European jurisdiction. US frontier model APIs are optional — only for inference, and only if you choose to enable them.

  • Customer data — documents, files, backups, audit logs — stored and processed in the EU. Always.

  • Open-weight models on EU infrastructure by default; no US provider required.

  • Optional US frontier models (Claude, GPT, Gemini) — opt-in only, never training on your data!

  • A documented exit plan: Data portability by design. We help you export and retain all your data when you stop using our software.

// Full, current sub-processor register available on request.

07responsible disclosure

Found something? Tell us.

We welcome reports from security researchers and treat them as a priority. Report a suspected vulnerability and we’ll acknowledge it quickly and keep you updated through to resolution — no legal threats for good-faith research.

due diligence

Send us your security questionnaire.
We answer in plain language.

Whether you need the sub-processor register, technical details, or on-prem hardware requirements — reach out and join a call with the people who actually design, build and run these systems. No NDA needed to start.