URGENT: Existing Supabase organisation/project disappeared — SU-475662 unanswered for 2+ weeks

[safshargh]

Hi Supabase community,
I’m hoping someone from the community or Supabase team can help point me in the right direction.

My existing Supabase organisation and project disappeared from my dashboard after Supabase appears to have automatically created a new profile during GitHub sign-in on 15 September.

I did not knowingly create a second Supabase profile or organisation.

I can successfully authenticate with the correct GitHub account, but the dashboard now shows an empty organisation list and asks me to create a new organisation.

The existing application/backend is still operational.

Details

• Support ticket: SU-475662
• Organisation: JourneyJournal
• Project: Journey Journal App
• Project ref: gcalmpaujshxqrhjdboe
• GitHub user: safshargh
  I have already provided Supabase Support with the project reference, identity details, screenshots, and the audit-log event showing:
• Creates user's profile
• 15 Sep 2026 at 14:45:42 (+08:00)
• Route: /platform/profile
• Status: 201

I have specifically asked Support to re-associate/re-map the existing project and organisation to my current account.
Unfortunately, SU-475662 has now been open for nearly two weeks without a substantive response, and this is actively holding up development of my application.

I’ve also tried the dashboard support form, but it cannot be submitted because it requires me to select the organisation that has disappeared.
Has anyone else experienced this exact account/organisation-mapping issue and had it resolved?

If any Supabase moderator or team member can help get SU-475662 in front of the appropriate account/platform team, I would be extremely grateful.

I can provide any ownership verification privately to Supabase Support.
Thanks,
Saba

[BryceEWatson]

I read your comments in #50475, so I'll skip the diagnosis and ticket tips. Here's what I'd try while the ticket's open, plus one risk to watch:

1. Try "Continue with ChatGPT" on the Supabase sign-in page, with a ChatGPT account on the email address your old account used (the one Supabase's project emails go to). Supabase's announcement of ChatGPT sign-in says it links to an existing account with the same email instead of creating a new one. It got someone with a similar lockout back into their organization, though it didn't work for the original poster in Project missing from dashboard — "Not a member of the selected organization" #50475. If it lands you in another empty dashboard, add that to your ticket.
2. If your computer or CI still has a Supabase CLI login from before Sept 15 (a SUPABASE_ACCESS_TOKEN secret in GitHub Actions, for example), run supabase projects list with it. Don't run supabase login first, since that replaces the saved token with one for your new account. The old token belongs to the old account, so if it lists the project, you can supabase link to it and keep deploying through the CLI while the ticket's open.
3. I know you'd rather not make changes, but a backup won't touch your tables or your Auth, RLS or Storage setup. It needs the Supabase CLI and Docker. The backup and restore guide has the three supabase db dump commands to run with your connection string. If the token from step 2 works, you don't need the database password: after supabase link, run the same commands without --db-url, and the CLI has Supabase create a temporary database login for the dump. Keep data.sql out of Git, since it includes your users' auth records (emails and any password hashes).
4. If the project's on the Free plan, keep some real traffic on it. Supabase pauses Free projects after a week of low activity, and the docs only cover resuming from the dashboard you can't reach right now.

[safshargh]

Thanks Bryce — I’ve now tested the Continue with ChatGPT path using the same safshar@gmail.com email.
Supabase successfully linked ChatGPT as an additional sign-in method to the same current Supabase profile alongside GitHub, and the audit log only shows “Logged into account” — it did not create another user profile.
Unfortunately, the dashboard is still empty and the existing JourneyJournal organisation/project is still missing.
So it looks like authentication itself is working correctly, but the organisation/project association is still broken.
Your CLI token suggestion sounds like the next useful diagnostic. I’m happy to check for an old saved Supabase token, but I want to make sure I don’t overwrite anything or accidentally log into the new/empty profile.
If you can confirm the safest read-only steps to check whether an old token still exists and whether it can still see project gcalmpaujshxqrhjdboe, I’ll try that next.

Thanks again for the help.

[BryceEWatson]

These steps only read. Don't run supabase login (it replaces the saved token) or supabase logout (it deletes it).

1. On each computer you've used the CLI on, run supabase projects list (or npx supabase projects list). If it says "Access token not provided", there's no saved login there. If it says "Cannot find project ref. Have you run supabase link?", ignore that and don't link. If gcalmpaujshxqrhjdboe shows up under REFERENCE ID, that token still reaches the old organization, and its ORG ID is the ID you didn't have for the ticket. An empty list probably means that login belongs to the new profile. If you've ever set SUPABASE_ACCESS_TOKEN in your shell, the CLI uses that first.
2. Check anywhere a deploy might keep a token, such as a SUPABASE_ACCESS_TOKEN secret in GitHub Actions. GitHub won't show its value, but if a run that used it succeeded after Sept 15, the token worked then. Only look at past runs, since re-running one would deploy again.
3. If you find a token outside the CLI (it starts with sbp_), you can test it without it being saved anywhere. On macOS or Linux, paste the token after the first line (it won't show):

   read -rs SUPABASE_ACCESS_TOKEN && export SUPABASE_ACCESS_TOKEN
   supabase projects list
   unset SUPABASE_ACCESS_TOKEN
   

   In PowerShell:

   $env:SUPABASE_ACCESS_TOKEN = Read-Host "Paste token"
   supabase projects list
   Remove-Item Env:SUPABASE_ACCESS_TOKEN
   

Please don't post a token here. If one works, tell Support that an old token still sees the project, and keep the token itself private. I'd also add the ChatGPT result to your ticket: it shows your email signs in to the new profile, so the old organization is either under a different login or detached on Supabase's side.

[GaryAustin1]

Accounts are associated with email not by Github account. If the project is running then it is in an account with another email OR in Lovable/Bolt/Vercel and not available from the SB dashboard.

Check your email history to confirm the exact email notices where being sent to. If you have CLI or Management API access still there are commands to show the org email members.

Do you have teammates on the org? If so and one is owner they could also have removed you.

[safshargh]

Thanks Gary. There are no teammates/other owners on the JourneyJournal organisation who could have removed me.
I’ll check the historic Supabase emails to confirm exactly which email identity the original project was associated with.
I’m also going to verify in Lovable whether the current backend is explicitly shown as a connected Supabase project versus Lovable Cloud, and then run the read-only CLI projects list check suggested above if needed.
One thing that still concerns me is that my Supabase audit log shows Creates user's profile on 15 September immediately before the original organisation disappeared, while my current safshar@gmail.com profile now accepts both GitHub and ChatGPT authentication but still shows no organisations.
I’ll report back with the email/backend/CLI results.

[safshargh]

hi @GaryAustin1 - I’ve now checked the backend directly in Lovable.
Journey Journal is explicitly shown as Supabase – Connected, with project Journey Journal App, and Lovable provides direct links to Manage Users, SQL Editor, Edge Functions and Manage Secrets.
So this does appear to be an existing directly connected Supabase project rather than Lovable Cloud/Bolt/Vercel hosting the backend independently.
The project is still functioning through Lovable, but my Supabase dashboard continues to show no organisations/projects.
I’ll now check historic Supabase emails and then do the read-only CLI projects list test suggested by Bryce to see whether an old access token can still see project gcalmpaujshxqrhjdboe.

[GaryAustin1]

If lovable cloud there won't be a supabase dashboard for it. If you signed in with github 2 weeks ago it would create a new empty supabase account with the primary email from github. You can check the email the account is using in account settings under your user icon top right, but with chatGPT logging into same one I'll assume that is the email for THIS account. So the org/project is in another email linked account or is Lovable cloud and there is no supabase.com access.

I can also file this in an informal queue as a lost ticket, but these almost always end up being in wrong account.

[safshargh]

Thanks Gary — yes please, I would really appreciate it if you could put SU-475662 into that informal lost-ticket queue.
I’ve now found another important piece of evidence:

• safshar@gmail.com has no Supabase emails at all prior to 15 September
• at 2:45 PM on 15 September, that email received a “Welcome to Supabase” message telling me to create my first project
• at essentially the same time, the Supabase audit log recorded “Creates user’s profile”
  So I agree it now looks very possible that the GitHub sign-in created a new empty Supabase account under safshar@gmail.com, while the existing JourneyJournal organisation/project remains attached to another identity.
  The live project is definitely still connected in Lovable as Supabase → Journey Journal App, and the project ref is:
  gcalmpaujshxqrhjdboe
  I’m now checking my other email accounts for historic Supabase correspondence to identify the original account email.

If you’re able to bump SU-475662 into the lost-ticket queue in the meantime, I’d really appreciate it.

Also, if the Supabase team can locate the owning account/email from the project ref, that would probably resolve this much faster.
Thanks again so much for your help!

[safshargh]

Hi Gary, quick update that I’ve now checked all email addresses I could possibly have used for Journey Journal, including my personal and Journey Journal accounts.

So unfortunately I can’t identify another historic email/account from my side.

At this point, I think Supabase will need to use the project ref internally to identify which organisation/account currently owns it and restore/reassociate my access.

Yes please — I would really appreciate you putting support ticket SU-475662 into the informal lost-ticket queue.

This has now been unresolved for over two weeks and is continuing to hold up development of the application.

Thanks again for helping with this!!

[safshargh]

@GaryAustin1 Hi Gary — quick update: I found the original Supabase account.
I feel pretty stupid now because I’d completely forgotten that I originally created the Journey Journal Supabase account under journeyjournalhub@outlook.com back in August.

So you were right — the GitHub sign-in under safshar@gmail.com had simply created a separate empty Supabase profile, while the real project was sitting under the original Outlook account the whole time.

Sorry for taking up your time with this, and thank you for sticking with me and pointing me toward checking the original email identity. That ultimately led me to the answer.

Really appreciate your help, but you helped me get there in the end..

[supertj]

Can't help with the account mapping itself, only Supabase can fix that. But while you wait: the project is still running, so if you have the database connection string anywhere (.env, Prisma/Drizzle config, a server secret), take a dump now so you're not depending on getting dashboard access back.

pg_dump "postgresql://..." -Fc -n public -f journey.dump

Use a pg_dump version at least as new as your project's Postgres. Also heads up if you go the CLI route: supabase db dump gives you schema only unless you add --data-only, which catches a lot of people.

That dump won't have your Storage files, only the storage.objects rows. The actual uploads need the Storage S3 keys (Storage → Settings) plus something like rclone, so that one has to wait until you're back in the dashboard.