Your reservations. Looked after.

Vortex PMS runs on a Hetzner Cloud server in Helsinki, Finland. The application, the database and uploaded files (property photos, guest ID photos) are all on that server. Off-site backup copies are kept separately, as described under Backups.

The server’s firewall accepts only web traffic (HTTPS, and HTTP that redirects to HTTPS) and SSH. SSH accepts keys only; password sign-in to the server is switched off. Operating-system security packages are updated automatically every day; some kernel updates take effect only after a server restart.

In transit: every page and API is served over HTTPS with TLS 1.2 or newer (older TLS versions are refused) and HSTS is switched on. The database is not reachable from the internet; the application talks to it inside the same server.

Stored secrets: keys and tokens you give us for connected services (payment, lock, accounting and messaging accounts) are encrypted with AES-256-GCM before they are saved. Passwords are hashed with bcrypt (cost 12). Sign-in sessions and private links are stored only as SHA-256 hashes. Session cookies are httpOnly, secure and sameSite=lax.

At rest: off-site backup copies are encrypted at rest by the storage provider (AES-256). The server’s own disk is not encrypted by us at the disk level; the database and files on it are protected by the access rules on this page.

Vortex PMS serves many hotels from one system. Every business record carries the account it belongs to, and every database query made for a signed-in user is limited to that account by the data layer itself, not only by the page that asks.

When Vortex PMS staff open a customer’s account to help, they do it through a separate staff area, and each such visit is written to the audit log with the staff member’s name, the account and the time.

Each person on your team signs in with their own account (password, or Google sign-in) and gets one of six preset roles. Roles decide who can see guest details, money and reports, and who can change settings. Cleaners use their own sign-in for the mobile task list; unit owners see only their own units.

Guest ID photos open only for signed-in users of the right account and role. They are deleted automatically after the retention period you set for the property.

Changes to reservations, payments, rates, team members and settings are written to an audit log with who did it, when, and the values before and after. Account owners can read and export their own audit log from the Audit page.

Vortex PMS never stores card numbers. On your booking page the guest types the card into Stripe’s own payment fields, so the number goes to Stripe and never reaches our servers. We keep Stripe’s references to the payment, not the card. Cards that arrive with channel bookings are held in the card vault of our channel-management provider and passed to Stripe as a token.

This is the arrangement PCI DSS calls SAQ A: card data is handled entirely by the payment provider. We do not run a card vault.

The whole database is backed up every 15 minutes. Each copy is uploaded to Cloudflare R2 object storage, away from the server, and checked after upload. We keep the 15-minute copies for up to 24 hours and a set of copies from each night for 14 days. The server also keeps the last 12 hours of copies.

A separate check runs every 30 minutes and emails us if the newest copy is missing, too old or too small, on the server or off it. So at most about 15 minutes of database changes are at risk if the server is lost.

These copies hold the database: reservations, guests, payments, rates, settings and messages. Uploaded files (property photos and guest ID photos) are not yet part of the off-site copy.

We restore from these copies with the standard PostgreSQL tools. We have not yet timed a full restore onto a new server, so we do not publish a recovery-time figure. See the service levels page.