Files
supabase/apps/docs
Arshdeep SinghandJeremias Menichelli e478aabb80 Clarify pg_net net schema grants (#49472)
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

Yes

## What kind of change does this PR introduce?

Documentation update — adds a new "Permissions" section to the pg_net
guide.

## What is the current behavior?

The pg_net docs don't explain the default permission model for the net
schema. Customers running security reviews flag that net schema objects
(net.http_request_queue, net._http_response) are readable by
anon/authenticated via inherited PUBLIC grants, and some have run their
own REVOKE scripts to lock this down. This breaks the pg_net background
worker, since postgres (the role the worker runs as) inherits its own
access through that same PUBLIC grant.

## What is the new behavior?

Adds a "Permissions" section clarifying that the default grants are safe
as-is, net isn't exposed through the Data API, and anon/authenticated
are NOLOGIN roles with no direct database connection.

## Additional context

For background and reviewer discussion on the accuracy of this, see the
https://supabase.slack.com/archives/C02FHG9QQAF/p1787299415288589.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
  * Added permissions guidance for the `net` schema.
  * Clarified access available to `anon` and `authenticated` roles.
* Explained why these permissions do not expose request data through the
Data API or direct database connections.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com>
2026-08-24 17:29:48 +05:30
..
2026-07-01 12:59:00 +02:00
2026-07-08 12:30:42 +10:00

Reference Docs

Supabase Reference Docs

Maintainers

If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.

DocSpec

We use documentation specifications which can be used to generate human-readable docs.

  • OpenAPI: for documenting API endpoints.
  • SDKSpec (custom to Supabase): for SDKs and client libraries.
  • ConfigSpec (custom to Supabase): for configuration options.
  • CLISpec (custom to Supabase): for CLI commands and usage.

The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.

Contributing

To contribute to docs, see the developers' guide and contributing guide.