Security and reliability
Where your data lives and what happens when something breaks.
A plain statement for an operator deciding whether to trust us with a season. Everything in the first list is true of the platform as it runs today. Everything in the second list is missing, and that list is deliberately as prominent as the first.
What is built
Where it runs
Xrise is one Next.js application on Vercel in front of one Postgres database on Supabase, in ca-central-1. Operators share that deployment and that database, and every tenant-scoped table carries an operator_id. Separation is enforced by row-level security in the database rather than by physical isolation. If you require a single-tenant database, say so before signing — it is not what you get today.
Money
Payments go through Stripe. On the direct model the guest's card is charged into your own Stripe account and the money never passes through Xrise. On the held model Xrise charges the guest and holds the funds in its own Stripe balance until you take a payout, no sooner than two days later, for the full amount minus the booking fee. Which model applies to you is written into your agreement, not inferred.
Access to data
Row-level security is enabled on every table, so the database enforces who can read what rather than trusting the application to remember. Uploaded photos sit in a private storage bucket and are served through short-lived signed links, never a public URL. Account roles today are customer, operator admin and superadmin.
Secrets
Keys are held in Vercel's environment store and injected at deploy time; none are committed to the repository.
Releases
Every change ships as a numbered version, and each changelog entry records the database migration level it requires — which is what decides whether a given version can be rolled back to. Migrations are plain SQL files applied in order and kept in the repository, so the schema behind any version is auditable after the fact.
Scheduled work
Four scheduled jobs run on Vercel cron: expiring unpaid reservation holds every five minutes, syncing external calendars every fifteen, sending boat club reminders hourly, and the self-check described below every five minutes.
Knowing whether it is up
The platform checks itself every five minutes — not that the web server answered, which stays green through the outage that matters, but that the database answered — and writes the result down. The uptime figure on the status page is read from those records, and it counts a check that should have happened and did not as time down rather than skipping it. That is the opposite of the usual arrangement, in which an outage writes nothing and the missing rows quietly round up to a hundred percent. It cannot see an outage that takes the platform and the database together; only a monitor somewhere else can, and we do not have one.
Knowing a scheduled job stopped
Each scheduled job records that it ran, whether it worked and how long it took, and the list of jobs that are supposed to exist lives in the code next to the schedule, checked against it by a test. A job that silently stops firing used to be invisible until a customer noticed something had not happened; now its absence is what is reported.
Who changed what
Changes to prices, inventory, tenancies, allocations, site maps, payouts and API keys are recorded with the person who made them, and you can read your own under Activity in the portal. Two limits worth knowing. The coverage is what has been wired up, one write at a time — it is not a blanket guarantee that every possible change is captured. And it is append-only as far as this software is concerned: the permission to edit or delete an entry is taken away from the application, so no part of it and no bug in it can rewrite history. Whoever holds the production database password still can. That is one person.
Waivers
In the boat club module a signed waiver stores the version and a snapshot of the text the member agreed to, so a later edit to the waiver cannot change what was signed. This is built for the club and not yet for charters or rentals.
What is not built
If a competitor’s security page has no section like this, it is not because they have nothing to put in it.
- No SOC 2, ISO 27001, PCI DSS or any other audit or certification. None has been started. Card data is handled by Stripe and never touches our servers, which narrows the question but does not answer it.
- No penetration test and no third-party security review.
- Nothing OUTSIDE this deployment watches it. The platform checks itself every five minutes and counts its own silence against itself, which catches a database that stops answering — but an outage that takes the whole deployment down takes the checker with it, and nobody is paged either way. There is no uptime commitment in any agreement and no on-call.
- No error tracking service. Failures are read out of Vercel's logs by hand.
- No self-service data export. Your records are yours and we will send you a full dump on request, by hand, but it is a support request and not a button.
- The audit log covers what has been wired to it, which is not everything. Prices, inventory, tenancies, allocations, maps, payouts and API keys are recorded; a change made through a path that has not been connected yet is not. Treat it as a good record rather than a complete one.
- Only two places are rate limited — the concierge and the public rental booking page — not every public form. Both use an in-process counter, so on serverless the real limit is multiplied by the number of running instances. It raises the cost of casual abuse and is not a security control.
- No formal backup or restore drill. Supabase takes automated backups on its own schedule; we have never performed a restore, so the recovery time is unproven.
- One person writes and deploys all of it. There is no second reviewer, no on-call rotation, and no separation of duties.
Why the second list exists
An earlier version of this page claimed a number of these things were already in place. They were not. Rather than quietly editing the sentences, the claims were removed and the corrections are recorded in the changelog and in the source of this page. If your insurer or your accountant needs something specific, ask and we will tell you whether we have it — and if we do not, we will say so.
Questions go to hello@xriseexperiences.com. Whether the platform is answering right now, and the uptime we have measured, are on the status page.