Security
Security, privacy, and tenant isolation
Renaro is designed for operators handling passenger PII, corporate account data, payment state, driver records, and audit evidence across tenant boundaries.
Tenant isolation is the default posture
Renaro is a multi-tenant SaaS platform. Booking, passenger, driver, payment, account, and audit records must remain scoped to the organization that owns them.
- Authenticated request context includes organization identity and roles before service work executes.
- Tenant-scoped reads and writes use explicit organization boundaries.
- Database access is designed to be RLS-aware as defense in depth.
Passenger privacy belongs in the data layer
Passenger PII cannot rely on UI hiding. The product architecture must preserve access boundaries where records are queried and mutated.
- Passenger records, booking history, and communication context are operator-scoped.
- Sensitive access and writes should produce audit evidence.
- No client code should contain secrets or provider credentials.
Infrastructure boundaries stay explicit
Renaro keeps backend services, static hosting, database, cache, and storage responsibilities documented and separate so deploy work does not blur operational boundaries.
- The landing site is static Astro content for Cloudflare Pages-style hosting.
- API and worker services own operational side effects.
- External provider calls belong in workers and outbox patterns, not open database transactions.
Security-related pages
Platform walkthrough
See how Renaro handles your real operating workflow.
Bring a booking scenario, a dispatch policy, a pricing edge case, or a migration concern. The walkthrough should prove how the platform behaves under actual operator pressure.