Skip to main content
The Phoenix app can be run in various environments such as Colab and SageMaker notebooks, as well as be served via the terminal or a docker container.
96785dbd-image

From the Terminal

Run Phoenix via the CLI on your local machine
09a1b0fb-image

As a Container

Self-host your own Phoenix
bac66bfa-image

In a Notebook

Run Phoenix in the notebook as you run experiments
If you are set up, see Quickstarts to start using Phoenix in your preferred environment.

​
Remote deployments

Any Phoenix instance that isn’t running on the same machine as your app — a container, a Kubernetes deployment, or a managed host — is reached the same way: point PHOENIX_COLLECTOR_ENDPOINT at its hostname, and supply an API key if it has authentication enabled.

​
Container

See Self-Hosting.

​
Notebooks

To start phoenix in a notebook environment, run:
This will start a local Phoenix server. You can initialize the phoenix server with various kinds of data (traces, inferences).
By default, Phoenix does not persist your data when run in a notebook.

​
Terminal

If you want to start a phoenix server to collect traces, you can also run phoenix directly from the command line:
This will start the phoenix server on port 6006. If you are running your instrumented notebook or application on the same machine, traces should automatically be exported to http://127.0.0.1:6006 so no additional configuration is needed. However if the server is running remotely, you will have to modify the environment variable PHOENIX_COLLECTOR_ENDPOINT to point to that machine (e.g. http://<my-remote-machine>:<port>)

​
Configuration & environment variables

Phoenix reads its connection settings from environment variables. Three of them are easy to confuse, so it’s worth being precise about what each one is for:
Point PHOENIX_COLLECTOR_ENDPOINT at the server’s base URL. Setting it (or the legacy PHOENIX_HOST) to a full endpoint path such as .../v1/traces will misconfigure the exporter and your traces will not arrive.

​
Choosing a project

PHOENIX_PROJECT selects the project that project-scoped operations write to and read from. PHOENIX_PROJECT_NAME is a supported alias for the same setting. When both are set, PHOENIX_PROJECT wins and Phoenix logs a one-time conflict warning. If neither is set, the project defaults to "default".

​
Credential file discovery (.env.phoenix)

Instead of exporting variables in every shell, you can drop PHOENIX_-prefixed settings into a .env.phoenix file. The Phoenix SDKs and CLI auto-discover it: starting from the current working directory they walk up toward the filesystem root and load the first .env.phoenix they find (dotenv format).
A few rules worth knowing:
  • The process environment always wins. A value already set in the environment is never overridden by the file.
  • The filename is .env.phoenix, not .env.
  • Add it to your ignore rules before storing credentials in it — the Phoenix repository already git-ignores .env.phoenix.
  • Opt out by setting PHOENIX_DISCOVER_CONFIG=false (also accepts 0, no, off), which disables file discovery entirely.