RLS policies

What is copied

SupaClone copies Row Level Security state and policy definitions for cloneable application schemas.

This includes:

• Whether RLS is enabled on a table.
• Policy names.
• Policy commands such as SELECT, INSERT, UPDATE, DELETE, and ALL.
• Permissive or restrictive policy mode.
• Policy roles.
• USING expressions.
• WITH CHECK expressions.

Why policy review still matters

RLS policies often reference functions, roles, JWT claims, Auth users, or Storage paths. SupaClone can copy the policy definition, but you should still verify that the target environment has the same assumptions.

Review policies that reference:

• auth.uid()
• auth.jwt()
• Custom roles.
• Project-specific IDs.
• Schema-qualified helper functions.
• Auth users or teams that do not exist in the target.
• Storage object paths.

Storage policies

Storage policies live on Supabase-managed tables such as storage.objects and storage.buckets. SupaClone handles them separately from normal application-schema policies when Storage cloning is selected.

If a Storage policy cannot be created on the target, SupaClone records a manual step instead of treating the entire clone as successful.

Post-clone checks

After cloning a protected app, test representative users against the target:

• Anonymous visitor.
• Authenticated user with normal privileges.
• User who owns rows.
• Admin or service workflow.
• Any role that should be denied.

The safest RLS verification is still application-level behavior testing.