Multi-Tenancy in FastAPI: Using Crevasses Outside Notebooks

6 comments

· Sorted by Oldest

RunLLM
APP
·
It seems likely that Phoenix can be used outside of a notebook environment, such as in a FastAPI application, but there are some considerations. Phoenix currently does not support multi-tenancy directly, which means you cannot natively segment data by "company" or similar entities within a single server instance. However, you can manage multiple projects by using different project names when logging traces, as suggested in the <https://github.com/Arize-ai/phoenix/issues/6253|GitHub issue>. For a FastAPI setup, you can use the `phoenix.otel` module to register a tracer provider and specify different project names for different traces. This allows you to logically separate traces by project, but it does not provide full multi-tenancy features like isolated data access or user management. You might need to implement additional logic in your application to handle these aspects. Would you like more detail on setting up Phoenix with FastAPI or managing multiple projects? Sources: - <https://github.com/Arize-ai/phoenix/issues/6253|GitHub issue>
💡 Hint: Mention RunLLM in the thread for followups.
Xander S.
·
Hey Christopher H. 👋 That's a really good question. The project name is set via contextvars, which should be thread and task local. I think that probably means they're local to the coroutine defining each fastapi route, but I have not tested this behavior.
Xander S.
·
If you want to be extra careful, you can also instantiate an individual tracer provider with a project name resource for each project. But this might be overkill.
Christopher H.
·
Yes, if project name is set via contextvars it should work. You mean with set_global_tracer_provider=False? Yeah, I will test and see. First option is more convenient 🙂 ...btw. really cool to see that the team is so response!
🙌1
Roger Y.
·
The current implementation is not safe for concurrency because it’s monkey patching the __init__ of each span. That’s why we generally limit its application in a notebook
🙌1
Xander S.
·
Oh, good catch Roger Y.. Christopher H. better go with the individual tracer provider approach then.
✅1

Multi-Tenancy in FastAPI: Using Crevasses Outside Notebooks | Arize AI Community

RunLLM
APP
·
It seems likely that Phoenix can be used outside of a notebook environment, such as in a FastAPI application, but there are some considerations. Phoenix currently does not support multi-tenancy directly, which means you cannot natively segment data by "company" or similar entities within a single server instance. However, you can manage multiple projects by using different project names when logging traces, as suggested in the <https://github.com/Arize-ai/phoenix/issues/6253|GitHub issue>. For a FastAPI setup, you can use the `phoenix.otel` module to register a tracer provider and specify different project names for different traces. This allows you to logically separate traces by project, but it does not provide full multi-tenancy features like isolated data access or user management. You might need to implement additional logic in your application to handle these aspects. Would you like more detail on setting up Phoenix with FastAPI or managing multiple projects? Sources: - <https://github.com/Arize-ai/phoenix/issues/6253|GitHub issue>
💡 Hint: Mention RunLLM in the thread for followups.
Xander S.
·
Hey Christopher H. 👋 That's a really good question. The project name is set via contextvars, which should be thread and task local. I think that probably means they're local to the coroutine defining each fastapi route, but I have not tested this behavior.
Xander S.
·
If you want to be extra careful, you can also instantiate an individual tracer provider with a project name resource for each project. But this might be overkill.
Christopher H.
·
Yes, if project name is set via contextvars it should work. You mean with set_global_tracer_provider=False? Yeah, I will test and see. First option is more convenient 🙂 ...btw. really cool to see that the team is so response!
🙌1
Roger Y.
·
The current implementation is not safe for concurrency because it’s monkey patching the __init__ of each span. That’s why we generally limit its application in a notebook
🙌1
Xander S.
·
Oh, good catch Roger Y.. Christopher H. better go with the individual tracer provider approach then.
✅1