Security
What Playium does to protect the data of venues and their families, and what it does not have yet.
In force since 2026-09-28
On this page
1. Where the data is
Playium's database and files are hosted on Supabase, in the European Union (eu-west-1 region, Ireland).
Server functions (the code that sends emails, receives payments or handles WhatsApp) run on Supabase's network, in the region closest to each request: usually in Europe, but also in the United States. They always read from and write to the EU database. The other providers and where they process data are in the list of sub-processors.
2. Encryption
• All communications with the platform are encrypted (HTTPS/TLS), and browsers are required to always use HTTPS (HSTS). • Supabase encrypts the database and files at rest. • Push notifications travel encrypted to the device.
3. Isolation between venues
Every record carries the venue it belongs to. The database's row-level security policies prevent one venue from reading or modifying another's data, including when the API is accessed directly. Each venue's files are stored in its own folder.
Isolation and permissions are checked by more than 150 automated tests run against a real database, plus tests that review the policies in the code.
4. Access control
• Venue staff: personal accounts with two roles, administrator and employee. The panel session expires after 8 hours on each device. • Families: each account only sees its own family's data. When the venue registers a family at the front desk, the temporary password it receives by email must be changed on first login. • Email codes: one-time verification codes expire and are invalidated after 5 failed attempts; and there is a limit on how many codes can be requested within a few minutes, to curb abuse. • Passwords: stored irreversibly by the authentication provider; Playium never sees them. • Payment gateway keys: the panel shows them masked and they never reach the browser in full. Other keys for external services (for example, each venue's WhatsApp token) are stored on the server and the browser has no access to them. • Synced calendar link: uses a secret code the venue can regenerate.
5. Backups
Supabase makes an automatic backup of the database every day and each backup is kept for seven days. When a venue is deleted, its data also disappears from the backups within that period.
6. Development and changes
• Changes are first tested in a separate test environment, with its own database, before reaching production; only urgent fixes may go straight to production. • The code has thousands of automated tests, including the isolation tests between venues. • Database changes are versioned and applied in a controlled way.
7. Monitoring and incidents
Errors are logged in a monitoring tool (Sentry, hosted in the EU); those sent by the server carry no emails, phone numbers or keys.
If a security breach affects a venue's data, Playium notifies the venue within 48 hours at most, as set out in the data processing agreement.
8. What we do not have yet
We would rather say it plainly:
• No certifications: Playium does not hold ISO 27001 or SOC 2 (Supabase and other providers hold their own). • No two-factor authentication: panel accounts sign in with email and password only. • No external penetration tests to date. • Server logs: technical logs of the server functions may include email addresses; they are stored in Supabase and only Playium's technical staff can access them.
9. How to report a vulnerability
If you find a security flaw, write to hola@limbo.ad with the details to reproduce it. We will reply, investigate it and let you know when it is fixed. Please do not access other people's data beyond what is strictly needed to demonstrate it, and do not make it public before we have fixed it.
The contact is also in security.txt.