How the platform is put together
An architectural view of how RapidRoot runs: managed cloud services, isolated environments, and observability. We describe the shape of the system rather than operationally sensitive detail.
System shape
This page is maintained by RapidRoot to answer common security and privacy questions about our platform. It describes practices that are in place today and clearly labels anything that is planned. It is not a certification, an audit result, or independent verification.
Requests arrive over TLS at the edge, are authenticated and authorised by application services, and read or write through a managed data layer. Every tier emits logs and metrics into the observability layer.
Hosting and environments
Managed cloud
We run on managed cloud infrastructure rather than self-administered servers, so patching, hardware and base-layer hardening sit with providers who do it at scale.
Separated environments
Development, staging and production are separate, with separate credentials. A test key cannot act on production data.
Infrastructure as configuration
Environments are defined as configuration so they can be recreated consistently rather than hand-assembled.
Regional hosting
Data residency and region selection depend on the underlying providers. We will confirm the current region in writing during evaluation.
Scalability
Application services are stateless where possible so capacity can be added horizontally. Message and call processing is queued rather than handled inline, so a burst of traffic slows a queue instead of dropping work.
Logging and monitoring
- Structured application logs for request, delivery and error events.
- Metrics on throughput, latency and failure rates from the managed platform.
- Alerting on error-rate and availability signals so failures surface without waiting for a customer report.
- Logs are retained for a diagnostic window and are treated as operational data, not as a conversation archive.
Backups and availability goals
Customer data sits in managed database services with provider-level automated backups and point-in-time recovery capability. Our availability goal is to remove single points of failure over time as the platform grows.
We do not publish an uptime percentage because we do not yet operate a measured, externally verifiable availability commitment. Enterprise customers can discuss availability expectations with us directly.