DEV Community: Aravind Govindhasamy

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.

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.

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.

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.