How to secure the self-hosted supabase studio?

[daneshh]

Hello,
I installed self-hosted supabase on ubuntu server via docker. I put it behind nginx with server block that points location / to localhost:8000 ( kong )
Since the Kong itself is pointing to other images I cannot use ip whitelisting just for studio access.
how can I secure the studio now? because I think the basic auth username/password is not secure enough.

[aantti]

Check https://supabase.com/docs/guides/self-hosting/self-hosted-proxy-https :) The included Caddy/Nginx examples include basic auth that substitute the one in Kong.

[manimovassagh]

The default Studio credentials (DASHBOARD_USERNAME/DASHBOARD_PASSWORD in your .env) are just basic auth and not great for production exposure. Here are a few approaches in order of practicality:

1. Separate Nginx server block for Studio

You said you can't IP-whitelist because Kong handles multiple services. The fix: route Studio traffic directly to the Studio container (port 3000) instead of through Kong, using a dedicated subdomain or port:

server {
    listen 443 ssl;
    server_name studio.yourdomain.com;

    ssl_certificate     /etc/ssl/certs/yourdomain.crt;
    ssl_certificate_key /etc/ssl/private/yourdomain.key;

    # Only allow your IP(s)
    allow 203.0.113.10;  # your IP
    deny all;

    location / {
        proxy_pass http://localhost:3000;  # Studio directly, not Kong
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

server {
    listen 443 ssl;
    server_name api.yourdomain.com;

    location / {
        proxy_pass http://localhost:8000;  # Kong for API traffic
    }
}

2. Tailscale / WireGuard VPN

Probably the simplest production-grade approach. Put Studio behind a VPN so it's only accessible from your private network. With Tailscale, it's literally:

• Install Tailscale on the server
• Only expose Studio to Tailscale's interface
• Access via http://your-server-tailscale-ip:3000

Zero Nginx changes needed. Free for personal use.

3. Cloudflare Tunnel + Access

If you're already on Cloudflare:

• Create a Cloudflare Tunnel pointing to localhost:3000
• Add a Cloudflare Access policy (email OTP, GitHub SSO, etc.)
• Free tier covers this

This gives you SSO-grade auth before anyone even reaches Studio.

4. OAuth2 Proxy as a sidecar

Run oauth2-proxy as another Docker container in front of Studio. Gives you Google/GitHub login before anyone can touch Studio. Add it to your docker-compose.yml and point Nginx to the proxy instead of directly to Studio.

My recommendation: Tailscale if you want least moving parts, or Cloudflare Tunnel + Access if you're already using Cloudflare. Both are free and far more secure than any password scheme.

[daneshh]

Mamnoon,
It was a great and complete solution for production.
Recommended

[daneshh]

I configured the Nginx server block before the main block so that the studio subdomain points directly to port 3000, and that part works fine.

The issue is that when someone accesses my_server_ip:8000 in the browser, they can bypass the IP whitelisting.

I also tried changing binding ports of kong from :

- ${KONG_HTTP_PORT}:8000/tcp
- ${KONG_HTTPS_PORT}:8443/tcp

to :

- "127.0.0.1:8000:8000/tcp"
- "127.0.0.1:8443:8443/tcp"

in my docker-compose.yml. This fixed the bypass issue, but it introduced another problem—my Next.js application started failing to fetch data. In the app, I’m using api.mydomain.com instead of the server IP.

there is another problem too. in your nginx code you have pointed api.yourdomain.com to localhost:8000 ( kong ) and this causes be able to visit studio when they put https://api.yourdomain.com in the browser.

[manimovassagh]

Glad it helped! Let me address both issues:

---

1. Kong binding to 127.0.0.1 breaks your Next.js app

Binding Kong to 127.0.0.1:8000 is the right move — it prevents direct public access. Your Next.js app breaks because api.mydomain.com resolves to the server's public IP, which can no longer reach Kong on 127.0.0.1.

The fix: Keep Kong bound to 127.0.0.1:8000 and let Nginx handle the public-facing proxy. The traffic flow becomes:

Next.js → api.mydomain.com → Nginx → 127.0.0.1:8000 → Kong

This already works as long as your Nginx proxy_pass points to 127.0.0.1:8000.

If your Next.js runs on the same server, you can also split client-side vs server-side URLs:

NEXT_PUBLIC_SUPABASE_URL=https://api.mydomain.com   # client-side (browser)
SUPABASE_URL=http://127.0.0.1:8000                  # server-side (SSR)

This lets SSR calls skip Nginx entirely and go straight to Kong internally.

---

2. Studio leaking through api.yourdomain.com

This happens because Kong routes / to Studio by default. When Nginx proxies everything to Kong, visiting https://api.yourdomain.com in the browser shows Studio.

The fix: Only proxy the actual Supabase API paths on your API subdomain:

server {
    listen 443 ssl;
    server_name api.yourdomain.com;

    ssl_certificate     /etc/ssl/certs/yourdomain.crt;
    ssl_certificate_key /etc/ssl/private/yourdomain.key;

    # Only proxy Supabase API paths
    location ~ ^/(rest|auth|storage|realtime|graphql|functions)/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support (needed for Realtime)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    # Block everything else — no Studio, no Kong dashboard
    location / {
        return 404;
    }
}

Result:

• api.yourdomain.com/rest/v1/... → works (PostgREST)
• api.yourdomain.com/auth/v1/... → works (GoTrue)
• api.yourdomain.com/storage/v1/... → works (Storage)
• api.yourdomain.com/realtime/... → works (WebSockets)
• api.yourdomain.com/ → 404 (Studio blocked)

---

Complete architecture

studio.yourdomain.com  →  Nginx (IP whitelist)  →  localhost:3000 (Studio direct)
api.yourdomain.com     →  Nginx (path filter)   →  127.0.0.1:8000 (Kong, API only)
Kong binding:          →  127.0.0.1:8000 (not publicly reachable)

Studio behind IP whitelist, API publicly accessible but only for actual API endpoints, Kong completely hidden from the internet.

[daneshh]

Thanks for your answer @manimovassagh —your solution is really good.

I actually managed to stop Studio from being exposed on api.yourdomain.com in a different way, but I’m not sure if it’s the right approach.

I edited the /volumes/api/kong.yml file and commented out everything in this section:

## Protected Dashboard - catch all remaining routes
  - name: dashboard
    _comment: 'Studio: /* -> http://studio:3000/*'
    url: http://studio:3000/
    routes:
      - name: dashboard-all
        strip_path: true
        paths:
          - /
    plugins:
      - name: cors
      - name: basic-auth
        config:
          hide_credentials: true

Now api.yourdomain.com returns an error because Kong can no longer route to Studio, but studio.yourdomain.com works perfectly.

Do you think this is a good approach?

[manimovassagh]

Yes, that works and it's actually a clean approach — you're solving the problem at the source instead of patching it at the Nginx level.

By removing the Studio route from Kong, Kong no longer knows how to serve Studio at all. So even if someone hits api.yourdomain.com/ directly, Kong has no route to match and returns an error. That's exactly what you want.

One small improvement: Instead of Kong returning a raw error (which leaks that you're running Kong), you can add a default catch-all route in kong.yml that returns a clean response:

  - name: catch-all
    url: http://localhost:8000
    routes:
      - name: fallback
        paths:
          - /
        strip_path: false
    plugins:
      - name: request-termination
        config:
          status_code: 404
          message: "Not found"

This way unmatched paths return a clean 404 instead of exposing Kong internals.

One thing to keep in mind: When you update Supabase (e.g. docker compose pull && docker compose up -d), the default kong.yml might get regenerated and re-add the Studio route. To prevent that:

1. Make sure your modified kong.yml is outside the default volumes path, or
2. Add a note in your deployment docs to re-check kong.yml after updates
3. Or better: use the Nginx path-filtering approach from my previous answer as a second layer of defense, so even if Kong's config resets, Studio still won't leak through

Defense in depth — both Kong route removal + Nginx path filtering together is the most resilient setup.

[daneshh]

Thank you, your solutions were awesome.
My problem solved.