Home

Production Readiness

After developing your project and deciding it's Production Ready, you should run through this checklist to ensure that your project:

  • is secure
  • won't falter under the expected load
  • remains available whilst in production

Security#

  • Ensure RLS is enabled
    • Tables that do not have RLS enabled with reasonable policies allow any client to access and modify their data. This is unlikely to be what you want in the majority of cases.
    • Learn more about RLS.
  • Enable replication on tables containing sensitive data by enabling Row Level Security (RLS) and setting row security policies:
    • Go to the Authentication > Policies page in the Supabase Dashboard to enable RLS and create security policies.
    • Go to the Database > Replication page in the Supabase Dashboard to manage replication tables.
  • Enable 2FA on GitHub. Since your GitHub account gives you administrative rights to your Supabase project, you should protect it with a strong password and 2FA using a U2F key or a TOTP app.
  • Ensure email confirmations are enabled in the Auth > Settings page.
  • Use a custom SMTP server for auth emails so that your users can see that the mails are coming from a trusted domain (preferably the same domain that your app is hosted on). Grab SMTP credentials from any major email provider such as SendGrid, AWS SES, etc.
  • Think hard about how you would abuse your service as an attacker, and mitigate.
  • Review these common cybersecurity threats.

Performance#

  • Ensure that you have suitable indices to cater to your common query patterns
  • Perform load testing (preferably on a staging env)
    • Tools like k6 can simulate traffic from many different users.
  • Upgrade your database if you require more resources. If you need anything beyond what is listed, contact enterprise@supabase.io.
  • If you are expecting a surge in traffic (for a big launch) contact support with more details about your launch. We'll keep an eye on your project.

Availability#

  • Use your own SMTP credentials so that you have full control over the deliverability of your transactional auth emails (see Auth > Settings)
    • you can grab SMTP credentials from any major email provider such as SendGrid, AWS SES, etc.
    • The default rate limit for auth emails provided by Supabase is 30 new users per hour, if doing a major public announcement you will likely require more than this.
  • If your application is on the free tier and is not expected to be queried at least once every 7 days, then it may be paused by Supabase to save on server resources.
    • You can restore paused projects from the Supabase dashboard.
    • Upgrade to Pro to guarantee that your project will not be paused for inactivity.
  • Database backups are not available for download on the free tier.
    • You can set up your own backup systems using tools like pg_dump or wal-g.
    • Nightly backups for Pro tier projects are available on the Supabase dashboard for up to 7 days.
  • Upgrading to the Supabase Pro Tier will give you access to our support team.

Rate Limiting, Resource Allocation, & Abuse Prevention#

  • Supabase employs a number of safeguards against bursts of incoming traffic to prevent abuse and help maximize stability across the platform
    • If you're expecting high load events including production launches or heavy load testing, or prolonged high resource usage please give us at least 2 weeks notice. You can do this by opening a ticket via the support form.

Auth Rate Limits#

  • The table below shows the rate limit quotas on the following authentication endpoints:
EndpointPathLimited ByRate Limit
All endpoints that send emails/auth/v1/signup /auth/v1/recover /auth/v1/user1Sum of combined requestsDefaults to 30 emails per hour. Is customizable with custom SMTP set up.
All endpoints that send One-Time-Passwords (OTP)/auth/v1/otpSum of combined requestsDefaults to 30 OTPs per hour. Is customizable.
Send OTPs or magiclinks/auth/v1/otpLast requestDefaults to 60 seconds window before a new request is allowed. Is customizable.
Signup confirmation request/auth/v1/signupLast requestDefaults to 60 seconds window before a new request is allowed. Is customizable.
Password Reset Request/auth/v1/recoverLast requestDefaults to 60 seconds window before a new request is allowed. Is customizable.
Verification requests/auth/v1/verifyIP Address360 requests per hour (with bursts up to 30 requests)
Token refresh requests/auth/v1/tokenIP Address360 requests per hour (with bursts up to 30 requests)
Create or Verify an MFA challenge/auth/v1/factors/:id/challenge /auth/v1/factors/:id/verifyIP Address15 requests per minute (with bursts up to 30 requests)

Realtime Rate Limits#

Abuse Prevention#

  • Supabase provides CAPTCHA protection on the signup, sign-in and password reset endpoints. Please refer to our guide on how to protect against abuse using this method.
  • When working with enterprise systems, email scanners may scan and make a GET request to the reset password link or sign up link in your email. Since links in Supabase Auth are single use, a user who opens an email post-scan to click on a link will receive an error. To get around this problem, consider altering the email template to replace the original magic link with a link to a domain you control. The domain can present the user with a "Sign-in" button which redirect the user to the original magic link URL when clicked.

Next steps#

This checklist is always growing so be sure to check back frequently, and also feel free to suggest additions and amendments by making a PR on GitHub.

Footnotes#

  1. The rate limit is only applied on /auth/v1/user if this endpoint is called to update the user's email address.

Need some help?

Not to worry, our specialist engineers are here to help. Submit a support ticket through the Dashboard.