Less Chaos · More Coordination
Trips carry real plans, real money, and real personal media. Here is how access to that data is controlled, what is logged, where the data goes, and what we have not done yet.
Access is enforced by the database, not the interface
Every piece of tenant-owned data is scoped to an organization, trip, event, or channel, and access is decided by row-level security policies evaluated inside Postgres. Hiding something in the interface is a user-experience choice; the database is the thing that actually says no. A user cannot reach another group’s data by editing a URL, calling the API directly, subscribing to realtime, guessing a storage path, or invoking a backend function — each of those paths is independently gated.
Backend functions repeat the check rather than trusting the caller. Every sensitive operation re-verifies membership and role server-side from the authenticated session, and never accepts an organization, trip, role, or user id supplied by the client. Chat runs on per-channel membership: a member is added to a trip’s channels only after their membership is verified, and removed when they leave, so the chat identity token grants no access on its own. Uploaded files live in private storage under tenant-scoped paths and are served through signed, expiring URLs.
Roles decide what each person can do
Permissions are evaluated across organization, then trip or event, then channel, then role, then action. The rules behind the role labels are defined in a single permission matrix that is compiled into both the app and the backend, with continuous integration blocking any drift between the two — so the interface and the server cannot disagree about who is allowed to do what.
Professional trips carry a boundary worth calling out: a coordinator can be brought in from outside the travelling group to run the calendar, tasks, places, files, and links without being able to open traveler chat or traveler photos and videos. An assistant or a travel advisor can do the logistics without sitting inside private conversations.
What is logged, and what happens when you leave
Privileged actions are written to an append-only audit log. Update, delete, and truncate are rejected for every role — including the service role and the table owner — and each record is hash-chained to the one before it, so any insertion, reordering, or edit breaks the chain and is detectable. A second log captures runtime security events: authentication, rate-limit hits, and access-token issuance.
Operational and telemetry tables have defined retention windows and are pruned on a schedule; the audit logs deliberately are not, because they are the compliance record. Account deletion is immediate and irreversible — there is no grace period and no deferred job. Your authentication record, uploaded media, and personal rows are destroyed in the same request, while trips you created that still have other members transfer ownership so the group does not lose its plan. You can also export your data on request.
How the service is built and watched
Changes go through continuous integration that runs secret scanning, static analysis, dependency review, and a set of drift checks that fail the build if the database schema, permission rules, or environment configuration fall out of sync with the code. Database migrations are reviewed and idempotent. Errors and performance are monitored in production.
Features ship behind flags that can be turned off in under a minute without a redeploy, so a misbehaving feature can be disabled without waiting for a deploy cycle. The database is backed up daily. Recovery objectives, the restore procedure, and the gaps in our disaster-recovery posture are written down internally rather than assumed.
Where your data goes
ChravelApp runs on Supabase for the database, authentication, storage, and backend functions, and on Vercel for hosting. Chat is provided by GetStream. Maps and places come from Google Maps Platform, and the AI Concierge is built on Google’s Gemini models, which receive trip context scoped to the trip you are asking about. Subscriptions on iOS are processed by Apple and RevenueCat — payment card details never touch our servers. Notifications are delivered by Twilio, Firebase, and our transactional email provider. Errors and product analytics go to Sentry and PostHog.
We keep a current inventory of every third party that receives data and exactly what each one receives, and review it quarterly. Enterprise customers can request that list.
What we have not done yet
ChravelApp is not SOC 2 certified and does not hold ISO 27001. We would rather say that plainly than imply an attestation we have not earned. What exists today is the underlying control set — database-enforced access control, tamper-evident audit logging, automated security checks in the build, a maintained risk register, an incident-response runbook, and a subprocessor inventory — which is the foundation an audit would examine, not a substitute for one.
Single sign-on, automated user provisioning, and an external write-once log archive are not built yet; they are scoped and waiting on the customer commitment that justifies them. If your security team needs a questionnaire completed, a specific control evidenced, or a timeline for certification, ask and you will get a direct answer — including where the answer is “not yet.”