Pydantic Logfire: an OpenTelemetry-based Python observability SDK with a closed-source backend

What Logfire actually solves for Python and LLM teams

Python observability has a fragmentation problem. Traces come from OpenTelemetry, logs from the standard logging module, metrics from a separate client library, and application-level context such as Pydantic validation results usually lives nowhere at all. Logfire's pitch is that a single configure() call wires these together and sends them to one place. The README frames the design goal as being an opinionated wrapper around OpenTelemetry, which is the honest description: it is not a new protocol, it is a convenience layer plus a hosted product.

The audience is narrower than the marketing implies. The README lists Python-centric insights, rich display of Python objects, event-loop telemetry, profiling, and built-in analytics on Pydantic validations. Those features matter most to teams running FastAPI services, Pydantic models, and LLM or agent workloads where a trace needs to show the prompt, the model response, and the validation failure in one view. If your services are written in Go or Java, the SDK is not aimed at you; the README points to TypeScript and Rust SDKs and to generic OpenTelemetry instrumentation instead.

The SDK, the exporter, and the closed-source backend

The repository layout makes the boundary explicit. The Python package lives in logfire/, a stub-only package for type information lives in logfire-api/, and docs/ holds documentation. The README states plainly that the server application for recording and displaying data is closed source, and that the SDKs are open source and can export to any OTel-compatible backend.

The mechanism is therefore conventional OpenTelemetry plus ergonomics. logfire.configure() sets up the SDK and exporter. logfire.info() and logfire.span() create log records and spans. logfire.instrument_fastapi(app) patches a web framework so requests produce traces without hand-written span code. Because the output is OTLP, the destination is a configuration choice rather than a lock-in at the protocol level.

That last point deserves emphasis because it is the most consequential design decision in the project. You can adopt the SDK and point it somewhere else. What you cannot do is run the Logfire UI and storage yourself without an enterprise licence, which the README links to under deploy/enterprise. The open source grant covers the client, not the product.

Installing Logfire and sending a first span

The README gives a three-step path: install the package, authenticate the CLI, then instrument. Start with the install command exactly as documented.

pip install logfire

The package requires Python 3.10 or newer according to pyproject.toml, and the classifiers list support through 3.14. Next, authenticate. This step is what connects your local machine to the hosted backend, so it is the point where a network-restricted environment will fail.

logfire auth

With credentials in place, the README's manual tracing example configures the SDK and emits a log line and a span. Note that this snippet calls input(), so it blocks on stdin and is marked in the README as not runnable in automated contexts.

from datetime import date

import logfire

logfire.configure()
logfire.info('Hello, {name}!', name='world')

with logfire.span('Asking the user their {question}', question='age'):
    user_input = input('How old are you [YYYY-mm-dd]? ')
    dob = date.fromisoformat(user_input)
    logfire.debug('{dob=} {age=!r}', dob=dob, age=date.today() - dob)

The braces in the span name and the log message are not f-string syntax; they are placeholders filled from the keyword arguments, which is why the values appear as structured attributes in the UI rather than as flattened text. For a web service, the README's FastAPI example is closer to real use, since it instruments the app globally and then lets Pydantic models flow through as structured data.

from fastapi import FastAPI
from pydantic import BaseModel

import logfire

app = FastAPI()

logfire.configure()
logfire.instrument_fastapi(app)


class User(BaseModel):
    name: str
    country_code: str


@app.post('/')
async def add_user(user: User):
    return {'message': f'{user.name} added'}

After this, requests to the endpoint should appear as traces, with the request body validated by the User model visible as an attribute. The README notes that you would normally continue by instrumenting your database connector and HTTP library as well.

Where Logfire is the wrong choice

The self-hosting constraint is the first real limitation, and it is a licensing one rather than a technical one. The README says you can self-host the platform by purchasing an enterprise license. There is no documented path to run the Logfire UI from the MIT-licensed repository alone, because the server is not in it. Teams whose compliance rules require every component in the observability path to be open source will have to use the SDK against a different backend, which means giving up the parts of the product that are not OpenTelemetry.

The second limitation is language coverage in the SDK itself. Python is the primary target; TypeScript and Rust SDKs exist in separate repositories, and everything else goes through generic OpenTelemetry instrumentation. The Python-specific features that make the product distinctive, such as Pydantic validation analytics and rich object display, do not transfer to a polyglot stack in the same form.

The third is the dependency on the hosted control plane for the default experience. The README does not document an offline or air-gapped setup procedure, and it does not document rollback if you decide to stop exporting. If your environment cannot reach the Logfire endpoint, the documented quickstart does not apply and you are configuring an OTLP exporter by hand.

Logfire compared with Langfuse

Langfuse is the comparison people search for, and the difference is architectural rather than cosmetic. Langfuse is positioned as an LLM engineering platform, so its data model is built around prompts, generations, scores and datasets from the start. Logfire starts from general application observability and layers LLM and eval support on top, which the README signals by linking separately to pages for LLM observability and evals in production.

In practice that means the choice depends on what you are tracing. If the workload is a Python service that happens to call a model, and you want the same traces to cover your database calls, your FastAPI routes and your Pydantic validations, Logfire's OpenTelemetry foundation is the more natural fit, and the SDK can be pointed at another OTLP backend if you change your mind about the vendor. If the workload is prompt-centric and the primary users are LLM engineers rather than platform engineers, a tool whose core abstraction is the generation will need less translation. The README's own comparison page is the place to check feature-by-feature claims, since this repository does not document Langfuse's behaviour.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10, which is recent. Release history shows a steady cadence: v4.40.0 on 2026-08-05, v4.41.0 on 2026-08-20, and v5.0.0 on 2026-09-04. The jump to 5.0.0 is the item to plan around. A major version bump in an observability SDK usually means the instrumentation or configuration surface changed, and this repository does not state which APIs were removed or renamed. Read CHANGELOG.md before upgrading a production service, and pin the version in your dependency file rather than tracking latest.

The licence position is straightforward to describe and worth stating precisely. The Python SDK is MIT, and pyproject.toml declares license = "MIT" with a LICENSE file. The platform is not covered by that grant. Nothing here is legal advice, but the practical consequence is that the MIT licence gives you freedom over the client code and no rights over the server, so any plan that assumes you can fork and run the whole product needs to be checked against the enterprise terms first. The SDK's own dependencies and their licences are a separate question that the README does not address.

Editorial conclusion

Adopt Logfire if your stack is Python-first, you already accept OpenTelemetry as the transport, and paying for a hosted backend is fine. Do not adopt it if procurement requires a fully open source observability stack, or if you need the UI running on your own hardware without an enterprise licence. Before committing, verify three things: that logfire auth works against your network egress rules, that logfire.configure() exports to a non-Logfire OTLP endpoint in your environment, and what your data retention and self-hosting terms are under the enterprise licence.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. pydantic/logfire on GitHub
4. README
5. Releases