Security, backups and availability

Reviewed on October 16, 2026

This page describes what the platform does today. It is not a service level agreement: it explains how the service is set up, it does not promise outcomes. When any of this changes, we will update this page.

1. Availability

  • We do not offer a service level agreement (SLA) with a guaranteed availability percentage, nor compensation for outages. Nor do we contractually commit to an incident response time.
  • The web application and the API run on three instances that share the traffic.
  • An automated process checks several services the platform depends on every 5 minutes and, if it detects an outage, opens an incident on our public status page.
  • Errors from the apps and the server are logged centrally so they can be reviewed and fixed.

See the status page

2. Database backups

  • Continuous backup: database changes are archived continuously —in normal operation, at most one minute behind— to external storage, outside the main server, encrypted with AES-256. A full backup is taken every week and a differential one every day.
  • With that backup the database can be returned to the state it had at a specific minute, within at least the last 7 days.
  • Independent daily copy: every night, a server in another cloud pulls a copy of the database and stores it with another provider, in storage configured so that it cannot be modified or deleted for 30 days.
  • Restoring is tested: in October 2026 we restored the full database on a new server from these backups, with the same data as production, and in another drill we returned it to a specific minute.
  • We do not commit to a restore time.

3. Security

  • Passwords are stored with bcrypt, an algorithm that does not allow them to be recovered: nobody, including us, can read a user's password.
  • Traffic between the apps, the dashboard and our servers is encrypted over HTTPS.
  • We do not store card numbers or security codes: charges are made by the payment processor, and its payment notifications are verified by signature before any balance or status changes.
  • Each company operates isolated by its identifier: one company cannot see another's drivers, trips, customers or finances.
  • The Apple notification keys that customers entrust to us are stored encrypted with AES-256-GCM.
  • Our internal diagnostic tools query the database with read-only access.

4. Your data: how to take it with you

  • From the dashboard you can download your drivers, passengers and businesses in Excel; your trips in CSV, with the filters you have applied; your reports in Excel, and wallet transactions in CSV.
  • The public API (/api/v1/reports/export) returns the trips or orders of a date range in CSV, with an OAuth authorization from your account.
  • What happens to your app and its code if CabGo stops providing the service is set out in the Terms of Service (§5 and §9).

See the Terms of Service

5. What we do not cover today

  • There is no SLA with an availability percentage and no compensation for outages.
  • The database runs on a single instance, with no standby replica on another server. If the main server fails completely, the service is interrupted until it is restored from the backups.
  • We do not hold our own certifications (SOC 2, ISO 27001 or PCI-DSS). Card data is handled by the payment processor, not by us.
  • The dashboard has no second authentication factor (MFA): you sign in with a password or a Google account.
  • We have not carried out a formal external penetration test.
  • No provider can guarantee that a system is invulnerable, and we do not promise it.