Managed pg_net is non-relocatable and remains in public (extrelocatable=false)

[jonassorenz]

Context

Project team flagged a remaining Supabase security advisor finding after migration cleanup: extension_in_public for pg_net.

What we observed in production

• Extension name: pg_net
• Schema: public
• Version: 0.19.5
• extrelocatable: false

Query used:

• SELECT extname, extversion, extnamespace::regnamespace, extrelocatable FROM pg_extension WHERE extname='pg_net';

Problem

pg_net remains installed in public, and advisor flags this extension placement. We need to know if there is an official/managed-safe way to relocate pg_net to a non-public schema.

ALTER EXTENSION pg_net SET SCHEMA appears not applicable in our case (extrelocatable=false), and we want to avoid unsupported forced approaches.

Request

• Confirm if/when hosted Supabase supports moving pg_net off public.
• If supported, provide official migration sequence for hosted DBs.
• If not supported, please confirm recommended posture for this advisory (accepted exception docs/guidance).

Why this matters

For production readiness and audit evidence, this warning remains the only unresolved advisory item in a security-hardening remediations set.

[coderabbitai[bot]]

🔗 Related PRs

#46686 - Remove unexposed extensions [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Lakshya77089]

Hey — clear report, and your diagnosis is correct: extrelocatable = false means Postgres will reject ALTER EXTENSION pg_net SET SCHEMA …, so the normal one-liner doesn't apply here (same situation as PostGIS ≥ 2.3). Here's where each of your three questions lands.

First, a note on the actual exposure. extension_in_public is a WARN-level security lint, and for pg_net it's flagging the extension's registration namespace (pg_extension.extnamespace = 'public') — not where its callable objects live. pg_net always creates and uses its own net schema: net.http_get, net.http_post, and the net.http_request_queue / net._http_response tables are all in net, not public. So the practical attack surface is much smaller than an extension that genuinely exposes functions in public. Worth keeping in mind when weighing "relocate" vs. "accept exception" below.

1) Is moving pg_net off public supported on hosted?

Yes — but not via ALTER EXTENSION … SET SCHEMA (blocked by extrelocatable = false, exactly as you found). There are two supported paths (below).

One caveat specific to pg_net: it's the engine behind Database Webhooks, and it's commonly called from triggers and pg_cron jobs. A DROP EXTENSION pg_net CASCADE drops the net schema and cascade-drops everything that depends on it (webhooks, any function/trigger calling net.http_*). So treat this as a real migration, not a cosmetic move.

2) Official migration sequence (hosted)

Option A — Support-assisted (no drop; recommended for production). This is the same managed-safe procedure Supabase documents for non-relocatable extensions like PostGIS. Open a ticket at Dashboard → Support and ask them to run:

begin;
  update pg_extension set extrelocatable = true where extname = 'pg_net';
  alter extension pg_net set schema extensions;
  update pg_extension set extrelocatable = false where extname = 'pg_net';
commit;

It temporarily flips the relocatable flag, moves the extension's namespace out of public, then flips it back — no drop, no data loss, dependents stay intact. (It needs elevated privileges, which is why Support runs it.)

Option B — Self-service drop/recreate. If you'd rather do it yourself and can recreate dependents:

-- 1. Back up first (CLI: `supabase db dump`, or pg_dump).
-- 2. WARNING: this cascades — Database Webhooks and any net.http_* callers get dropped.
drop extension if exists pg_net cascade;

-- 3. Recreate outside public
create extension pg_net with schema extensions;

-- 4. Re-create the webhooks / triggers / cron jobs that called net.*

After either path, re-run the Security Advisor and the extension_in_public finding for pg_net should clear.

3) If you choose not to relocate — accepted-exception posture

This is fully supported, and given pg_net's functions already live in net (not public), it's a defensible posture for an audit. The Dashboard has a first-class mechanism:

• Go to Advisors → Security (or Advisors → Rules), find Extension in Public, and Disable the rule for the project.
• That records an exception — it stops appearing in advisor reports and is omitted from advisor email notifications — which is exactly the kind of explicit, logged "accepted exception" you can attach as audit evidence.

Net recommendation: if the audit requires zero open advisories, use Option A (Support-assisted, lowest risk). If the audit accepts documented exceptions, disable the rule and record the rationale (callable functions reside in net; WARN-level finding). I'd avoid Option B on a production project unless you've fully inventoried everything that calls net.*.

Happy to help draft the support ticket or the exception rationale if that's useful.

[harrysun2006]

Short version: on hosted Supabase you can't relocate pg_net, and this particular advisor finding is a known accepted exception — not something you're expected to fix.

extrelocatable = false means the extension declares that its objects can't be moved with ALTER EXTENSION ... SET SCHEMA, so there's no supported path to shift it out of public yourself, and forcing it (editing catalogs / dropping-recreating in another schema) is exactly the kind of unsupported surgery you're right to avoid on a managed instance.

So the recommended posture for audit purposes is:

• Treat extension_in_public for pg_net as an accepted/acknowledged exception. It's a platform-managed extension living where Supabase puts it; the advisory is flagging placement, not an actual privilege escalation you can act on. Document it as "managed extension, non-relocatable, placement controlled by Supabase" in your remediation evidence.
• Don't grant anything extra on it — pg_net's functions aren't exposed to anon/authenticated by default, so the practical exposure is nil.
• If a clean advisor report is a hard requirement, the right move is a feature request / support ask for Supabase to relocate pg_net to the extensions schema on managed instances (they've been migrating other extensions out of public over time; pg_net is one of the stragglers).

That's genuinely the correct answer here rather than a workaround — the one remaining advisory item being a non-relocatable managed extension is a defensible "accepted risk" line in a hardening review.