Security & trust
Boring where it counts. By design.
This page is not a badge wall. It is a plain description of how the system is actually built: who can see what, who can move money, and what gets written down when anything changes.
The guarantees
In plain words.
Every workspace is a sealed tenant
Every table is tenant-scoped, and row-level isolation is enforced inside the database itself, not just in application code. A bug in the app cannot read another company's rows, because the database refuses to return them.
The books reconcile to zero
The ledger is double-entry: every transaction posts balanced legs, so the whole book sums to zero or something is wrong. A permanent property test asserts that reconciliation on every change to the system, and a database-level check backs it up.
Every state change leaves an audit row
Immutable, and without exception. Human actions record the person. Automated actions record actor "system" plus the id of the exact rule that authorized them. Nothing in the product changes state silently.
Door codes sit behind a dual gate
A smart-lock code goes out only when payment is verified and ID is verified, and the gate is re-checked at the moment of sending, not when the rule was configured. A failed check holds the code with its reason and puts it in front of a human.
Humans gate the money
Approval gates stand in front of everything that moves funds: verifying a payment proof, issuing a refund, releasing a payout. No automation can move money, and no agent rule that moves money can be written.
24 roles, scoped per property
Access control ships with 24 roles, from owner to cleaner, each grantable per property, so a seat sees only the buildings it works. Custom roles carry a hard ceiling: they can never move money and never release door codes.
The supply chain is pinned and signed
Every base image the product runs on is pinned by digest rather than by a tag that can be moved under us, scanned for known vulnerabilities on the way through, and signed so a deploy can prove the image it is running is the image that was built. A dependency advisory published overnight turns the build red the next morning.
The code is scanned against our own rules
Alongside the usual secret and dependency scanning, the pipeline runs a static-analysis pack written for this codebase specifically: the rules encode our own invariants, like money never being a float and a query never escaping its tenant scope, so the class of mistake that would matter most here fails a build rather than a review.
Production access is read-only, and it is a document
Engineers do not hold a shell on the production database. Debugging goes through a fixed-command mechanism backed by a role that can only SELECT, so a support investigation cannot write, and every invocation is logged by the cloud provider rather than by us.
Backups and transport
Databases are backed up daily. Every connection runs over TLS, in the browser and between our own services. Encrypted in transit, everywhere, always.
Card numbers never touch our servers
Card payment is not available yet, so no card number exists anywhere in Stay N Host. When it ships it will run through a PCI-DSS Level 1 processor holding the card data, leaving us with a PCI-certified processor, and we store only references. Bank-transfer and cash proofs live as evidence documents inside your sealed tenant.
The audit trail
If it happened, it's written down.
Every booking, payment, message, and door code carries a permanent history of who did what and why. When an agent acts, the row names the rule that authorized it, so an automated action is more accountable than a human one, not less. This is the record you hand an owner, an accountant, or an auditor without flinching.
"Trust the automation because you can read its receipts."
FAQ
Security questions, answered
Can another customer ever see my data?
No. Every workspace is a sealed tenant: every table is tenant-scoped and row-level isolation is enforced inside the database itself, not just in application code. Even a bug in the application cannot read across tenants, because the database refuses the query.
Do you store card numbers?
No, and today we never see one either: card payment is not available yet, so there is no card number anywhere in the system. When it ships it will run through a processor that holds the card data, leaving us with references. Bank-transfer and cash proofs are stored as evidence documents inside your own sealed tenant.
Can an AI agent move money or open a door on its own?
Money: never. No automation can move funds, and no agent rule that moves funds can even be written. Door codes: only through a rule your workspace authored, and only after the dual gate passes, payment verified and ID verified, re-checked at the moment of sending. A failed check holds the send with its reason and surfaces it to a human.
Who can release a door code?
Only seats holding that specific capability, and it is deliberately scarce. Custom roles have a hard ceiling: no matter how they are configured, they can never move money and never release door codes.
How do I ask a security question or report an issue?
Email hello@staynhost.com. Reports get a human reply, and confirmed issues get fixed before they get discussed.
Try the whole platform free for 14 days
Full Growth-plan access. No credit card. Your data stays yours.
Start free trial