Supascale
Sign Up

Wildcard SSL Certificates for Self-Hosted Supabase Multi-Project Setups

Learn how to set up wildcard SSL certificates with Let's Encrypt for self-hosted Supabase, enabling secure HTTPS across unlimited projects.

Cover Image for Wildcard SSL Certificates for Self-Hosted Supabase Multi-Project Setups

Running multiple self-hosted Supabase projects on a single server quickly turns SSL certificate management into a headache. Instead of provisioning individual certificates for each project subdomain, wildcard certificates offer a cleaner solution. This guide walks you through setting up wildcard SSL certificates using Let's Encrypt for your self-hosted Supabase infrastructure, covering DNS validation, reverse proxy configuration, and automated renewal.

Why Wildcard Certificates Matter for Multi-Project Setups

When you're running multiple Supabase projects—say project1.supabase.yourdomain.com, project2.supabase.yourdomain.com, and so on—you have two certificate strategies:

Individual certificates per project:

  • Requires separate certificate requests and renewals
  • More complex automation as projects scale
  • Let's Encrypt rate limits can become problematic (50 certificates per registered domain per week)

Single wildcard certificate (*.supabase.yourdomain.com):

  • One certificate covers all current and future subdomains
  • Simpler renewal automation
  • Centralized certificate management
  • No rate limit concerns when adding new projects

The trade-off? Wildcard certificates require DNS-01 validation, meaning you need programmatic access to your DNS provider. HTTP-01 validation—the simpler method—doesn't work for wildcards.

Prerequisites

Before starting, ensure you have:

  • A domain with DNS hosted on a provider with API access (Cloudflare, AWS Route53, DigitalOcean, or similar)
  • A server meeting the Supabase system requirements
  • Supabase deployed via Docker Compose (see our deployment guide)
  • A reverse proxy (Nginx, Traefik, or Caddy) configured for your setup

Step 1: Install Certbot with DNS Plugin

Certbot is the recommended client for Let's Encrypt. For wildcard certificates, you need both Certbot and a DNS plugin matching your provider.

# Install Certbot via Snap (recommended for latest version)
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Install DNS plugin for your provider
# For Cloudflare:
sudo snap install certbot-dns-cloudflare

# For AWS Route53:
sudo snap install certbot-dns-route53

# For DigitalOcean:
sudo snap install certbot-dns-digitalocean

As of 2026, Let's Encrypt and Certbot 5.x have improved significantly. The snap installation ensures you're running the latest version with critical ACME compliance updates.

Step 2: Configure DNS Provider Credentials

Each DNS plugin requires API credentials. Store these securely—never commit them to version control.

Cloudflare Configuration

Create a credentials file at /etc/letsencrypt/cloudflare.ini:

# Cloudflare API token (recommended over Global API Key)
dns_cloudflare_api_token = your_api_token_here

Set restrictive permissions:

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

When creating a Cloudflare API token, grant only the minimum permissions needed:

  • Zone:DNS:Edit for your specific zone
  • Zone:Zone:Read for your specific zone

AWS Route53 Configuration

For Route53, configure AWS credentials in /root/.aws/credentials:

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

Or use IAM roles if running on EC2.

Step 3: Request the Wildcard Certificate

Now request your wildcard certificate. The DNS-01 challenge will automatically create and verify a TXT record at _acme-challenge.supabase.yourdomain.com.

# For Cloudflare
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.supabase.yourdomain.com" \
  -d "supabase.yourdomain.com" \
  --agree-tos \
  --email [email protected]

# For AWS Route53
sudo certbot certonly \
  --dns-route53 \
  -d "*.supabase.yourdomain.com" \
  -d "supabase.yourdomain.com" \
  --agree-tos \
  --email [email protected]

Notice we're requesting both *.supabase.yourdomain.com and supabase.yourdomain.com. The wildcard only covers subdomains, not the base subdomain itself.

Successful output looks like:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/supabase.yourdomain.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/supabase.yourdomain.com/privkey.pem

Step 4: Configure Your Reverse Proxy

With the certificate in place, configure your reverse proxy to use it and route traffic to your Supabase projects.

Nginx Configuration

Create a configuration file for your Supabase projects:

# /etc/nginx/sites-available/supabase-wildcard

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name *.supabase.yourdomain.com supabase.yourdomain.com;
    return 301 https://$host$request_uri;
}

# Project 1
server {
    listen 443 ssl http2;
    server_name project1.supabase.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/supabase.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/supabase.yourdomain.com/privkey.pem;
    
    # Modern SSL configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    location / {
        proxy_pass http://localhost:8001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
    }
}

# Project 2
server {
    listen 443 ssl http2;
    server_name project2.supabase.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/supabase.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/supabase.yourdomain.com/privkey.pem;
    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    location / {
        proxy_pass http://localhost:8002;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
    }
}

Enable the configuration and reload:

sudo ln -s /etc/nginx/sites-available/supabase-wildcard /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Traefik Configuration

If you're using Traefik (common with Docker setups), configure it to use the Let's Encrypt certificate:

# traefik.yml
certificatesResolvers:
  letsencrypt:
    acme:
      email: [email protected]
      storage: /letsencrypt/acme.json
      dnsChallenge:
        provider: cloudflare
        resolvers:
          - "1.1.1.1:53"
          - "8.8.8.8:53"

For more details on reverse proxy configuration, check our comprehensive reverse proxy setup guide.

Step 5: Update Supabase Environment Variables

Each Supabase project needs its environment variables updated to reflect the HTTPS endpoints. In your .env file:

# Project 1 environment variables
SITE_URL=https://project1.supabase.yourdomain.com
API_EXTERNAL_URL=https://project1.supabase.yourdomain.com
SUPABASE_PUBLIC_URL=https://project1.supabase.yourdomain.com

Restart your Supabase services after updating:

docker compose down && docker compose up -d

For a complete reference of environment variables, see our environment variables guide.

Step 6: Set Up Automatic Renewal

Let's Encrypt certificates expire every 90 days. Certbot creates a systemd timer for automatic renewal, but you need to ensure your reverse proxy reloads after renewal.

Create a renewal hook script at /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh:

#!/bin/bash
systemctl reload nginx

Make it executable:

sudo chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh

Test the renewal process:

sudo certbot renew --dry-run

For production environments, with the industry potentially moving toward shorter certificate lifetimes, mastering automated DNS challenge renewal is essential.

Adding New Projects

The beauty of wildcard certificates is adding new projects requires zero certificate changes:

  1. Deploy a new Supabase instance on a different port (e.g., localhost:8003)
  2. Add DNS record: project3.supabase.yourdomain.com → your server IP
  3. Add a new server block in Nginx (or Traefik configuration)
  4. Reload your reverse proxy

That's it. The existing wildcard certificate automatically covers the new subdomain.

For guidance on managing multiple projects, see our guide on managing multiple Supabase projects.

Security Considerations

Wildcard certificates come with security trade-offs worth understanding:

Private key exposure scope: If your wildcard certificate's private key is compromised, all subdomains under that wildcard are affected. With individual certificates, exposure is limited to one subdomain.

Mitigation strategies:

  • Store private keys with restrictive permissions (chmod 600)
  • Use separate certificates for production vs. staging environments
  • Consider Certificate Transparency monitoring for your domain
  • Implement key rotation policies

For comprehensive security hardening, review our production hardening guide.

Troubleshooting Common Issues

DNS Propagation Delays

DNS-01 challenges can fail if TXT records haven't propagated. The --dns-cloudflare-propagation-seconds flag (or equivalent for other plugins) helps:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d "*.supabase.yourdomain.com"

Rate Limits

Let's Encrypt has rate limits. For testing, use the staging environment:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.supabase.yourdomain.com" \
  --staging

Remove --staging for production certificates.

Certificate Not Trusted

If browsers show certificate warnings, verify:

  • You're using fullchain.pem (not just cert.pem)
  • Your server clock is synchronized (NTP configured)
  • The domain matches the certificate's Subject Alternative Names

How Supascale Simplifies This

While manual wildcard certificate setup works, it adds operational overhead—especially when managing multiple projects across different servers.

Supascale handles SSL certificate management automatically:

  • Automatic Let's Encrypt provisioning for custom domains
  • Free SSL certificates included with all projects
  • One-click domain binding through the UI
  • Automatic certificate renewal without manual intervention

With Supascale's one-time purchase model, you get unlimited projects with automated SSL—no more wrestling with Certbot configurations or renewal scripts.

Conclusion

Wildcard SSL certificates are the practical choice for self-hosted Supabase deployments running multiple projects. The DNS-01 challenge requirement adds initial complexity, but the payoff—centralized certificate management and seamless project scaling—is worth it.

Key takeaways:

  • Use wildcard certificates when running 3+ projects on the same base domain
  • Automate DNS validation with provider-specific Certbot plugins
  • Set up renewal hooks to reload your reverse proxy
  • Secure your private keys and consider the blast radius of key compromise

For teams who want the multi-project flexibility without the certificate management burden, Supascale offers automated SSL as part of its self-hosted Supabase platform.

Further Reading