DEV Community: Aravind Govindhasamy

SMS and WhatsApp sign-in codes for Supabase with MSG91

Aravind Govindhasamy — Sun, 01 Nov 2026 00:00:00 +0000

Phone sign-in is how many users in India expect to log in. Supabase Auth generates and checks the codes; you just need to deliver them. Supabase's built-in SMS providers don't cover every country's rules well, and none send WhatsApp, so Supabase lets you take over delivery with a Send SMS hook. This guide wires that hook to MSG91, which handles Indian SMS regulations and WhatsApp.

How it works

A user enters their phone number; your frontend calls supabase.auth.signInWithOtp({ phone }).
Supabase generates a six-digit code and calls your hook over HTTPS with the phone number and code.
Your FastAPI endpoint verifies the request came from Supabase and sends the code through MSG91.
The user types the code; supabase.auth.verifyOtp({ phone, token, type: "sms" }) signs them in.

1. Get your MSG91 auth key

MSG91_AUTH_KEY=...

2. For SMS in India: register on DLT

Indian telecom rules (TRAI) require every business SMS to be registered on a DLT platform run by the operators:

Register your business as a Principal Entity and get an Entity ID.
Register a header (the sender name users see, usually 6 letters).
Register a content template for your code, for example: {#var#} is your Example sign-in code. It expires in 10 minutes.
Add the approved template in MSG91 and note its template id.

Messages that don't match an approved template are dropped by the operators. Approval takes from a few hours to a few days, so start early.

3. For WhatsApp: an authentication template

Connect a WhatsApp Business number in MSG91 and create an Authentication template. Meta approves it, usually quickly. Authentication templates put the code in the message body and a "copy code" button.

MSG91_WHATSAPP_NUMBER=919876543210 # your integrated number, country code first

4. Write the hook endpoint

Supabase signs hook requests with the Standard Webhooks scheme. The secret Supabase gives you looks like v1,whsec_<base64>; strip the prefix and verify the webhook-id, webhook-timestamp and webhook-signature headers:

import base64, hashlib, hmac, json, time
import httpx
from fastapi import Request
from fastapi.responses import JSONResponse

def verify(body: bytes, headers, secret: str) -> None:
    key = base64.b64decode(secret.removeprefix("v1,whsec_"))
    msg_id, ts = headers["webhook-id"], headers["webhook-timestamp"]
    if abs(time.time() - int(ts)) > 300:
        raise ValueError("stale")
    signed = f"{msg_id}.{ts}.".encode() + body
    expected = base64.b64encode(hmac.new(key, signed, hashlib.sha256).digest()).decode()
    if not any(hmac.compare_digest(expected, s.split(",", 1)[1])
               for s in headers["webhook-signature"].split()):
        raise ValueError("bad signature")

@app.post("/hooks/send-sms")
async def send_sms_hook(request: Request):
    body = await request.body()
    try:
        verify(body, request.headers, SEND_SMS_HOOK_SECRET)
    except (KeyError, ValueError):
        return JSONResponse({"error": {"http_code": 401, "message": "invalid"}}, 401)
    event = json.loads(body)
    phone, otp = event["user"]["phone"].lstrip("+"), event["sms"]["otp"]
    httpx.post(
        "https://control.msg91.com/api/v5/otp",
        params={"mobile": phone, "template_id": MSG91_OTP_TEMPLATE_ID},
        json={"OTP": otp},
        headers={"authkey": MSG91_AUTH_KEY},
        timeout=15,
    ).raise_for_status()
    return {}

A 200 with an empty body tells Supabase the code was sent. For WhatsApp, send your approved template through MSG91's WhatsApp API instead, with the code as the body variable and the button value.

5. Turn it on in Supabase

Authentication → Providers → Phone: enable phone sign-in.
Authentication → Hooks: add a Send SMS hook of type HTTPS , URL https://api.example.com/hooks/send-sms.
Generate the hook secret there and put it in your API's environment as SEND_SMS_HOOK_SECRET.

6. Test it

Sign in with your own number. If no message arrives, check, in order: your API's logs (did the hook arrive and verify?), MSG91's delivery reports (did it send?), and the DLT template (does the text match exactly?).

Cost note: every code is a paid message, so keep Supabase's rate limits on and consider a CAPTCHA on the form (Turnstile guide) to stop SMS pumping attacks.

Using it with FastAPI Supabase Starter

The hook endpoint, signature checks, MSG91 client and a delivery log are built in. Set MSG91_AUTH_KEY, SEND_SMS_HOOK_SECRET and (for WhatsApp) MSG91_WHATSAPP_NUMBER with OTP_CHANNEL=whatsapp, add the hook in Supabase, and map the otp template to your DLT template id or WhatsApp template name under Admin › Messaging. See Sign-in methods.

Razorpay and Stripe in one FastAPI app, without trusting the browser

Aravind Govindhasamy — Fri, 30 Oct 2026 00:00:00 +0000

If you sell to customers in India, you want UPI, and for that you want Razorpay. If you also sell abroad, Stripe Checkout is the easiest way to take cards. The starter does both from one FastAPI app, with one rule that matters more than either provider: the browser never decides that a payment succeeded.

Prices live on the server

Products and their prices are a dictionary in backend/app/api/payments.py:

PRODUCTS: dict[str, dict] = {
    "pro": {
        "name": "Pro upgrade",
        "plan": "pro", # profiles.plan after payment
        "prices": {"stripe": (1900, "usd"), "razorpay": (149900, "inr")},
    },
}

Amounts are in minor units (cents and paise). The client sends a product id, never an amount, so nobody can buy the Pro plan for one rupee by editing a request.

Pending until a webhook says otherwise

Checkout creates a pending row in payments and returns the provider's checkout URL or order. When the customer pays, the provider calls a webhook:

Stripe: /payments/webhooks/stripe, with the checkout.session.* events
Razorpay: /payments/webhooks/razorpay, with order.paid and payment.failed

The backend verifies the signature, and only then marks the payment paid and calls on_paid(), which upgrades the user's plan. A success page in the browser is just a page; it changes nothing.

Exactly once, even when providers retry

Payment providers retry webhooks, sometimes several times. Each event is recorded with its id, and applying it twice is a no-op, so a retried order.paid can't grant the plan twice or notify the buyer twice. The tests replay webhooks to prove it.

Money is never added across currencies

Revenue charts and the admin payments list keep each currency separate. Adding ₹499 to $9 gives a number that means nothing, so the starter never does it.

Turning it on

A provider appears in the UI once its keys are in .env. Set the webhook URL in the provider's dashboard, pick the events above, and you can take a test payment in a few minutes. The payments guide has the details.

Add Google sign-in to Supabase, step by step

Aravind Govindhasamy — Wed, 28 Oct 2026 00:00:00 +0000

"Continue with Google" is the sign-in most users reach for. With Supabase Auth it takes about fifteen minutes: a client in Google Cloud, two values pasted into Supabase, and one function call in your frontend.

What you need

A Google account with access to Google Cloud Console
Your Supabase project
Your app's URL (for example https://example.com) and, for development, http://localhost:5173

1. Create a Google Cloud project

In Google Cloud Console, pick a project from the selector at the top or create a new one, for example "Example Auth". Keep one project per product, so the consent screen shows the right name.

2. Set up the consent screen

Open Google Auth Platform (search for "OAuth consent screen" if you can't find it). Fill in:

Branding: your app name, support email, logo and your homepage, privacy policy and terms links. Users see this when they sign in.
Audience: External , so any Google account can sign in. While the app is in Testing , only test users you list can sign in; click Publish app when you go live.
Data Access (Scopes): add openid. The .../auth/userinfo.email and .../auth/userinfo.profile scopes are the defaults. Avoid sensitive scopes: they trigger Google's verification review.

Google may review your branding before your logo shows, which can take a few business days. Sign-in works meanwhile.

3. Create the OAuth client

Go to Clients → Create client and choose Web application.

Authorized JavaScript origins: your app's origin, with no path: https://example.com. Add http://localhost:5173 for development, and remove it before launch.
Authorized redirect URIs: Supabase's callback, not your app's URL. Copy it from the Supabase dashboard ( Authentication → Providers → Google , "Callback URL"). It looks like:

https://<project-ref>.supabase.co/auth/v1/callback

Click Create and copy the Client ID and Client secret.

4. Enable Google in Supabase

In Supabase, open Authentication → Providers → Google , turn it on, paste the client ID and secret, and save.

Then open Authentication → URL Configuration :

Site URL: https://example.com
Redirect URLs: https://example.com/ ** and http://localhost:5173/**

Supabase only sends users back to URLs on this list.

5. Add the button

With supabase-js in a React app:

await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo: `${window.location.origin}/dashboard` },
})

The browser goes to Google, then to Supabase's callback, then back to redirectTo with a session. Your FastAPI backend receives the same kind of access token as for any other sign-in, so nothing changes there. How to verify it.

Common errors

Error	Fix
`redirect_uri_mismatch`	The redirect URI in Google must be Supabase's callback URL exactly, including `https` and `/auth/v1/callback`.
Back on the Site URL instead of your page	Add the `redirectTo` URL to Supabase's Redirect URLs list.
"Access blocked: app is in testing"	Add the account as a test user, or publish the app.
Users see `<project-ref>.supabase.co` on Google's screen	Expected on the default domain. A Supabase custom domain (such as `auth.example.com`) shows your own domain instead.

Using it with FastAPI Supabase Starter

Do steps 1 to 4, then list the buttons to show in .env and rebuild the frontend:

OAUTH_PROVIDERS=google

Add more providers the same way (OAUTH_PROVIDERS=google,github) after enabling each in Supabase. See Sign-in methods for email codes, SMS, WhatsApp and CAPTCHA.

Google Search Console and GA4 for a React site, the right way

Aravind Govindhasamy — Wed, 28 Oct 2026 00:00:00 +0000

A React app can rank in Google, but only if Google gets real HTML for your public pages. This guide covers that first, then Search Console (what Google sees), then Google Analytics 4 (what visitors do), with two pitfalls specific to apps that also have sign-in.

1. Give crawlers real HTML

A classic single-page app serves the same empty index.html for every URL and fills it in with JavaScript. Google can render JavaScript, but slowly and not always; other search engines, link previews (WhatsApp, LinkedIn, X) and AI crawlers mostly don't.

Pre-render the public pages (home, pricing, blog, docs) to HTML at build time, each with its own <title>, description, canonical link and Open Graph tags, and keep the signed-in app as a single-page app. Frameworks like TanStack Start, Astro or Next.js do this. Then generate:

sitemap.xml listing every public page
robots.txt that allows crawling and points to the sitemap

2. Verify your site in Search Console

Go to search.google.com/search-console and Add property. Two kinds:

Domain (example.com): covers every subdomain and protocol. Verify with a DNS TXT record. On Cloudflare, Google can add it for you.
URL prefix (https://example.com/): covers just that address. Verify by uploading an HTML file Google gives you (put it in your frontend's public/ folder so every build includes it), a meta tag, or Google Analytics.

Keep the verification file or record forever: Google re-checks, and removing it loses access.

3. Submit the sitemap and request indexing

Sitemaps: submit https://example.com/sitemap.xml. Search Console shows how many URLs it found.
URL Inspection: paste your most important URLs (home, pricing) and click Request indexing. There's a small daily quota, so use it on pages that matter.

First data appears in two or three days; a new site can take a few weeks to be fully indexed. Watch Pages for URLs Google found but didn't index, and why.

Also add Bing Webmaster Tools (bing.com/webmasters): it imports your Search Console site in a minute, and Bing's index feeds several AI search products.

4. Add Google Analytics 4

In analytics.google.com, create a property and a Web data stream for your domain. Copy the Measurement ID (G-XXXXXXXXXX).

Keep Enhanced measurement on: its "page changes based on browser history events" option counts client-side navigation in a single-page app as page views, so you don't need router code.

Load the tag from your public pages:

let loaded = false

function loadAnalytics(id: string) {
  if (loaded) return
  loaded = true
  const w = window as unknown as { dataLayer?: unknown[] }
  const dataLayer = (w.dataLayer ??= [])
  function gtag(..._args: unknown[]) {
    dataLayer.push(arguments) // gtag.js expects the arguments object, not an array
  }
  gtag("js", new Date())
  gtag("config", id)
  const script = document.createElement("script")
  script.async = true
  script.src = `https://www.googletagmanager.com/gtag/js?id=${id}`
  document.head.append(script)
}

Keep the ID in configuration, not in code, if other people or projects use the same codebase.

Pitfall 1: sign-in tokens in the URL

Some auth flows (Supabase's implicit flow, for example) return the user to your site with #access_token=... in the address. If analytics loads on that page, the token can end up in Google's reports. Skip loading analytics when the URL carries a token:

if (!location.hash.includes("access_token")) loadAnalytics(GA_ID)

Pitfall 2: another tag already created `dataLayer`

Cloudflare's Google tag gateway, a Tag Manager container or a plugin may create window.dataLayer before your code runs. Don't treat "dataLayer exists" as "analytics is loaded", or your tag never loads; track your own loaded flag and share the existing array, as in the snippet above. And if a Tag Manager container already fires your GA4 tag, don't load it twice, or every visit counts double.

5. Check it

GA4 Reports → Realtime : open your site and see yourself within a minute.
Search Console Sitemaps : status "Success".
Share a page link in a chat app: the preview shows its own title, description and image.

If you have visitors from the EU, Google Analytics' cookies need consent there. Cookie-free alternatives such as Cloudflare Web Analytics avoid the banner.

Using it with FastAPI Supabase Starter

The public site is already pre-rendered, with per-page titles, descriptions, share images, structured data, sitemap.xml, robots.txt and an RSS feed. Set GA_MEASUREMENT_ID in .env and rebuild: the tag loads on public pages only, never on a URL carrying a session, and shares any existing dataLayer. Put Google's verification file in frontend/public/. See Blog and help pages.

Get a Gemini API key and call it from FastAPI

Aravind Govindhasamy — Mon, 26 Oct 2026 00:00:00 +0000

Google's Gemini models are fast, capable and have a free tier for development, which makes them a good first model for an in-app assistant. This guide gets a key, keeps it safe, and calls Gemini from FastAPI, including letting the model call your own Python functions.

1. Create the key in Google AI Studio

Go to aistudio.google.com/apikey and sign in with a Google account.
Click Create API key. New accounts get a default Google Cloud project; if you already use Google Cloud, choose Import projects and pick the project that should own the key and its billing.
Copy the key into your server's environment:

GEMINI_API_KEY=...

Every key belongs to a Google Cloud project, which is where billing, quotas and limits live. Before you launch, read Google's current free-tier limits and data-use terms: Google has treated free-tier and paid-tier prompts differently, so turn on billing before real users' data goes through it.

2. Keep it on the server

Never put the key in frontend code or a mobile app; anyone can read it there and spend your quota. The browser talks to your API, and your API talks to Gemini. That also lets you check who's asking and apply per-user limits.

3. Call Gemini from FastAPI

uv add google-genai


from google import genai
from pydantic import BaseModel

client = genai.Client() # reads GEMINI_API_KEY from the environment

class Ask(BaseModel):
    message: str

@app.post("/assistant")
async def assistant(body: Ask, user: CurrentUser):
    response = await client.aio.models.generate_content(
        model="gemini-2.5-flash",
        contents=body.message,
    )
    return {"reply": response.text}

Use the async client (client.aio) so a slow model call doesn't block other requests. Check Google's models page for the current model names; flash models are the fast, inexpensive default.

4. Let the model call your functions

Tool calling turns a chatbot into an assistant that can look things up. With the SDK, a typed Python function with a docstring becomes a tool:

from google.genai import types

def list_items(limit: int = 10) -> list[dict]:
    """List the signed-in user's most recent items."""
    return fetch_items_for_current_user(limit=min(limit, 50))

response = await client.aio.models.generate_content(
    model="gemini-2.5-flash",
    contents="What did I add this week?",
    config=types.GenerateContentConfig(tools=[list_items]),
)

The SDK runs the function when the model asks for it and sends the result back. Two rules keep this safe:

Tools run as the user. Query with the user's own credentials so the model can never reach other people's data. With Supabase, pass the user's token so row-level security applies. How.
Tools are read-only or additive. The model acts without asking for confirmation, so don't give it a "delete everything" tool.

5. Put limits on it

AI calls cost money. Count requests per user per day and refuse past a plan's limit with a 429. Store conversations if users expect history, and log token usage so you can see costs per user.

Using it with FastAPI Supabase Starter

The assistant page, saved conversations, tool calling and per-plan daily and monthly limits are built in. Set GEMINI_API_KEY (and optionally GEMINI_MODEL, default gemini-2.5-flash), and the same tools are served over MCP so Claude and Cursor can use your app as the signed-in user. Add a tool by writing a typed function in backend/app/ai/tools.py and appending it to TOOLS. See AI assistant and MCP.

Razorpay API keys and webhooks: from test mode to live payments

Aravind Govindhasamy — Mon, 26 Oct 2026 00:00:00 +0000

Razorpay is the easiest way to accept UPI, cards and netbanking in India. This guide gets you from a new account to verified payments: keys, an order created on your server, Razorpay Checkout in the browser, and a webhook that confirms the payment.

How the pieces fit

Your API creates an order with the amount (server-side, so the browser can't change the price).
The browser opens Razorpay Checkout with that order's id. The customer pays by UPI, card or netbanking.
Razorpay calls your webhook with order.paid. Your API checks the signature and marks the payment paid.

The browser's "payment succeeded" callback is only a hint for the UI. The signed webhook is the only thing you should trust.

1. Generate test keys

In the Razorpay Dashboard, switch to Test mode , then go to Account & Settings → API Keys (under Website and app settings ) and click Generate Key.

You get a Key ID (starts rzp_test_, safe to send to the browser) and a Key Secret (server only). The dashboard won't show the secret again, so store it right away.

RAZORPAY_KEY_ID=rzp_test_...
RAZORPAY_KEY_SECRET=...

Test mode is a full simulation: no real money moves, and Razorpay provides test cards and UPI ids.

2. Create an order from FastAPI

Amounts are in paise: ₹1,499.00 is 149900.

import httpx

def create_order(amount_paise: int, receipt: str) -> dict:
    r = httpx.post(
        "https://api.razorpay.com/v1/orders",
        auth=(RAZORPAY_KEY_ID, RAZORPAY_KEY_SECRET),
        json={"amount": amount_paise, "currency": "INR", "receipt": receipt},
        timeout=15,
    )
    r.raise_for_status()
    return r.json() # contains "id": "order_..."

Look the price up on the server from a product id. Never accept an amount from the browser.

3. Open Checkout in the browser

Load Razorpay's script and open Checkout with your Key ID and the order id:

await new Promise((resolve) => {
  const s = document.createElement("script")
  s.src = "https://checkout.razorpay.com/v1/checkout.js"
  s.onload = resolve
  document.body.append(s)
})

new (window as any).Razorpay({
  key: RAZORPAY_KEY_ID,
  order_id: order.id,
  name: "Example",
  handler: () => showMessage("Payment received, confirming…"),
}).open()

4. Add the webhook

Webhooks need a public HTTPS URL; Razorpay won't save a localhost one. For local testing, expose your API with a tunnel such as Cloudflare Tunnel or ngrok.

In the Dashboard (in the same mode as your keys), go to Account & Settings → Webhooks → Add New Webhook :

Webhook URL: https://api.example.com/payments/webhooks/razorpay
Secret: a long random string you generate; it's not your Key Secret
Alert Email: where Razorpay reports failures
Active Events: order.paid and payment.failed

RAZORPAY_WEBHOOK_SECRET=...

Set the webhook up again when you switch to live mode, with its own secret.

5. Verify the signature

Razorpay signs the raw request body with HMAC-SHA256 using the webhook secret and sends the hex digest in X-Razorpay-Signature:

import hashlib
import hmac
import json

from fastapi import HTTPException, Request

@app.post("/payments/webhooks/razorpay")
async def razorpay_webhook(request: Request):
    body = await request.body() # the raw bytes, before any JSON parsing
    expected = hmac.new(RAZORPAY_WEBHOOK_SECRET.encode(), body, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, request.headers.get("x-razorpay-signature", "")):
        raise HTTPException(400, "Bad signature")
    event = json.loads(body)
    if event["event"] == "order.paid":
        mark_paid(event["payload"]["order"]["entity"]["id"]) # idempotent
    return {}

Razorpay retries deliveries, so make mark_paid idempotent: record each event or order id once, and ignore repeats.

6. Go live

In live mode, Razorpay asks for the website where you'll take payments and verifies it (it can take a few working days). Make sure the site has the policy pages Razorpay checks for: terms, privacy, refunds and cancellation, shipping or delivery, and contact details.
Generate live keys (rzp_live_...) and a live webhook with a new secret.
Swap the three values in production and make a small real payment to check.

Using it with FastAPI Supabase Starter

Steps 2, 3 and 5 are already built: products and prices live on the server, the billing page opens Checkout, and the webhook verifies the signature and applies each event exactly once before upgrading the user's plan. Set the three RAZORPAY_* values, point the webhook at /payments/webhooks/razorpay, and the public site already has the policy pages Razorpay asks for. See Payments and the payments design.

Deploy FastAPI and React with Docker Compose

Aravind Govindhasamy — Mon, 26 Oct 2026 00:00:00 +0000

Docker Compose gives you the same setup on your laptop and your server: one command builds and starts the API and the frontend. This guide covers both Dockerfiles, the one setting people get wrong (build-time variables for the frontend), and going to production.

The backend image

With uv, the image is small and the install is reproducible from the lockfile:

FROM python:3.12-slim
COPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv

WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv sync --frozen --no-dev
COPY app ./app

EXPOSE 8000
CMD ["/app/.venv/bin/fastapi", "run", "app/main.py", "--port", "8000"]

Copying pyproject.toml and uv.lock before the code means dependency layers are cached until the dependencies change. Pin the uv image to a version in production instead of latest.

The frontend image

A React build is static files, so build with Node and serve with nginx:

FROM node:24-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
ARG API_URL SITE_URL
RUN npm run build

FROM nginx:alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /app/dist /usr/share/nginx/html

With an nginx.conf that falls back to the app for client-side routes:

server {
  listen 80;
  root /usr/share/nginx/html;
  location / { try_files $uri $uri/index.html /index.html; }
}

Build-time vs run-time settings

This trips everyone up once. The frontend's settings (the API URL, public keys, analytics ids) are baked into the JavaScript at build time. Setting them as container environment variables does nothing; they must be build args , and you rebuild when they change. The backend reads its settings at run time from the environment.

compose.yml

services:
  backend:
    build: ./backend
    env_file: .env
    ports:
      - "8000:8000"

  frontend:
    build:
      context: ./frontend
      args:
        API_URL: ${API_URL:-http://localhost:8000}
        SITE_URL: ${SITE_URL:-http://localhost:5173}
    ports:
      - "5173:80"

Compose reads ${API_URL} from your .env file next to compose.yml, so one file feeds both.

docker compose up --build -d
docker compose logs -f backend

Production

Set public URLs in .env: API_URL=https://api.example.com, SITE_URL=https://example.com, then rebuild (docker compose up --build -d).
Put HTTPS in front. Bind the ports to localhost ("127.0.0.1:8000:8000") and use a reverse proxy on the host: nginx with certbot, Caddy, or Cloudflare Tunnel with no open ports at all.
Real client IPs. If the proxy reaches the API over Docker's network, the API sees the proxy's container address. Set uvicorn's FORWARDED_ALLOW_IPS to that address (for example the bridge gateway 172.18.0.1) so X-Forwarded-For is trusted.
Restart policy. Add restart: unless-stopped to both services.
Updates: git pull && docker compose up --build -d, then check the health endpoint.

Using it with FastAPI Supabase Starter

The starter ships both Dockerfiles and a compose.yml with every build arg listed (SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, API_URL, SITE_URL, OAUTH_PROVIDERS, TURNSTILE_SITE_KEY, SENTRY_DSN, GA_MEASUREMENT_ID). Fill in .env and run docker compose up --build: the app is on port 5173 and the API on 8000. There's no database container, because Supabase hosts Postgres. See the quick start and Deploy to production.

Deploy FastAPI and a React app on a VPS with nginx, systemd and uv

Aravind Govindhasamy — Sun, 25 Oct 2026 00:00:00 +0000

A single small VPS (or a home server) runs a FastAPI + React app comfortably. No containers needed: the frontend is static files, the API is one Python process under systemd, and nginx sits in front of both.

What you need

An Ubuntu server (22.04 or newer) you can SSH into
A domain with two DNS records pointing at the server: example.com (the site) and api.example.com (the API)
Your app's code, with the backend managed by uv

1. Prepare the server

sudo apt update && sudo apt install -y nginx
curl -LsSf https://astral.sh/uv/install.sh | sh # installs uv for your user

Open only what you need with the firewall:

sudo ufw allow OpenSSH && sudo ufw allow 'Nginx Full' && sudo ufw enable

2. Build the frontend where you develop

Build on your own machine (or in CI), not on the server: the server doesn't need Node, and a build failure never takes the site down.

cd frontend
API_URL=https://api.example.com SITE_URL=https://example.com npm run build

Copy the output to the server:

tar -czf - -C dist . | ssh user@server 'sudo mkdir -p /var/www/example && sudo tar -xzf - -C /var/www/example'

(If your build writes to a subfolder, such as dist/client for a pre-rendered TanStack Start site, copy that folder instead.)

3. Install the API

Copy the backend to the server (for example with git archive), then:

cd ~/app/backend
uv sync --frozen --no-dev

Put secrets in ~/app/.env with permissions 600. Then create /etc/systemd/system/example-api.service:

[Unit]
Description=Example API
After=network-online.target

[Service]
User=deploy
WorkingDirectory=/home/deploy/app/backend
EnvironmentFile=/home/deploy/app/.env
ExecStart=/home/deploy/app/backend/.venv/bin/uvicorn app.main:app --host 127.0.0.1 --port 8000 --workers 2 --proxy-headers --forwarded-allow-ips 127.0.0.1
Restart=always

[Install]
WantedBy=multi-user.target


sudo systemctl daemon-reload && sudo systemctl enable --now example-api
curl http://127.0.0.1:8000/health

--proxy-headers with --forwarded-allow-ips 127.0.0.1 makes uvicorn trust nginx's X-Forwarded-For, so your logs and rate limits see real client IPs, not 127.0.0.1.

4. Configure nginx

/etc/nginx/sites-available/example:

server {
    server_name example.com;
    root /var/www/example;

    location /assets/ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        try_files $uri =404;
    }

    location / {
        add_header Cache-Control "no-cache";
        try_files $uri $uri/index.html /index.html;
    }
}

server {
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The try_files line serves a page's own HTML when it exists (pre-rendered pages) and falls back to the single-page app for every other path. Use your SPA's shell file in place of /index.html if it has a different name.

sudo ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

5. HTTPS

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d api.example.com

Certbot edits the nginx config and renews certificates automatically. Behind Cloudflare, or with no public IP at all, use Cloudflare Tunnel instead and skip this step.

6. Redeploy

A redeploy is the same three moves: build and copy the frontend, copy the backend and uv sync, restart the service.

sudo systemctl restart example-api && curl -fsS https://api.example.com/health

Checklist

.env is readable only by the service user, and never committed.
The API listens on 127.0.0.1 only; nginx is the only public entry.
An uptime monitor watches /health.
Logs: journalctl -u example-api -f.

Using it with FastAPI Supabase Starter

This is how the starter's own demo runs. Build with API_URL and SITE_URL, copy frontend/dist/client, and use /_shell.html as the fallback in try_files. The API needs no database password: it talks to Supabase over HTTPS. Webhook and hook URLs to register afterwards are listed in Deploy to production.

Cloudflare Tunnel: publish a home server or VPS without opening ports

Aravind Govindhasamy — Thu, 22 Oct 2026 15:52:06 +0000

Cloudflare Tunnel lets a machine that can't accept incoming connections (a home server behind your router, a laptop, a VPS with every port closed) serve websites on your domain. A small program, cloudflared, opens an outbound connection to Cloudflare, and Cloudflare sends your visitors' requests down it. You get HTTPS, DDoS protection and no open ports, for free.

What you need

A domain using Cloudflare's nameservers (add it to Cloudflare and change the nameservers at your registrar)
A Linux machine running your app on local ports, for example a website on localhost:8080 and an API on localhost:8000

1. Create the tunnel

In the Cloudflare dashboard, go to Networking → Tunnels (in the Zero Trust dashboard it's Networks → Tunnels ) and click Create a tunnel. Choose cloudflared , give it a name such as home-server, and save.

Cloudflare shows install commands for your operating system. On Debian or Ubuntu they add Cloudflare's package repository, install cloudflared, and register it as a service with your tunnel's token:

sudo cloudflared service install <TOKEN>

Within a few seconds the dashboard shows the connector as Connected. The token is a credential: anyone with it can run your tunnel, so don't paste it in public.

2. Route a hostname to a local port

Open the tunnel, go to Routes , click Add route and choose Published application (older dashboards call this Public hostnames → Add a public hostname ):

Field	Example
Subdomain	`app`
Domain	`example.com`
Path	(empty)
Service URL	`http://localhost:8080`

Save. Cloudflare creates the DNS record for app.example.com itself (a proxied CNAME to your tunnel), and the site is live over HTTPS. No restart needed.

Add as many hostnames as you like to one tunnel, for example api.example.com → http://localhost:8000.

3. See real visitor IPs

Requests reach your app from cloudflared on the same machine, so your app sees 127.0.0.1 as every visitor's address. Cloudflare passes the real one in X-Forwarded-For and CF-Connecting-IP. Tell your server to trust them from localhost:

uvicorn (FastAPI): --proxy-headers --forwarded-allow-ips 127.0.0.1
nginx: set_real_ip_from 127.0.0.1; real_ip_header CF-Connecting-IP;

Without this, per-IP rate limits treat all your visitors as one.

Gotchas

Dashboard tunnels ignore local ingress rules. If you created the tunnel in the dashboard, editing /etc/cloudflared/config.yml changes nothing: the routes come from the dashboard. Manage hostnames there.
Restarting cloudflared drops every hostname on the tunnel for a few seconds. You don't need to restart it to add or change routes.
Keep your firewall closed. The tunnel is outbound, so ufw default deny incoming stays as it is.
Webhooks work. Stripe, Razorpay and Supabase hooks reach a tunneled API like any HTTPS URL, which also makes a tunnel handy for testing webhooks from your laptop.
Cloudflare settings apply. Caching rules, Bot Fight Mode and Cloudflare's managed robots.txt affect tunneled sites like any other. If search engines or AI crawlers can't see your site, check those first.
Protect private tools. Put admin hostnames behind Cloudflare Access so only your email can reach them.

Check it

curl -I https://app.example.com # should show server: cloudflare
sudo systemctl status cloudflared # connector running

Using it with FastAPI Supabase Starter

Serve the built frontend (for example with nginx on a local port) and run the API on 127.0.0.1:8000, then add two routes: your site's hostname to the frontend's port and api. to port 8000. Set API_URL, FRONTEND_URL and SITE_URL to the public HTTPS addresses, and keep FORWARDED_ALLOW_IPS at its localhost default so the request log and rate limit see real IPs. The full server setup is in Deploy FastAPI and React on a VPS.

Supabase API keys explained: publishable, secret and JWT signing keys for FastAPI

Aravind Govindhasamy — Thu, 22 Oct 2026 00:00:00 +0000

Supabase gives every project a URL and a handful of keys, and mixing them up is the most common way to leak data. This guide covers what each one is, where it belongs, and how a FastAPI backend should use them.

The keys at a glance

Key	Looks like	Where it goes	Row-level security
Project URL	`https://<project-ref>.supabase.co`	Browser and server	—
Publishable key	`sb_publishable_...`	Browser, mobile apps, and your server	Applies
Secret key	`sb_secret_...`	Server only, never a browser	Bypassed
Legacy `anon` key	A long JWT starting `eyJ`	Same as publishable	Applies
Legacy `service_role` key	A long JWT starting `eyJ`	Same as secret	Bypassed

The legacy anon and service_role keys still work, but Supabase is retiring them by the end of 2026. Use the publishable and secret keys in new code.

1. Find your URL and keys

In the Supabase dashboard, open your project and go to Project Settings → API Keys. The Connect button at the top of the project also shows the URL and publishable key.

Put them in your backend's environment:

SUPABASE_URL=https://<project-ref>.supabase.co
SUPABASE_PUBLISHABLE_KEY=sb_publishable_...
SUPABASE_SECRET_KEY=sb_secret_...

The frontend only ever gets the URL and the publishable key.

2. Know what the secret key can do

The secret key skips row-level security: any query made with it can read and change every row. Supabase refuses it from a browser (it answers 401), but that check isn't protection on its own. Keep it in server environment variables only, and use it only for work no user owns, such as:

recording a payment after a verified webhook
looking up an API key's owner
sending a message on the system's behalf

For everything a user asks for, call Supabase as that user (step 4).

Tip: create a separate secret key for each backend component (API, workers, scripts). If one leaks, you rotate that one: create a new key under API Keys , deploy it, confirm it works, then delete the old one.

3. Verify the user's token in FastAPI

When a user signs in, Supabase Auth gives the browser an access token (a JWT). The browser sends it to your API as Authorization: Bearer <token>. Your API must check it before trusting it.

Supabase signs tokens with JWT signing keys. With asymmetric keys (ES256 or RS256), the public keys are published at a JWKS endpoint, so your API can verify tokens without any secret:

https://<project-ref>.supabase.co/auth/v1/.well-known/jwks.json

With PyJWT:

import jwt

jwks = jwt.PyJWKClient(f"{SUPABASE_URL}/auth/v1/.well-known/jwks.json", cache_keys=True)

def verify_token(token: str) -> dict:
    alg = jwt.get_unverified_header(token).get("alg")
    if alg not in ("ES256", "RS256"):
        raise jwt.InvalidAlgorithmError(alg)
    key = jwks.get_signing_key_from_jwt(token).key
    return jwt.decode(token, key, algorithms=[alg], audience="authenticated",
                      options={"require": ["exp", "sub"]})

Older projects may still sign with the legacy shared JWT secret (HS256). If yours does, verify with that secret instead, or migrate to signing keys on the JWT Keys page of your project settings, where Supabase moves keys through standby, current and revoked states so you can rotate in stages. Always pin the algorithm: never accept whatever the token's header claims.

4. Call Supabase as the user

The safest pattern is to pass the user's own token through to Supabase. Postgres then sees who is asking, and your row-level security policies decide what they can read or write:

from postgrest import SyncPostgrestClient

def as_user(token: str) -> SyncPostgrestClient:
    return SyncPostgrestClient(
        f"{SUPABASE_URL}/rest/v1",
        headers={"apikey": SUPABASE_PUBLISHABLE_KEY, "Authorization": f"Bearer {token}"},
    )

items = as_user(token).from_("items").select("*").execute().data # only this user's rows

Compare that with connecting to Postgres directly or using the secret key for everything: then every route has to remember to filter by owner, and one forgotten where user_id = ... leaks other people's data. Why we never connect to Postgres directly.

Checklist

The browser has the URL and publishable key, nothing else.
The secret key lives in server environment variables and is used only for system work.
Your API verifies every token with the JWKS endpoint and a pinned algorithm.
User requests reach Supabase with the user's own token, so RLS applies.
Every table has RLS enabled, with policies written for auth.uid().

Using it with FastAPI Supabase Starter

The starter is built this way. Copy the three values above into .env and you're done: verify_token() checks tokens against your project's JWKS (with the legacy secret as a fallback), every route queries through as_user(token), and the secret key is used only for verified webhooks, payments and API-key lookups. API keys and MCP clients get a real Supabase session for their owner, so the same RLS applies to them. Setup steps are in the quick start.

Send Supabase Auth emails through Resend SMTP (with Cloudflare DNS)

Aravind Govindhasamy — Thu, 22 Oct 2026 00:00:00 +0000

Out of the box, Supabase Auth sends confirmation, magic-link and password-reset emails through a shared service meant for testing. It only delivers to members of your Supabase team, and only about 2 messages an hour. The first real user who signs up won't get their email. The fix is custom SMTP, and Resend is a quick, developer-friendly option.

What you need

A Resend account
A domain you control, with DNS on Cloudflare (other DNS hosts work the same way)
Your Supabase project

1. Pick a sending domain

Send from a subdomain, such as mail.example.com or auth.example.com, rather than your root domain. It keeps your sending reputation separate from your main domain's mail, and Supabase's own guidance recommends a separate domain for auth emails.

Watch out: the address you send from must be on the domain you verify. If you verify mail.example.com, send from no-reply@mail.example.com. Sending from no-reply@example.com fails with a "domain is not verified" error.

2. Add the domain in Resend

In Resend, go to Domains → Add domain and enter your sending domain. Resend shows the DNS records to add.

On Cloudflare, Resend's Sign in to Cloudflare button can add them for you. To add them by hand, open your zone's DNS → Records and create:

Type	Name	Content	Notes
MX	`send` (or `send.mail` for a subdomain)	the `feedback-smtp...amazonses.com` value Resend shows	Priority 10
TXT	`send` (or `send.mail`)	`v=spf1 include:amazonses.com ~all`	SPF
TXT	`resend._domainkey` (or `resend._domainkey.mail`)	the long `p=...` value Resend shows	DKIM, DNS only

Copy the exact names Resend gives you: for a subdomain they include it. In the Name field, enter only the part before your zone's domain; Cloudflare adds the rest.

Then click Verify in Resend. Records usually propagate in minutes.

Recommended: add a DMARC record too, for example a TXT record named _dmarc with v=DMARC1; p=none; to start, then tighten it once mail flows cleanly.

3. Create an API key

In Resend, go to API Keys → Create API key. For SMTP, a key with Sending access is enough. Copy it now; it's shown once.

4. Turn on custom SMTP in Supabase

In the Supabase dashboard, open Authentication → Emails → SMTP Settings and enable custom SMTP:

Field	Value
Sender email	`no-reply@mail.example.com` (on your verified domain)
Sender name	Your product name
Host	`smtp.resend.com`
Port	`587` (STARTTLS) or `465` (SSL)
Username	`resend`
Password	your Resend API key (`re_...`)

Save. Supabase now sends to any address, starting with a limit of 30 emails an hour; raise it under Authentication → Rate Limits once you're sure the setup is right.

5. Send a test

Sign up with an address outside your team, or trigger a password reset. The email should arrive within seconds, and it shows up in Resend's Emails list with its delivery status. If it doesn't:

"Domain is not verified": the sender address isn't on the verified domain (see step 1).
Nothing in Resend's list: the SMTP details in Supabase are wrong; re-enter the password.
Lands in spam: check SPF and DKIM pass in the message headers, and add DMARC.

6. Send your app's own emails

Invitations and notifications from your API can use the same SMTP details. In FastAPI with the standard library:

import smtplib
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "no-reply@mail.example.com"
msg["To"] = "user@example.com"
msg["Subject"] = "You're invited"
msg.set_content("Join the team: https://example.com/invite/abc")

with smtplib.SMTP("smtp.resend.com", 587) as smtp:
    smtp.starttls()
    smtp.login("resend", RESEND_API_KEY)
    smtp.send_message(msg)

Run it in a thread (run_in_threadpool) or a background task so a slow mail server doesn't block requests.

Using it with FastAPI Supabase Starter

Steps 1 to 5 are the same. For the app's own emails (organization invitations and templates from Admin › Messaging ), put the same values in .env:

SMTP_HOST=smtp.resend.com
SMTP_PORT=587
SMTP_USER=resend
SMTP_PASSWORD=re_xxx
EMAILS_FROM_EMAIL=no-reply@mail.example.com

Every message is recorded with its status in the delivery log under Admin › Messaging. More in Email, SMS and WhatsApp.

Stop bot sign-ups on Supabase with Cloudflare Turnstile

Aravind Govindhasamy — Thu, 22 Oct 2026 00:00:00 +0000

Bots find sign-up forms within days of launch. They create junk accounts and, worse, use your password-reset and magic-link forms to send email to people who never asked for it, which hurts your sending reputation. Supabase Auth can require a CAPTCHA on every sign-up, sign-in and reset, and Cloudflare Turnstile is free and usually invisible to real users.

How it works

The Turnstile widget runs in your page and produces a short-lived token.
Your frontend passes that token to Supabase with the auth call.
Supabase checks the token with Cloudflare using your secret key, and refuses the request if it's missing or invalid.

Your backend doesn't need any changes.

1. Create a Turnstile widget

In the Cloudflare dashboard, open Turnstile → Add widget :

Name: your app's name
Hostnames: your domain (example.com) and localhost for development
Widget mode: Managed is a good default; most visitors never see a challenge

Copy the Site key (public, goes in your frontend) and the Secret key (goes in Supabase).

2. Add the widget to your forms

With React, the @marsidev/react-turnstile package is the simplest route:

npm install @marsidev/react-turnstile


import { Turnstile } from "@marsidev/react-turnstile"

const [captchaToken, setCaptchaToken] = useState<string>()

<Turnstile siteKey={TURNSTILE_SITE_KEY} onSuccess={setCaptchaToken} />

Then pass the token to every auth call Supabase protects:

await supabase.auth.signUp({ email, password, options: { captchaToken } })
await supabase.auth.signInWithPassword({ email, password, options: { captchaToken } })
await supabase.auth.signInWithOtp({ email, options: { captchaToken } })
await supabase.auth.resetPasswordForEmail(email, { captchaToken })

A token works once. After a failed attempt, reset the widget to get a fresh one.

3. Deploy the frontend first

This order matters. Once Supabase requires a CAPTCHA, every sign-in without a token is refused, including from users still running your previous build. So:

Deploy the frontend with the widget and captchaToken in place.
Check that sign-in still works (Supabase ignores the token until step 4).
Then turn on enforcement.

4. Turn on CAPTCHA protection in Supabase

In the Supabase dashboard, open Authentication → Attack Protection (some dashboard versions call it Bot and Abuse Protection ). Turn on Enable CAPTCHA protection , choose Cloudflare Turnstile , paste the Secret key and save.

5. Test

Sign up in a normal browser: it should work, usually without a visible challenge.
Call the auth API without a token (for example with curl): Supabase should refuse it with a CAPTCHA error.

Troubleshooting

Symptom	Cause
"captcha verification process failed" for everyone	The secret in Supabase doesn't match the site key's widget, or the hostname isn't on the widget's list.
Works in production, fails on localhost	Add `localhost` to the widget's hostnames.
Fails on the second try	Tokens are single-use; reset the widget after each attempt.

Using it with FastAPI Supabase Starter

The widget and the captchaToken wiring are already in the sign-in page. Put the site key in .env, rebuild and deploy the frontend, then add the secret key in Supabase:

TURNSTILE_SITE_KEY=0x4AAAAAAA...

Keep that variable set in every future build, or sign-in breaks once Supabase requires the CAPTCHA. See Sign-in methods.

DEV Community: Aravind Govindhasamy

SMS and WhatsApp sign-in codes for Supabase with MSG91

How it works

1. Get your MSG91 auth key

2. For SMS in India: register on DLT

3. For WhatsApp: an authentication template

4. Write the hook endpoint

5. Turn it on in Supabase

6. Test it

Using it with FastAPI Supabase Starter

Razorpay and Stripe in one FastAPI app, without trusting the browser

Prices live on the server

Pending until a webhook says otherwise

Exactly once, even when providers retry

Money is never added across currencies

Turning it on

Add Google sign-in to Supabase, step by step

What you need

1. Create a Google Cloud project

2. Set up the consent screen

3. Create the OAuth client

4. Enable Google in Supabase

5. Add the button

Common errors

Using it with FastAPI Supabase Starter

Google Search Console and GA4 for a React site, the right way

1. Give crawlers real HTML

2. Verify your site in Search Console

3. Submit the sitemap and request indexing

4. Add Google Analytics 4

Pitfall 1: sign-in tokens in the URL

Pitfall 2: another tag already created dataLayer

5. Check it

Using it with FastAPI Supabase Starter

Get a Gemini API key and call it from FastAPI

1. Create the key in Google AI Studio

2. Keep it on the server

3. Call Gemini from FastAPI

4. Let the model call your functions

5. Put limits on it

Using it with FastAPI Supabase Starter

Razorpay API keys and webhooks: from test mode to live payments

How the pieces fit

1. Generate test keys

2. Create an order from FastAPI

3. Open Checkout in the browser

4. Add the webhook

5. Verify the signature

6. Go live

Using it with FastAPI Supabase Starter

Deploy FastAPI and React with Docker Compose

The backend image

The frontend image

Build-time vs run-time settings

compose.yml

Production

Using it with FastAPI Supabase Starter

Deploy FastAPI and a React app on a VPS with nginx, systemd and uv

What you need

1. Prepare the server

2. Build the frontend where you develop

3. Install the API

4. Configure nginx

5. HTTPS

6. Redeploy

Checklist

Using it with FastAPI Supabase Starter

Cloudflare Tunnel: publish a home server or VPS without opening ports

What you need

1. Create the tunnel

2. Route a hostname to a local port

3. See real visitor IPs

Gotchas

Check it

Using it with FastAPI Supabase Starter

Supabase API keys explained: publishable, secret and JWT signing keys for FastAPI

The keys at a glance

1. Find your URL and keys

2. Know what the secret key can do

3. Verify the user's token in FastAPI

Pitfall 2: another tag already created `dataLayer`