πŸ“£ Improved Supabase setup + AI-assisted workflow debugging

Hey everyone :waving_hand:

This release brings an improved Supabase setup, AI-powered testing and troubleshooting for backend workflows, easier-to-read JavaScript bindings, and more!

Check out the details :backhand_index_pointing_down:

:locked_with_key: Control page access with Supabase roles

Previously, setting up role-based page access with Supabase required building the full workflow manually.

A new workflow template now gives you a ready-made structure to protect pages based on a user’s Supabase role.

Go to Page Triggers, create a new workflow, then select Supabase β†’ Role-Based Page Access:

The workflow can:

:white_check_mark: Retrieve the user’s role

:white_check_mark: Check if a user is authenticated

:white_check_mark: Redirect unauthenticated users

:white_check_mark: Control access to protected pages

:robot: Build and fix backend workflows with AI

WeWeb AI and MCP-connected AI tools can now test the backend workflows they build, review the execution logs, and verify the result.

You can also use them to troubleshoot an existing workflow by asking them to inspect the logs, identify the cause of an error, and suggest a fix.

Example prompt: Review the workflow logs, identify what caused the issue, and suggest how to fix it

:green_circle: Choose how Supabase works with your app

When setting up Supabase for the first time, it’s now easier to choose how you want to use it:

Use Supabase as a data source if you want WeWeb Server to handle your API endpoints, backend workflows, and access control.

:white_check_mark: Useful when you want to combine Supabase with other data sources or manage more of your backend logic in WeWeb.

Use Supabase as your backend if you want your app to connect directly to Supabase and manage data access with Row Level Security.

:white_check_mark: A good fit when your app already relies on Supabase-native features such as RLS policies, database functions, or other backend logic configured in Supabase:

Your choice is saved as the project default, but you can still change it for individual tables or update the default later:

:abacus: Read JavaScript bindings more easily

Previously, JavaScript bindings could show technical references that made it difficult to tell which table view, variable, or element was being used.

Now, JavaScript bindings are easier to understand, with clearer table previews and more readable references to the data and elements used in your app:

:hammer_and_wrench: Other improvements and fixes

  • Supabase table views: Fixed deep filtering on nested joined data
  • Supabase connections: Fixed connection errors in the Supabase integration
  • Xano connections: Fixed environment connection errors and fallback behavior
  • Table filters: Parameters containing dashes, spaces, or other special characters now work correctly
  • Supabase password updates: The Update User action now supports the current password when required by Supabase
  • Production data previews: Data now loads from the connection configured for the selected environment, rather than defaulting to editor data

That’s all for this release! As always, let us know what you think :slightly_smiling_face:

Hey, great changes and it looks like MCP can now see collections properly which is fantastic (although not listed so maybe this always worked?) but could we get a heads-up when these are being rolled out? Had a mcp session fail halfway because of a mid run tool schema change that deprecated tools without notice.

Thanks for the continued improvements!

Thanks so much for the Supabase page role access!

We had built a different solution for this already but we are at a stage where we might be better to undo that and use this instead.