Request to Hide or Delete Default Project in Phoenix

Ben M. · 2025-05-29T14:46:38.248Z

Is there a reason that we can’t delete or at least hide the default project in phoenix? We have discrete project names for every deployment and the default sits empty but unable to be removed

Request to Hide or Delete Default Project in Phoenix | Arize AI Community

4 comments

· Sorted by Oldest

RunLLM
APP
·
The default project in Phoenix cannot be deleted or archived to ensure there is always at least one project present in the system. This is an intentional safeguard: deletion or archiving of the default project is explicitly blocked, even if other projects exist, to prevent system instability or user confusion if all projects are removed or hidden. The default project acts as a fallback and organizational anchor, especially for new users or empty states, and its presence is enforced at both the API and UI levels. Hiding the default project is not currently supported by the platform's design or API.According to the official API documentation, "The default project cannot be deleted." This is further confirmed by implementation details and issue discussions, which clarify that the default project is protected from deletion or archiving to maintain system integrity.Would you like more detail on possible workarounds or the technical rationale?Sources: - Projects API Reference - chore: protect default project from deletion - Prevent default project from being deleted
💡 Hint: Mention RunLLM in the thread for followups.
Mikyo
·
Hey Ben M. - it's sorta historical but also intentional for a few reasons. Any trace that doesn't have a project in the resource ends up in the default project. Often times people forget to add this and then go searching for the trace, only to find it in the default. Since we dynamically create projects, if we allowed it to be deleted, it would keep regenerating, causing a bit of thrash. We also allow for project switching at runtime in notebooks using a context manager (e.g. using_project ) - We did this for experimentation reasons but it has some caviots in that spans could escape the context manager if they happened in things like threads or background processes. To be able to ensure that a span always landed in a project and then could be re-constructed I believe is why we made it un-deletable. I believe those were the reasons 😅 Happy to explore making it deletable 🤷
Ben M.
·
It's not the end of the world, we just have a perpetually empty project in production 😄 Another option would be renaming it, but either way this is a low low priority IMO
Mikyo
·
Gotcha, well lmk if it gets really annoying 🙂

RunLLM
APP
·
The default project in Phoenix cannot be deleted or archived to ensure there is always at least one project present in the system. This is an intentional safeguard: deletion or archiving of the default project is explicitly blocked, even if other projects exist, to prevent system instability or user confusion if all projects are removed or hidden. The default project acts as a fallback and organizational anchor, especially for new users or empty states, and its presence is enforced at both the API and UI levels. Hiding the default project is not currently supported by the platform's design or API.According to the official API documentation, "The default project cannot be deleted." This is further confirmed by implementation details and issue discussions, which clarify that the default project is protected from deletion or archiving to maintain system integrity.Would you like more detail on possible workarounds or the technical rationale?Sources: - Projects API Reference - chore: protect default project from deletion - Prevent default project from being deleted
💡 Hint: Mention RunLLM in the thread for followups.
Mikyo
·
Hey Ben M. - it's sorta historical but also intentional for a few reasons. Any trace that doesn't have a project in the resource ends up in the default project. Often times people forget to add this and then go searching for the trace, only to find it in the default. Since we dynamically create projects, if we allowed it to be deleted, it would keep regenerating, causing a bit of thrash. We also allow for project switching at runtime in notebooks using a context manager (e.g. using_project ) - We did this for experimentation reasons but it has some caviots in that spans could escape the context manager if they happened in things like threads or background processes. To be able to ensure that a span always landed in a project and then could be re-constructed I believe is why we made it un-deletable. I believe those were the reasons 😅 Happy to explore making it deletable 🤷
Ben M.
·
It's not the end of the world, we just have a perpetually empty project in production 😄 Another option would be renaming it, but either way this is a low low priority IMO
Mikyo
·
Gotcha, well lmk if it gets really annoying 🙂