Where your book sits, and who can read it.

Your browser sends the file straight to storage against a link signed for fifteen minutes. It does not pass through our API on the way, so there is no copy of it in a request log, in a temporary directory or in a queue. Six file types are accepted at the door — PDF, Word, PowerPoint, PNG, JPEG and plain text — and the ceiling is 250 MB per file. Anything else is refused rather than stored and sorted out afterwards.

Accepted is not the same as readable, and the difference is ours to carry rather than yours to discover. The reader currently handles PDF and plain text; a Word file, a slide deck or a photograph is stored and then reported back as something it cannot process, and turning it into a PDF is our work. We would rather accept the file you actually have and do that conversion than refuse it at the upload and leave you wondering what format we wanted.

Your book goes into one bucket and stays there. It is versioned, and there is no rule anywhere in the configuration that deletes a live object. That is a product requirement rather than a storage preference: every citation in your course is verified by re-reading the page it came from, so a rule that quietly removed a PDF after a year would break the checking with no error until a student clicked something. Objects move to cheaper, slower storage at 90 days and again at 365, which changes the price and not the availability. A deleted object stays recoverable for 7 days.

Everything derived from your material — page images, the output of reading a scan, thumbnails — goes into a second bucket and is deleted at 180 days, because all of it can be rebuilt from the first. The part of the system that reads your originals cannot write to them.

One PostgreSQL 17 instance. It has no authorised networks at all — not a narrow list, an empty one — accepts encrypted connections only, and is reachable solely through a socket mounted into our own service and gated by cloud identity. There is no bastion host, no VPN, and no password on a laptop that reaches it.

Encryption at rest is the cloud provider’s default for both the database and the buckets. We have added no customer-managed key, and this page is not going to describe a vendor default as though we had built it.

One region, in Iowa, in the United States. The deployment configuration refuses any other value before it runs, so the region cannot drift by accident. If you need your material to stay inside the EU, we cannot do that today: it is a second deployment in a second project, and it is not built. We would rather tell you here than after you have paid us.

No advertising network, no tag manager, no session recorder, no chat widget. There is no third-party script on this website and none on the screen your students look at — not as a policy we intend to adopt, but as a fact about the pages as they are written today.

Backups cover the whole database, because every provider is in one database. Restoring your data alone means restoring a copy of the entire instance to a scratch machine at a chosen moment and copying your rows back in dependency order. That is a person with a runbook and it takes hours rather than minutes. We would much rather you knew that before an incident than during one.

We chose a shared database knowingly. A separate database for each provider would have made this one command, and it would have turned signing up into a provisioning project with its own failure states. The trade is written down, with the alternatives that lost, in the architecture decision record that fixes the tenancy model.

An account identifier at the identity service, an email address if the provider released one, a display name, which course they are enrolled in, which lessons they have opened and how they answered the questions. No home address, no telephone number, no date of birth, no payment detail. The product holds no card details and contains no payment code at all — there is nothing in it that could take a payment.

The contact form on this site stores a name, an email address, an optional school name and the message, plus a keyed hash of the sending address rather than the address itself, because the only question ever asked of it is whether the same person pressed the button twice in ten minutes. The database’s own query monitoring is configured not to record client addresses.

23 kinds of event are recorded: every change to who can do what, and every change to what your students can see. The application role holds no privilege to update or delete those rows, so the trail is append-only as a matter of database permission rather than of good intentions. Removing a member does not erase the record of what they did; the actor is simply unlinked from it.

An audit row never contains an email address, only its domain, and that follows from the same decision: a row that can never be deleted must not hold anything a person could later ask us to erase. There is no screen showing the trail yet. Today it is read with a query, and saying so is cheaper than implying a console that does not exist.

There is no platform-level administrator account in the product. Nobody can sign in as a support engineer and open your course, and adding that ability would be a change to the most security-sensitive path in the codebase rather than a setting somebody flips. That is a real property and it is worth having.

What it does not mean is that nobody can reach your data. Whoever operates the database can, exactly as at every other supplier you have ever bought from, and a page that implies otherwise is lying to you. What we can say is that it is a small number of people, that it takes a deliberate act rather than a click, and that we will tell you if it ever happens for a reason other than fixing your own problem.