⌘K
Suheb Hi, I’m facing a similar issue and would appreciate any guidance. It would be helpful if the v0 team could provide a way to transfer chats between workspaces without requiring a paid team seat, while preserving the chat history and generated code. Hopefully, someone from the Vercel team can help resolve this.
Apoyoti Thank you for sharing your experience. It seems this issue affects other users as well. I hope the v0 team can provide a solution that allows us to recover and transfer our existing chats without requiring a paid seat. My main concern is preserving the development history and generated source code, as significant work has already been completed. Hopefully, someone from the Vercel team can help us resolve this.
Chintan Hi @williaamlow-beep Welcome to vercel community. Have you write query to Vercel billing team via "billing(at)vercel.com"
Amy Egan @williaamlow-beep just came across this post and wanted to make sure this is no longer a problem. Were you able to open a support case at vercel.com/help to get it solved?
MarnixB Hey, you can use Supabase or Neon database for this, both are already integrations that are connected to v0. Just ask your agent to setup authentication. You can choose for really simple auth by just using a hashed password with minimal 10x seed and save this to a simple neon db. without a real auth service. or you can choose neon/supabase and use their authentication service, just make sure that your prompt include your wished for rollbased acces. and whenever you are done with setting everything up, ask the ai to check for any rls problems or authenticated endpoints, and make sure everything that needs to be "locked" is really locked by rls or middleware auth check. if people get your supabase public url from a raw request in your app or site they can just send requests to it, and if you have wrong or none rls setup, there is a small chance that they can see all your data and sometimes write to it. thats the starting point, but enough videos that you can find online aswell about auth services.
Bryce Watson The part that matters most is where the check runs: hiding a page in the UI doesn't protect it, so every role check also has to happen on the server and in the database. Here's the setup I'd use with v0's Supabase integration: 1. Use Supabase Auth for sign-up and login instead of storing passwords yourself. If the app is Next.js, follow Supabase's server-side guide so the session is read on the server: https://supabase.com/docs/guides/auth/server-side/nextjs 2. Keep each user's role in its own table (for example `user_roles` with `user_id` and `role`), not in user metadata. Supabase's docs note that `raw_user_meta_data` can be updated by the signed-in user, so a role stored there can be changed by that user: https://supabase.com/docs/guides/database/postgres/row-level-security 3. Turn on row level security for every table the app reads and write policies that check the role. Supabase's RBAC guide shows the full pattern: a `user_roles` table, a custom access token hook that adds the role to the JWT, and an `authorize()` function your policies call. https://supabase.com/docs/guides/database/postgres/custom-claims-and-role-based-access-control-rbac 4. In the app, check the role on the server before rendering an admin page or running a server action. Don't rely on middleware or a hidden button alone, because the Supabase API can be called directly with the public key from your site. 5. Before launch, sign in as a normal user and try to open an admin URL and trigger an admin action directly. Then run the Security Advisor in the Supabase dashboard (Advisors) to catch tables without RLS: https://supabase.com/docs/guides/database/database-advisors
