Bunyawi

Security and data protection

Last updated 19 September 2026 · Bunyawi, Cairo, Egypt · Security reports and questions: [email protected]

This page describes what is actually in place today. It is written as a list of facts, not promises, and it is updated when the facts change. The privacy policy says what we collect and why; the data processing terms say what we owe a merchant as their processor.

1. Where it runs

  • The platform runs on a single DigitalOcean droplet in Frankfurt, Germany (EU region fra1), with Cloudflare in front of it.
  • TLS everywhere: Cloudflare terminates TLS at the edge, and the connection from Cloudflare to the origin server is itself TLS with a Let's Encrypt certificate. There is no plain-HTTP path to the API.
  • The PostgreSQL database listens on localhost only. It is not reachable from the internet, and there is no public database port.
  • Each merchant's data is isolated inside the database with PostgreSQL row-level security keyed by tenant id. A query made in one merchant's context cannot return another merchant's rows, even if the application code had a bug.

2. What we process

The platform processes only what a merchant's app needs to work:

  • Orders: order number, items, totals, status.
  • Customer name, email, phone and shipping address — only when Shopify has granted the merchant's installation that access (Shopify's protected customer data approval).
  • Push notification tokens, so order updates can be delivered to the device.
  • Sign-in identity through Firebase Auth (a user id and the email or provider it is linked to).

We never receive or store card data. Payment happens in Shopify's checkout or through the merchant's own payment gateway; card numbers do not pass through Bunyawi.

3. How long we keep it

  • Orders: kept for as long as the merchant has the app installed — they are the merchant's tax and commercial records.
  • A customer's name, email and phone: erased from their orders when Shopify sends customers/redact, or when the customer deletes their account in the app. The order itself remains, without the person.
  • Raw webhook payloads: 90 days.
  • Abandoned app carts: 30 days.
  • Checkout requests: 90 days.
  • Audit and access logs: 365 days.
  • Encrypted database backups: 14 days.
  • An uninstalled store: everything is deleted 30 days after uninstall — or immediately when Shopify sends shop/redact.

4. Encryption

  • In transit: TLS on every hop, as described above.
  • At rest: the PostgreSQL data directory lives on a DigitalOcean Block Storage volume, which is encrypted at rest at the storage layer (LUKS). The volume is attached only to this one server.
  • Backups: the database is backed up nightly. Each backup is encrypted with AES-256 (GnuPG) before it is written to disk, and the key is held only by the operator. A backup that cannot be decrypted and restored is discarded.
  • Secrets — database credentials, API keys, signing keys — live in a root-only environment file on the server. They are never committed to the code repository.

5. Who has access

  • Bunyawi is run by one operator. There is no support team with production access.
  • Server access is by SSH key only. Password login is disabled.
  • Merchants reach their dashboard only through Shopify's own staff login and session tokens. We never see or store a merchant's password.
  • Customers sign in through Firebase Auth: Google, Apple, or email with verification. We do not store customer passwords.
  • The operator's own accounts — GitHub, Google, DigitalOcean, Cloudflare, Shopify Partners — use unique passwords of 16 characters or more from a password manager, plus two-factor authentication.
  • Every change made in the dashboard, and every read of customer personal data, is written to a per-merchant audit log that the merchant can view.

6. Test data and production

  • Test orders are in-memory fixtures. They are never written to the database, and they are shown only to allow-listed test accounts.
  • Development runs against a local file store on the developer's machine, never against the production database.

7. If something goes wrong

  1. Contain — rotate the affected secret and block the source at Cloudflare.
  2. Assess — establish the scope from the server logs and the audit log: which merchants, which data, which period.
  3. Notify — email every affected merchant within 72 hours with what happened and what data was involved, and notify Shopify where its terms require it.
  4. Fix — correct the root cause and redeploy.
  5. Learn — write a post-mortem and make the change that stops it recurring.

To report a vulnerability or a suspected incident, write to [email protected]. Reports are read by the operator personally.

8. Data subject requests

  • A customer can delete their account from inside the app. Their name, email and phone are removed from their orders at that moment.
  • A merchant who receives a request from a customer forwards it to [email protected].
  • Shopify's customers/data_request, customers/redact and shop/redact webhooks are implemented and honoured automatically.

9. Sub-processors

The third parties that necessarily handle some of this data, and what for:

  • DigitalOcean — hosting (Frankfurt).
  • Cloudflare — DNS, CDN and TLS termination.
  • Google Firebase — customer authentication and Android push delivery.
  • Apple Push Notification service — iOS push delivery.
  • Google Play services — Android app distribution and device services.
  • Shopify — the source of the store's products, orders and customers.
  • GitHub — code hosting and the build pipeline.
  • Codemagic — iOS builds; sees the merchant's App Store Connect key for the duration of a build.

If this list changes, merchants are emailed before the change takes effect.