Deleting the last super admin account prevents re-initialization via /admin/signup

[samssj10]

Describe the bug

When the last super admin deletes their own account via Personal Settings → "Delete my account", the super_admin table's initialized flag remains true. This causes the /admin/signup page to permanently redirect to /login, making it impossible to create a new admin account and leaving the instance in an unrecoverable state without direct database intervention.

To Reproduce

Steps to reproduce the behavior:

1. Set up a fresh Infisical instance and complete the admin signup at /admin/signup
2. Log in as the admin
3. Go to Personal Settings → Danger Zone
4. Click "Delete my account" and confirm
5. Try to visit /admin/signup to create a new admin

Expected behavior

After the last super admin deletes their account, the instance should reset to an uninitialized state, allowing a new admin to be created at /admin/signup.

Screenshots

Not required

Platform you are having the issue on:

Self-hosted (Docker / docker-compose)

Additional context

The root cause is in backend/src/services/user/user-service.ts — the deleteUser() function deletes the user row but never checks whether any super admins remain, and never resets initialized in the super_admin table. The super-admin-service.ts → deleteUser() (used by admins deleting other users via the admin panel) correctly guards against deleting the last super admin, but the self-deletion path has no such logic.

[linear]

ENG-4885

[samssj10]

I'd like to work on this fix. The change is isolated to backend/src/services/user/user-service.ts — after deleting the user, check if any super admins remain and if not, reset initialized to false in the super_admin table. Happy to submit a PR once approved.

cc @maidul98 @akhilmhdh

[akhilmhdh]

Hi @samssj10

The provided alternative is quite dangerous given it makes the instance open to anyone taking it as super admin.

This is quite sensitive part of Infisical and may need more discussion internally to implement

But thank you for creating a bug report and we will be exploring more on this. We are rethinking about the whole server admin.

[samssj10]

Thank you so much for the context @akhilmhdh and that makes total sense for me as well.

A safer approach might be to block self-deletion when the user is the last super admin and other users still exist on the instance, with a clear error message asking them to promote another user to super admin first. That way the instance is never left in an ambiguous state without requiring any changes to the initialization flow.

Would love to see what approach the team goes forward for this.