Configure HTTPS, OAuth, and Backups for Self-Hosted Supabase

If you run your own backend, deploying Supabase is just step one. The real work starts when you need to configure HTTPS, point a real domain, configure OAuth self-hosted Supabase to work with providers like Google or GitHub, and put a backup plan in place so you do not lose user data. This guide covers all of that.

If you haven't set up Supabase yet, you can check this guide on Self-hosting Supabase with Docker Compose and then follow the steps below to handle HTTPS, OAuth, and backups.

Before you configure OAuth self-hosted Supabase, make sure you have all of this ready:

• A Linux server running Ubuntu 22.04 or newer with Docker and Docker Compose installed.
• A domain name with an A record pointing to your server's public IP.
• Ports 80 and 443 are open in your firewall.
• Your Supabase Docker stack is pulled and ready in a folder, for example, /opt/supabase.

For a stable setup, your server should have at least 4 GB of RAM and fast disks. Running Supabase, PostgreSQL, GoTrue Auth, and Kong on a shared VPS can cause bottlenecks under real traffic. A reliable dedicated server gives you full CPU and RAM resources with no noisy neighbors, making it a good choice once you move to production.

You must point your domain to the server before anything else. Go to your domain registrar's DNS panel and create an A record:

Wait a few minutes, then verify it works:

You should see your server IP in the output. Do not move forward until DNS resolves correctly; Caddy and Certbot both need it to issue an SSL certificate.

A simple domain registration service like PerLod lets you search, buy, and manage DNS records in one place, which makes the rest of this guide easier to follow.

You can easily configure HTTPS with Caddy and Nginx. Here we will show you both options:

Supabase ships with a ready-made Caddy override file. Caddy automatically handles Let's Encrypt certificates, renewals, HTTPS redirects, and WebSocket upgrades with zero extra config.

First, you must update your .env file and edit the URL variables to use HTTPS and your real domain:

Change these three lines:

Then, start Caddy with Docker Compose:

Caddy reads the Caddyfile in volumes/proxy/caddy/ and automatically issues a certificate for your domain.

Verify HTTPS is working:

A 401 response is expected and correct here. It means HTTPS is working and the Auth service is responding.

If you prefer Nginx over Caddy, you can use this method instead. First, set Nginx-specific variables in the .env file:

Start with the Nginx override:

Verify it is working correctly:

When you configure OAuth self-hosted Supabase, you need three things: a correct callback URL registered with the provider, the right .env values, and the matching passthrough lines in docker-compose.yml.

First, create a Google OAuth app:

• Go to Google Cloud Console.
• Create or select a project.
• Go to APIs & Services → OAuth consent screen → click Get started → set app type to External.
• Go to APIs & Services → Credentials → Create Credentials → OAuth client ID.
• Set application type to Web application.
• Under Authorized redirect URIs, add exactly:
  • https://api.yourdomain.com/auth/v1/callback
• Click Create and copy your Client ID and Client Secret.

Then, add the credentials to the .env file:

Uncomment or add these lines:

You must also enable in docker-compose.yml:

Find the auth: service block and uncomment or add these environment lines:

Restart only the auth container:

Verify Google is enabled:

You should see:

The pattern to configure OAuth self-hosted Supabase is the same for every provider. Here is GitHub as a second example.

First, create a GitHub OAuth app:

• Go to GitHub → Settings → Developer settings → OAuth Apps → New OAuth App.
• Set Homepage URL: https://api.yourdomain.com.
• Set Authorization callback URL: https://api.yourdomain.com/auth/v1/callback.
• Click Register application and copy your Client ID and Client Secret.

Add to .env file:

Add to docker-compose.yml:

Restart auth:

The same four steps work for every provider in the table below, just swap the prefix:

For a complete list of provider-specific environment variables and the latest examples, you can also check the official Supabase guide.

After login, Supabase redirects users back to your frontend. If your app lives on a different domain, for example, https://app.yourdomain.com, you must explicitly allow it.

In .env, add:

Then restart the auth service:

Without this, users will hit a redirect error right after a successful OAuth login, one of the most common mistakes when you configure OAuth self-hosted Supabase.

When you configure OAuth self-hosted Supabase for the first time, these are the mistakes that show up most often:

The callback URL in your OAuth app uses http:// but your server runs on https://. Most providers reject HTTP callbacks. Always use HTTPS when you configure OAuth self-hosted Supabase for any provider.

Some people register https://api.yourdomain.com/callback instead of https://api.yourdomain.com/auth/v1/callback. The /auth/v1/callback path is required; do not shorten it.

The .env values are not automatically available inside containers. They must have a matching GOTRUE_EXTERNAL_* line in docker-compose.yml. Check what the auth container actually sees:

After OAuth finishes, GoTrue redirects to SITE_URL. If it is blank or points to localhost in production, users land on the wrong page.

Run this to confirm the variable reached the container:

If nothing shows, your passthrough line in docker-compose.yml is missing or commented out.

Once you configure OAuth self-hosted Supabase and real users start signing in, you need a backup plan. All user accounts, tokens, and data live in PostgreSQL. Losing the database means losing everything.

1. Manual backup with pg_dump:

2. Create a backup directory:

3. Automate with a daily cron job:

Add this line to run a backup every day at 2 AM:

4. Remove backups older than 7 days: Add this line to the same crontab to keep disk usage under control:

5. Copy backups off-server, for example, with rsync: Do not store all backups on the same machine. Push them to a remote server or object storage:

6. Restore from a backup:

Your .env and docker-compose.yml files are just as important as the database. If your server dies, you need them to rebuild it.

Or push them to a private Git repository without secrets inside, use a secret manager, or environment injection in production.

If login breaks or something is off, always start with the logs:

For Nginx or Caddy proxy errors:

You can run a quick HTML test page to confirm everything works once you configure OAuth self-hosted Supabase. Create a test HTML file:

Then, serve it locally:

Open http://localhost:3000/oauth-test.html in your browser. Click the button. If you land back on the page logged in, your setup is working.

Getting HTTPS, a real domain, and working social logins on a self-hosted Supabase instance requires getting each piece right in order. The most common failures when people configure OAuth self-hosted Supabase include HTTP vs HTTPS mismatches, the wrong callback URL, and missing passthrough lines in docker-compose.yml. Follow the steps above and check the logs when something breaks.

We hope you enjoy this guide.