Isolation you can point at, not a promise.
Most hotel platforms keep every property in one database and separate them with a column. That works until one query forgets the filter. We took the other approach.
A database per property
Your data lives in its own PostgreSQL database with its own credentials, not in shared tables filtered by a hotel column. A query written wrongly cannot return another property's guests, because there is nothing else in the database to return.
Limits Postgres enforces
Each tenant connects through a role carrying its own connection limit and statement timeout, granted data access only. One property's runaway report cannot starve another's front desk, and the database rejects it rather than our code remembering to.
Deny by default
Every route requires a named permission, and a test asserts that no route escapes the check. Permissions live in code beside the routes they guard, so adding an endpoint without deciding who may call it fails the build.
Audit that only extends
Audit tables are partitioned per tenant with a retention window that ratchets: moving to a longer window keeps more, and moving to a shorter one shortens the future only. Nothing already recorded is removed by a billing change.
The hostname decides the tenant
Which property a request belongs to is derived from the address it arrived on, never from a header a browser can set. Tenant headers are stripped at the edge before the application sees them.
Sign-in you can harden
Password, OAuth, passkeys and authenticator codes, on one global account. Who may open a property's staff panel is decided per address: a property's domain admits its owner and active members, nobody else.
Being straight with you
What we are still working on.
Uploaded documents are not yet scanned or sanitised, and we have not completed a review of how hotel-supplied content is rendered.
Session cookies are shared across property subdomains. That is a deliberate trade for single sign-on, bounded by a strict content security policy rather than eliminated.
If your security team wants detail beyond this page, ask us. We would rather answer the question than have you assume an answer.