eu-central-1 · fra1
Security & your customers’ data
Booth planning means names, roles, contact details and notes on what you discussed. That is other people’s data, held by you. This page states exactly how it is protected and who can reach it — so you can judge for yourself instead of taking our word for it.
Everything below is checked against the running production system.
Where your data is
- Database in Frankfurt
- PostgreSQL in AWS region eu-central-1 — Frankfurt, Germany.
- Application in Frankfurt
- The server code runs in region fra1, also Frankfurt. It used to run in Washington DC while the database was here; that meant personal data was processed in the United States on every request. We moved it. You can check the response header x-vercel-id yourself: it reads fra1::fra1.
- Nothing is processed outside the EU
- No analytics, no advertising trackers, no third-party scripts in the application.
Why one company cannot see another’s data
This is the part that matters most, so here is the mechanism rather than a slogan.
- The database refuses, not the code
- Every table has Row Level Security: PostgreSQL itself attaches a filter to each query, checking that the row belongs to a company you are a member of. It is not an if-statement in our application that we might forget — a mistake in the app cannot hand out rows the database will not release.
- All 22 tables, no exceptions
- Customers, meetings, visitor history, staff, rooms, rosters, travel, presence, preferences — every table carries it. We verify this against production rather than assuming it.
- Two independent locks
- On top of Row Level Security, the rights on each table are narrowed to what that table actually needs. Anonymous visitors hold nothing at all, and a signed-in account holds only the rights its work requires — it cannot empty a table, and it cannot delete from a table the application never deletes from. So a request is stopped twice, by two independent mechanisms. One mistake is not enough to expose anything.
- Separate environments
- Each company works on its own subdomain. Logging in with a valid account on someone else’s subdomain gives you no access — membership is checked per request.
Who can reach what
- An account per person
- No shared logins. Your administrator creates accounts and decides who is an administrator.
- Roles are enforced by the server
- Only administrators can add colleagues or delete a fair. Hiding a menu item is not security, so the server checks the role on every such action — not the browser.
- Deleting is deliberate
- Removing a fair takes every meeting with it, so it requires typing the fair’s name exactly, and the server checks that too.
- Passwords
- Stored only as a bcrypt hash — nobody, including us, can read your password. Changing it requires your current one, so an unattended open session is not enough to take over an account.
Encryption and backups
- Encrypted in transit
- HTTPS only, on every connection, with HTTP redirected.
- Encrypted at rest
- Disk-level encryption on the database and its backups (AES-256, managed by AWS in Frankfurt).
- Daily backups
- Made and retained by Supabase on the Pro plan, in the same European region.
- A copy of your environment every night
- On top of the platform backups above, BoothManager takes its own snapshot of every company each night. Your administrator can download it or put it back without us — no request, no waiting.
- Kept seven days by day, twelve months by month
- The last seven nights are kept, plus the final copy of each month for a year — because a fair deleted in January is often only missed in March.
- Restoring is deliberate, and recorded
- A restore puts rows back into live data, so it asks the administrator to type that copy’s own date and time, and the server checks it. It is then written to a log with their name. Administrators can read that log; no account can edit or erase a line.
Who else touches the data (subprocessors)
You are entitled to know this, so it is stated plainly rather than buried.
- Supabase — database, authentication
- Runs on AWS in Frankfurt. Supabase Inc. is an American company; the data itself does not leave the EU.
- Vercel — hosting the application
- Runs in Frankfurt. Vercel Inc. is an American company; the data itself does not leave the EU.
- Nobody else
- No analytics, no advertising, no CRM, no mailing service. The only extra is the browser push service (Google/Apple/Mozilla) — and only when a colleague turns on notifications.
What is not in place yet
Stated openly, because you should hear it from us and not discover it later.
- No data processing agreement yet
- There is no signed DPA (Auftragsverarbeitungsvertrag) to offer you yet. For German customers this is usually the first requirement, and it is not optional — ask us before you put real customer data in.
- Two-factor authentication is not required
- It can be switched on per account under personal settings, with a code from an authenticator app. We do not require it, so an account that leaves it off is protected by its password alone.
- No password reset by e-mail yet
- There is no mail server configured, so a forgotten password means your administrator issues a new one. You can change it yourself afterwards.
- No external audit
- No ISO 27001, no SOC 2, no pen test. BoothManager is young; we would rather say so than imply otherwise.
- Our nightly copies sit next to your live data
- They live in the same database as the environment they came from. That protects you against a mistake — a deleted fair, a wiped roster — not against the loss of the platform itself. For that there is the database provider’s point-in-time recovery, which we have not taken yet.
Questions your security officer wants answered?
Ask. Anything on this page can be demonstrated in the running system.
← Back to home