Can Supabase Edge Functions be isolated from project-wide privileged credentials?

[ukryln]

I'm developing a multi-tenant POS system with public order-processing functions and separate privileged device-administration operations.

Our security requirement is that compromising a public order-processing Edge Function must not allow an attacker to provision, rotate, revoke, replace or reassign devices.

According to the Supabase documentation, hosted Edge Functions automatically receive environment variables including SUPABASE_DB_URL, SUPABASE_SECRET_KEYS and the legacy SUPABASE_SERVICE_ROLE_KEY.

My questions are:

Is there a supported way to prevent a specific hosted Edge Function from accessing these privileged credentials?

Can individual functions have isolated secrets or restricted execution identities, so that arbitrary code execution within one function cannot obtain project-wide privileges?

Is this possible on a paid plan, such as Pro, Team or Enterprise?

If not, what architecture does Supabase recommend for isolating public-facing functions from privileged device-administration operations?

We've considered running public order processing in an independently hosted Deno service using a restricted PostgreSQL role, but would prefer to retain Supabase Edge Functions if secure isolation is supported.

I'm specifically asking about protection against a compromised function runtime, not merely authentication of incoming HTTP requests or Row Level Security.

Any official guidance would be appreciated.

[sandiyochristan]

Direct Answers to Your Questions

1 & 2. Can hosted Edge Functions have isolated secrets, restricted execution identities, or be prevented from receiving project-wide credentials?

No, not within a single Supabase project.
In the hosted Supabase Edge Runtime, default environment variables (SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, SUPABASE_DB_URL) and any secrets configured via supabase secrets set are project-scoped. Every Edge Function deployed to a given project shares the same ambient secret store in its worker runtime. There is currently no per-function secret masking, function-level IAM identity, or secret access control policy in the hosted Edge Runtime.

3. Is per-function credential isolation available on Pro, Team, or Enterprise?

No. While Team and Enterprise plans offer features such as dedicated compute, custom vanity domains, SOC2/HIPAA compliance, and VPC peering/Direct Connections, the Edge Function secret management model remains project-wide across all tiers.

---

Recommended Architectures for Zero-Trust / Blast-Radius Isolation

If your security requirement dictates that a compromised order-processing runtime (e.g., via Remote Code Execution or a vulnerable third-party Deno module) must have zero path to device provisioning or administrative keys, you should not rely on application-layer logic within the same project.

Here are the standard production patterns used to achieve physical blast-radius isolation:

Architecture A: Multi-Project (Dual-Project) Isolation Pattern (Recommended for Supabase)

Split your system into two isolated Supabase projects:

1. Public / Untrusted Ingestion Project (Project A - POS & Orders):
   • Hosts public endpoints and order-processing Edge Functions.
   • Has its own distinct database and service keys.
   • Contains zero credentials, zero database tables, and zero network routes to the device-administration subsystem.
2. Privileged Device Management Project (Project B - Core / Fleet Admin):
   • Manages device provisioning, rotation, revocation, and cryptographic hardware identities.
   • Strictly restricted to internal admin identities (e.g., via IP allowlists, internal VPN, or restricted Supabase Auth with MFA).
   • Functions in Project A publish events (e.g., via an async message queue like AWS SQS, a Kafka/RabbitMQ broker, or an authenticated webhook endpoint) that Project B consumes on its own terms.

Even if an attacker gains full arbitrary code execution in Project A's Edge Function and dumps Deno.env.toObject(), they only obtain credentials for the untrusted order boundary—the device fleet remains completely out of reach.

Architecture B: External Isolated Compute for Public Ingestion (AWS Lambda / Deno Subhosting / Cloudflare Workers)

If you prefer maintaining a single database but require strict runtime-level credential isolation:

• Deploy the public order-processing endpoint outside the Supabase Edge Runtime—for example, on AWS Lambda (with a dedicated IAM execution role) or Cloudflare Workers.
• Connect directly to the Supabase Postgres instance (via the Supavisor connection pooler) using a dedicated, least-privilege PostgreSQL role:

  CREATE ROLE pos_order_worker WITH LOGIN PASSWORD 'secure_worker_password';
  GRANT USAGE ON SCHEMA public TO pos_order_worker;
  GRANT SELECT, INSERT ON TABLE public.orders TO pos_order_worker;
  -- Explicitly revoke access to device administration
  REVOKE ALL ON ALL TABLES IN SCHEMA device_admin FROM pos_order_worker;

• Store only this scoped connection string in the external compute environment. Because the Supabase SUPABASE_SERVICE_ROLE_KEY is never provided to this runner, an attacker exploiting the public endpoint cannot elevate to project-wide PostgREST admin privileges.

Summary

If maintaining hosted Supabase Edge Functions is preferred, separating the untrusted ingestion workload into its own dedicated Supabase project (Architecture A) is the cleanest, most maintainable, and verifiable isolation boundary.

[ukryln]

Thank you for taking the time to explain the limitations of Supabase Edge Functions and suggest an alternative architecture.

Your recommendation to use two separate Supabase projects was particularly helpful. We've been evaluating that approach alongside external hosting, and your explanation helped us identify a much clearer path towards isolating our public-facing functions from privileged database operations.

We're now preparing a proof-of-concept to validate the security boundaries before moving forward.

Really appreciate you sharing your knowledge and pointing us in the right direction!