> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.mythos.new/integrations/supabase/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mythos.new/_mcp/server. # Managed Supabase backend > Connect a customer-owned Supabase organization for application data, authentication, storage, and server functions. Mythos can connect a Supabase organization owned by you and create a dedicated backend when your project needs one. Application data stays in that customer organization, separate from the database that runs Mythos itself. A landing page or portfolio can build, preview, and publish without a backend. Connecting an organization alone does not create a Supabase project or add database behavior to an existing form. ## Connect your organization 1. Open **Connectors → Supabase** in the dashboard, or find Supabase in your project's **More → Connectors → All connectors** catalog. 2. A workspace owner or admin authorizes the intended Supabase organization. Access and connection status are checked before continuing. 3. Ask Build for the functionality you need, such as saving enquiries or adding customer accounts. When needed, Build requests a backend in that organization. 4. After activation, **More → Cloud** opens the project's database, authentication, storage, functions, logs, and other available backend controls. The initial connection currently requires the authorized Supabase account to expose exactly one accessible organization. Mythos does not guess between multiple organizations. Reconnection must retain access to the same organization. If connection is unavailable, the catalog explains the current status; contact support if the organization cannot be confirmed. ## Review backend changes Build can prepare database migrations and server functions for your project. Review the exact SQL or function source and approve the requested action before it is applied. A successful frontend build does not mean an unapproved backend change has run. Enter private API keys only in the protected secret-input control when requested. Secrets belong in server functions, not prompts or browser code. Server functions need access checks appropriate to the action they perform. For incoming webhooks, use the connected provider's supported setup and verify who can call the endpoint; adding a URL alone does not secure it. Test the complete flow: save a record, reload it, check the intended user's access, and verify that another user cannot read private data. A visual form or sign-in screen alone is not proof that data is saved or an email is delivered. ## Build a feature with saved data Describe the records, the people using them, and the result after each action. For example: ```text Add session reservations. A signed-in customer can reserve an available session and see only their own reservations. Staff can view the session list. Show a useful error if saving fails. ``` After approving the necessary backend changes, test with a real application account. Create a record, reload the page, and open the app again. Check both the expected access and the access that should be denied. The Cloud view helps you inspect the backend: | Area | What to inspect | | -------------------------- | ----------------------------------------------------------- | | **Database** | Tables, stored records, and row-level security policies | | **Users** | Application accounts, separate from your Mythos team | | **Storage** | Buckets and uploaded files | | **Functions** and **Logs** | Server behavior and errors from the feature you are testing | ## Row-level security Row-level security, or RLS, decides which database rows an application user may read or change. A private screen or hidden button is not an access rule: the backend must enforce the same boundary. Open **Cloud → Database → RLS policies** to inspect the policies for a table. The view shows the operation, roles, and policy conditions. Use those details to ask Mythos for a focused change. Describe access in terms of the people and data in your app: ```text Customers should only read and cancel their own reservations. Staff may read all reservations but must not change a customer's identity. Review the database rules for those actions. ``` A table's permissions and its row policies work together. If an expected read or write fails, ask Mythos to examine both rather than removing RLS. Review the proposed change and test with the owner of a record, a different customer, and a signed-out visitor. Use [Project security](/features/project-security) to review available database findings alongside the app's code. A scan supplements testing; a successful page load alone does not prove private data is protected. For background, see [PostgreSQL row security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) and [Supabase RLS](https://supabase.com/docs/guides/database/postgres/row-level-security). ## Storage policies Storage policies control access to uploaded files. Open **Cloud → Storage → RLS policies** to inspect the rules on `storage.objects`. Uploading, reading, replacing, and deleting are distinct actions; allowing an upload does not automatically allow a later replacement. Choose visibility based on the files. Product photos may be public; customer documents should be restricted to the people who need them. A public bucket makes its files publicly accessible, so do not use it as a shortcut around a failed private download. ```text Let a customer upload a document for their own reservation. Only that customer and staff may read it. Another customer must not be able to list or download it. ``` Test the whole flow: upload, reopen, replace if supported, and delete. Then try the same file with a different account. If one step fails, include the exact action and message when asking Mythos to review the policy. See [Supabase Storage access control](https://supabase.com/docs/guides/storage/security/access-control) for the underlying rules. ## Give someone access to your application Application accounts are separate from the people invited to your Mythos workspace. Ask Build to give your verified Mythos email the role your app uses. If you do not yet have an application account, the confirmation card lets you choose a private password and create your own sign-in with that role. For another person, first create their application account through your app's sign-up flow or **Cloud → Users**, then ask Build to assign their role. For example: “Give [alex@example.com](mailto:alex@example.com) staff access to the enquiries inbox.” Build checks the existing access rules and can prepare a confirmation for one account when the app uses the server-managed `app_metadata.role` field. Review the account, backend, and requested role, then choose **Assign role**. The account may need to sign in again to receive updated access. You can also ask Build to remove that role. A public sign-up never grants staff access by itself. Creating your own sign-in confirms your already verified email for that app. Changing an existing account's role never resets its password or confirms its email. Enter passwords only in the private card, never in chat. If the result is uncertain, use **Check status**; Mythos will not repeat account creation automatically. This action does not create other people's accounts, send invitations, or change a separate roles table. If your app uses another access model, Build must work with that model. Adding a staff area or setting up email is a separate request; connecting Supabase does not add either automatically. ## Reconnect or disconnect If the workspace connection needs attention, open **Connectors → Supabase** and choose **Reconnect Supabase**. Reconnection must restore access to the same organization. Use **Check connection** if the current result is uncertain, and read the status before retrying. Disconnecting revokes the Mythos authorization for the Supabase account used for the connection. It may also disconnect that account's other Mythos workspaces. Only the person who authorized the connection can confirm the action, with the required workspace permissions. Review this effect before choosing **Disconnect**. Supabase projects and data are not deleted, but Mythos can no longer manage them through that authorization. If a previous authorization needs cleanup, follow the confirmation shown on the connector page; contact support when its outcome cannot be confirmed. ## Ownership and costs Your Supabase organization owns the backend project and its data. Supabase charges, plan limits, backups, and provider billing belong to that organization. Mythos does not automatically upgrade a plan, purchase add-ons, or transfer, pause, or delete your Supabase project. Resolve provider quota or billing actions in your Supabase account when the connection asks for them. Downloading source or restoring a code version does not restore database rows, uploaded files, or provider configuration. Keep the backups your application needs. ## Existing Supabase projects Retiring the former bring-your-own connection does not delete or change an external Supabase organization, project, database, user, file, or function. Manage those resources directly in your Supabase account. An already-connected legacy project can keep using its stored public project URL, anon key, and frontend scaffold. The old OAuth, project picker, and provisioning path remain retired; managed organization access is a separate connection and does not take over a legacy backend automatically. If you need help with a previous Mythos connection, contact support; do not send credentials. ## Related * [Connect your tools](/integrations/introduction) — distinguish Build tools from published-app integrations. * [Connect GitHub](/integrations/github) — keep the project in a repository you control. * [Troubleshooting](/reference/troubleshooting) — diagnose a project without exposing secrets. > Learn how to turn an idea into a working app, improve it in Mythos, and publish it when it is ready.