Self-Hosted Logfire Overview

Self-hosted Logfire runs the same product as the public Logfire deployment in your own Kubernetes environment. It is delivered through the official Logfire Helm chart.

Self-hosted Logfire is included in the Enterprise plan. Contact sales@pydantic.dev for access to the private container images and commercial terms.

Use the Logfire Helm chart README for the current chart commands and chart-version-specific values. These website docs focus on planning, architecture, examples, and operational procedures.

Website Docs

• Local quickstart: run a first install with the chart’s values.dev.yaml file.
• Architecture: understand the main services, dependencies, and data flow.
• Production requirements: plan the production values you need before installing the chart.
• Examples: configure SSO connectors and exchange instance-admin tokens.
• Troubleshooting: debug image pull, database, and runtime issues.
• Bucket migration: migrate telemetry object storage buckets.
• FusionFire database migration: move the ff database to a new PostgreSQL instance.
• Usage report: generate usage reports for self-hosted deployments.

Production Prerequisites

A production deployment needs:

• A Kubernetes cluster with enough capacity for the selected sizing preset.
• Image pull credentials for Logfire’s private images.
• PostgreSQL, with three databases: one for Logfire application data, one for FusionFire metadata, and one for Dex.
• Object storage using Amazon S3, Google Cloud Storage, Azure Storage, or an S3-compatible provider.
• A managed Redis instance.
• An identity provider supported by Dex.
• Kubernetes storage for scratch and ingest volumes, either through a default StorageClass or explicit storage class settings in values.

Production requirements explains what to decide for each service. The Logfire Helm chart README of your chart version states the supported versions and settings.

Upgrades

Each chart version has a GitHub release with Upgrade notes and Breaking changes sections. Before you upgrade, read these sections for every version after your current one, up to and including the target version. You can then upgrade to the target version in one helm upgrade.

The backend and FusionFire migrations run as Helm pre-upgrade jobs, before the new pods start. The running pods keep serving requests during the migrations, because the migrations keep blocking locks short:

• Index changes use CONCURRENTLY.
• Validations of large tables use locks that do not block reads or writes.
• A statement that needs a stronger lock sets a short lock timeout, usually under a second. If it cannot get the lock in that time, the migration fails and Kubernetes runs the job again.

Moving From Logfire Cloud

There is no supported way to move existing data from Logfire Cloud to a self-hosted instance. Point your applications at the self-hosted instance, and keep access to Logfire Cloud until you no longer need the data there.

Client Configuration

After deploying self-hosted Logfire, create a project and copy its write token from Project → Settings → Write tokens. Set it before running your application:

Terminal

export LOGFIRE_TOKEN="your-write-token"

Point the SDK at your Logfire base URL:

import logfire

logfire.configure(
    advanced=logfire.AdvancedOptions(base_url='https://logfire.example.com'),
)

For local development, you can instead sign in and save project credentials with the CLI. These commands require uv; pass the same base URL to both:

Terminal

uvx logfire-cli --base-url="https://logfire.example.com" auth
uvx logfire-cli --base-url="https://logfire.example.com" init