Where your school's data lives and who sees it
Cerium is made by fire-gem, a software house, not a chain of schools: we do not compete with you for students and we do not sell data. Below is what has been verified, and what is not there yet.
How it is built
Every sentence below is backed by a test or a check on a running installation.
Servers in Poland
The application, database and online lesson server run on our own machines in Poland. Files are stored with Hetzner in Germany, and email goes out through a provider with an EU data centre.
Each school separated in the database
Every query names the school explicitly, and the database still lets through only that school's rows (RLS with FORCE). 320 isolation tests guard this and run before every deployment.
Only the owner knows the password
The server generates the password and emails it; the database keeps only an Argon2id hash. The school never sees it, and a lost password is recovered by the person with a link valid for 15 minutes.
A session with no secret in the browser
An HttpOnly cookie with a random token; the database keeps only its hash. A session ends after 30 days or after 14 idle days, and revoked access ends it on the very next request.
A lockout that gives nothing away
After 10 failed attempts the account waits 15 minutes, and the response looks like a wrong password, so it does not tell a stranger whether the account exists.
A database copy every day
A database dump is taken once a day and kept for 14 days, on a separate disk in the same server. There is no off-server copy today; that is the next step.
What is verified, and what is missing
Security is also a list of things not yet done. We would rather show it than have someone find it.
Verified
- School isolation: database tests, including writing to another school and linking to another school's record.
- Revoking access: an open session is refused from the next request.
- Payments: card details stay with Stripe; Cerium keeps identifiers and a label.
- Files: only listed extensions can be uploaded, and downloads always come as attachments.
- Payment webhook: signature checked, a repeated event is never booked twice.
Not there yet
- A penetration test by an outside firm.
- An off-server database copy: the copy sits on a second disk in the same machine.
- An audit log: who read the data leaves no trace.
- Two-factor sign-in.
- Scanning file contents; the extension is what gets checked.
Who sees what
Your role decides what you see. The server enforces the boundary on every request, not a hidden menu button.
| Role | Sees | Changes |
|---|---|---|
| Operator | Limit usage numbers, the list of people with their last activity date, and Support tickets. | Creates the space and sets limits. Does not enter the school's space. |
| Management | The whole school. Only management sees a student's PESEL and ID document. | Everything; a director of studies gets team contracts and rates only when granted. |
| Teacher | Their own groups, lessons and the students they teach. | Attendance, grades and homework on their own lessons. Never team contracts or rates. |
| Pupil, parent | Themselves or their children: journal, payments and materials. Not the group's member list. | Their own account: password, email and language. |
Questions about data
GDPR, where data is stored, who has access and what happens if you leave.
The school. Data the school enters into the system or collects on its public pages belongs to it, and we process it as a processor under the data processing terms in the agreement. An extended data processing agreement is available on request. Details are in the privacy policy and terms.
We do not enter the school's space. The platform operator sees limit usage numbers, the list of people with their last activity date and signed-in devices, tickets sent to Support, and the mail delivery log: recipient address and subject, never the body. At the school's request we prepare a downloadable package of its data (GDPR art. 15 and 20); every such download is recorded in the operator activity log. The operator sees the owner's password once, when creating the space, and the owner then changes it under Account. Nobody, neither the school nor us, knows anyone else's password.
The application, database and online lesson server run on our own servers in Poland. Files from DocHub and E-learning are stored with Hetzner in Germany, email goes out through ZeptoMail from an EU data centre, and traffic to the site and panel passes through Cloudflare's network. Online payments go through the school's Stripe account.
During the agreement the school exports data itself: CSV from the tables, documents and files. After the agreement ends, access is blocked and we keep the data for 90 days so it can be handed over on the school's request. Then it is permanently deleted, and it leaves the backups within the following 14 days.
Only management: the owner and the director of studies. For anyone else with the Students module, the server returns PESEL, ID number and date of birth empty, CSV export included. It is a server-side restriction, not a hidden column on screen.
Connections use HTTPS, and the session cookie is Secure and HttpOnly. Passwords and tokens are stored as hashes, and accounting software keys are encrypted. The database itself is not separately encrypted at rest, and we say so plainly.
Not today. An account is protected by a password of at least 10 characters, a lockout after 10 failed attempts and a session that ends when the password or email changes. Changing your own password requires the current one, and all other sessions end at once.
Documents
The full data processing rules and the terms of the agreement.
Privacy Policy
Who the controller is, which providers receive data and how long we keep it.
OpenTerms of Service
Agreement terms, data processing, termination and handing data over afterwards.
OpenSubprocessors
Which providers we entrust with school data, in which country, and how we announce changes.
OpenSee Cerium from the inside.
14 days on your groups and instalments. No card, no strings.