Security, uptime, and what happens if
Last updated 16 September 2026
Most vendor security pages are written to survive a questionnaire. This one is written so that you can decide, before you buy, whether the arrangement is good enough for your practice — including the parts that are not good enough yet.
The one-paragraph version
Marchlight runs on a single server operated by one person in Barnala, Punjab, India, behind Cloudflare. Backups run nightly and a restore is tested automatically every week. There is no redundancy, no failover and no contractual uptime guarantee. A power cut or a broadband outage in Barnala means nobody can book online until it comes back — your phone still rings, and your diary is intact. There is no plan to move to cloud hosting; if that ever changes, clients get at least 30 days' notice in writing.
How it is built
| Booking service | Python/FastAPI with a PostgreSQL database, in Docker |
|---|---|
| Reminders | n8n, self-hosted on the same machine, driven by the booking service |
| Public access | Cloudflare Tunnel — the server has no inbound ports open to the internet and its address is not published |
| Transport | HTTPS everywhere, TLS terminated at Cloudflare and again at the origin |
| Brevo over authenticated SMTP, with SPF, DKIM and DMARC published for marchlight.pro | |
| Website | marchlight.pro is static, on Cloudflare Pages, separate from the booking service |
Access control
- One person has access to the server and database: Sahil Sidhu. There is no support team, no contractor and no offshore helpdesk.
- Your dashboard logins are yours; passwords are stored hashed, and nobody at Marchlight can read them.
- Each business's data is scoped to that business. Booking pages are addressed by a per-business slug, and the management link a customer receives is a long random token that grants access to that appointment alone.
- The reminder workflow authenticates to the booking service with a service key, and inbound webhooks are verified with an HMAC signature, so a third party who learns a URL cannot make the system send mail.
Backups, and how they are checked
- Nightly backup of the database, the workflow definitions and their encryption key. A database backup without that key restores to undecryptable credentials, so both are captured together.
- 14 daily and 8 weekly copies retained, then overwritten.
- A restore is tested every week, automatically — the newest backup is restored into a scratch database and the data checked. A backup nobody has restored from is a guess, not a backup.
- Backup archives contain secrets and are written readable only by the account that created them.
What is not true yet: those copies are on the same machine as the data, so they protect against a bad deploy, a corrupted database or a deletion — not against the machine being destroyed or stolen. An encrypted off-site copy is the next change, and this page will say so plainly when it is done rather than before.
Uptime — the honest position
No guarantee is offered, and no historical uptime figure is published, because there is not yet enough measured history to quote one honestly. What can be said:
- The booking service runs unattended. It does not need anybody awake to take a booking or send a reminder.
- The realistic causes of an outage, in order: a power cut or broadband failure at the premises in Barnala; a fault on the single machine; a Cloudflare incident.
- During an outage, existing appointments are unaffected. Nothing is lost, nothing is double-booked, and the diary is exactly as it was when access returns.
- You are told about an outage that affected your bookings, and what caused it, without having to ask.
What happens if…
…the server is down when a patient tries to book
They see a Cloudflare error page and can still phone you. Nothing in your existing diary is affected.
…the database is damaged
It is restored from the most recent nightly backup, so at most one day of bookings would need re-entering from the confirmation emails, which exist independently in your inbox and your customers'.
…Sahil is ill or unreachable
The system keeps running: bookings, reminders and confirmations do not depend on a person. Changes you have asked for wait. Nothing is deleted, and your exported data stays yours on request.
…you want to leave
Ask for a full CSV and JSON export (sent within 7 days, free), delete one script tag from your website, and email to cancel. No notice period, no exit fee. See the terms.
…Marchlight stops trading
90 days' written notice and a final export, as a contractual term rather than a promise.
What Marchlight deliberately does not hold
- No card or payment data. Deposits and payments are not taken, so no card details ever enter the system.
- No clinical records. It is a diary. The free-text note is not a patient record and the widget tells customers not to use it as one.
- No tracking in the booking widget, and only cookieless, aggregate visit counts (Cloudflare Web Analytics) on marchlight.pro, so there is no behavioural profile to lose.
- No IP addresses stored against bookings.
Certifications
Marchlight holds no ISO 27001, no SOC 2 and no Cyber Essentials certification. If your procurement process requires one of those, it is a genuine reason not to buy today, and saying so now is more useful to you than discovering it after a pilot.
What is planned, in order
- Encrypted off-site backup copies.
- A second, separate disk for local backup copies, so one failed drive cannot take the only copy with it.
- Self-hosted fonts on marchlight.pro, removing Google from the website's sub-processor list.
This list is kept in the order it will actually be done, and this page is updated when an item ships, not when it is started.
Reporting a vulnerability
Email hello@marchlight.pro with enough detail to reproduce it. You will get an acknowledgement within one business day and an honest account of what is being done. Nobody will be threatened with legal action for a good-faith report. Please do not run automated scans against the booking service — it is one small machine and a scan is indistinguishable from an attack.