How RestaPro works under the hood
Architecture checked on 9 October 2026. Provider configuration can change; availability and recovery commitments require their own operational evidence.
Stack in one image
Internet (HTTPS)
↓
Vercel (domains, TLS and frontend distribution)
↓
React 19 + TypeScript (application, Admin and Pro) / Docusaurus (Wiki)
↓
Supabase (PostgreSQL + Edge Functions + Auth + Storage)
↓
Integrations: Resend, Stripe and Google Gemini
The frontend is published on Vercel from this monorepo. Business logic runs in Deno Edge Functions and PostgreSQL. The former server is no longer part of hosting or the current recovery procedure.
Frontend
React 19, TypeScript and Vite build the application, Admin and Pro. The Wiki uses Docusaurus. Tailwind CSS, TanStack React Query, React Hook Form and Zod cover styling, data and forms. Vercel serves the builds and the configured routes for each domain.
Backend: Supabase
- Managed PostgreSQL in Frankfurt (
eu-central-1). - 96 active Edge Functions in the 9 October review; this is a snapshot of that review.
- Auth with JWT sessions, email and Google OAuth; TOTP available in the project configuration.
- Storage for logos, covers and menu images.
- Realtime for application events and pg_cron for scheduled jobs.
Multi-tenant security: Row Level Security (RLS)
RLS policies and permission checks in Edge Functions determine which data each member can read or change. Isolation needs testing by role, restaurant and operation; enabling RLS alone does not prove a policy is correct. Service credentials require additional controls because they can bypass RLS.
Encryption
The frontend uses HTTPS managed by Vercel and Supabase connections require TLS. Integration secrets are configured in the providers and Edge Function environment; their contents are not published. Enabling TOTP in configuration does not prove all accounts have enrolled or all routes require a second factor.
AI: Gemini + Pinche
Pinche uses Google Gemini and backend-authorized tools to read or change data. The model and available tools depend on deployed configuration. Data-processing terms must be checked for the actual service and contract; they cannot be inferred from another Google product's terms.
Notifications
Realtime (instant)
Supabase Realtime distributes events to subscribed sessions. Availability depends on the provider, connection and user permissions.
Transactional email (Resend)
Resend handles sending and receiving email. The application records delivery states and webhook events. Signatures, retries and idempotency require specific tests: a processed-event record alone does not guarantee an operation completes exactly once.
Payments: Stripe
Stripe manages subscriptions, Checkout and the customer portal. The application keeps customer and subscription references without receiving full card details. Webhooks require signature validation, failure recovery and concurrency tests.
Hosting
The review found the Vercel project in a team on Pro and the Supabase organization on Free. The audited PostgreSQL database is in Frankfurt. This does not establish geographic replication, a single region for all providers or a recovery SLA.
GDPR
Database location is one part of processing. Integrations, contracts, permissions, retention and deletion procedures also require review. More in Privacy and GDPR.
Backup and recovery
The audit verified manual database copies from 8 October: public, Auth and Storage metadata. Their checksums and catalogs were valid, but those copies did not include Storage files. No accessible managed backups or PITR were found in the audited project.
On 9 October, a new encrypted local copy of public, Auth and Storage metadata was completed together with all 85 Storage files. An isolated PostgreSQL 17 trial restored tables and permissions and checked the Storage files. External upload and full Supabase recovery, including login and file access through its API, still await verification.
A flow has been prepared to export the database and all Storage files, validate checksums, encrypt for a GPG public key and optionally verify an external copy in Backblaze B2. The nightly job remains inactive until credentials are configured, the private key is held safely and an isolated recovery is validated. The selected destination is bucket restapro; the intended key custody is the owner's password manager.
Neither 30-day retention nor a recovery time below four hours has been demonstrated. Archive integrity, an external copy and a working restore are separate checks. Joint database and Storage recovery needs a quiet period or reconciliation, because the export is not a transaction across both services.
Monitoring
The code integrates Sentry and Edge Function and database logs. Their presence does not establish complete coverage, retention or delivery of alerts: those conditions need checking in the services and an assigned owner.
CI/CD
The GitHub Actions workflow checks lint, types, tests and the checkout build, and checks all Edge Functions with Deno 2.8.0 as CI tooling and frozen dependencies. That version does not identify the hosted Supabase runtime. It verifies candidate HTTP delivery and rendering with synthetic data and uses isolated PostgreSQL for SQL regressions. Actual Vercel configuration and full backend flows require additional checks. A workflow's existence does not mean its results block publication. Delivery needs verification of the SHA, required checks, deployment and subsequent smoke check. Snapshots on the former server are not Vercel's rollback mechanism.
Continuous deployment
The 9 October 2026 check confirmed automatic domain assignment disabled: publication uses manual promotion after verifying CI for the SHA. Automated Deployment Checks still need selection and a failure trial; recheck the setting after each promotion.
Vercel integrates the repository and creates deployments for commits. The SHA links code, CI and production; a frontend rollback uses a previous Vercel deployment and does not undo a database migration. More in Versioning and publishing.