How Premises keeps your data: one database per business, files sealed at rest

In transit

Your workspace is served over HTTPS with a certificate that renews itself. A request on plain HTTP is redirected before it is read. Cookies that carry your session are marked so that scripts cannot read them and other sites cannot send them.

At the gate

The address — yourbusiness.premises.ph — is the first thing checked. It maps to exactly one workspace, and the platform opens that workspace's database and only that one. Your session is then checked, then your role, then the limits that stop a script from hammering a page. One database per customer explains why there is no shared table that a bug could forget to filter.

At rest

Records are in a database file per workspace. Files you upload are encrypted before they touch disk, with a key that belongs to your workspace; the bytes on disk are useless without it, including to another workspace on the same server. Nothing you upload is ever served from a public folder — every download goes through the gate and a permission check.

In the log

Every create, change, delete, sign-in, "View as" and export is written to an audit log inside your database. The app can read it and cannot edit it. The audit log shows how to read it.

In the copies

A snapshot every night, a copy to a second location every week, each of them a whole workspace. Backups covers how long they are kept and how a restore works.

On the other side of the door

Tenants use the same address as staff, but through a different door: a separate session type that can reach only the eight portal pages. A tenant who types a staff URL gets the sign-in page, not a glimpse. Staff sessions cannot be reused on the portal side either.