Bring your own backend
Tuqo serves the static front end; the database, auth and payments come from external services. The site calls them straight from the browser with their public key. The result is a full app without a server of your own.
Postgres, auth and file storage, called straight from a static site
Firestore and Google sign-in from a static site
Ready-made auth and UI components for the front end
Take international payments from a static site
Open-source BaaS: database, auth and files from the browser
YooKassa, CloudPayments, T-Bank: take rubles on a static site
Counter, Session Replay and click maps on a static site
Lightweight private analytics with no cookie banner
Form submissions as Telegram or MAX messages, no bot of your own
Take YooKassa payments on a static site: links and widget
A headless CMS as the content source for a static site
Why this is safe
A public key is normal
For Supabase (anon key), Firebase (web config), Clerk (publishable key) and Appwrite (project ID), the browser key is public by design, so nobody hides it. Access to the data is limited by the service's own rules: Row-Level Security, Security Rules, permissions. Setting them up is your part, and it is standard practice.
Tuqo is not in the data path
We serve the front end over HTTPS and never touch your data or the service's secrets. Real secrets (admin keys, server APIs) never go into a static site: they are used from the service's own server functions (Supabase Edge Functions, for example).
- Free SSL on every plan; custom domains from the Start plan
- Deploy from the panel, the CLI or an AI agent (MCP)
- Servers in Russia: sites open there without a VPN
- The backend stays yours — switch whenever you like
Front end on Tuqo, any backend you like
A free plan, deploys in seconds, a full app without a server of your own.