Deploy Latitude AI Agent Observability

Deploy and Host Latitude AI Agent Observability on Railway

Latitude is an open source observability platform for AI agents. It ingests OpenTelemetry traces from your agents, groups them into sessions, finds where they fail, and lets you run evaluations, build datasets and query everything through a REST API or an MCP server.

About Hosting Latitude

Latitude's self host stack is five application services (web, API, ingest, workers, workflows) and a migration job, backed by PostgreSQL with pgvector, ClickHouse, two Redis instances, Temporal and an S3 object store.

This template deploys that full stack, pinned to version 0.3.126, with every secret generated at deploy time. It also closes two gaps in the stock setup. Latitude signs users in with emailed magic links and ships no mail server, so the template includes a password protected Mailpit inbox where your first login link arrives. And upstream's API lets anyone create an organization and an API key without logging in, so the API sits behind a small gateway that refuses that route unless you send a secret header.

Plan requirement: Hobby plan or higher. ClickHouse, Temporal and the Node services need more memory than the Free and Trial plans allow.

Common Use Cases

• Agent tracing: send OTLP traces from any framework and inspect spans, tool calls, cost and latency
• Failure discovery: signals and flaggers group recurring agent failures across sessions
• Evaluations and datasets: turn production traces into datasets and score them
• Agent access: let coding agents query traces through the built in MCP server

Dependencies for Latitude Hosting

• PostgreSQL with pgvector: included
• ClickHouse: included (span and trace store)
• Redis: included, two instances (cache and job queue)
• Temporal: included, stored in the same PostgreSQL
• SeaweedFS: included (S3 object store)
• Mailpit: included (login link inbox until you add real email)
• AI provider keys: not needed to boot; required only for AI features such as evaluations and semantic search

Deployment Dependencies

• Latitude self hosting docs
• Latitude configuration reference
• Latitude GitHub repository

Implementation Details

First steps after deploy:

1. Fill LAT_ALLOWED_EMAIL_DOMAIN on the Web service when you deploy, for example acme.com. Only addresses at that domain can create accounts.
2. Wait until every service is green. The app services wait for the Migrations service.
3. Open the Web domain and enter your email.
4. Open the Mailpit domain, sign in with MAILPIT_USERNAME and MAILPIT_PASSWORD from the Mailpit service variables, and click the login link.
5. Create an API key in the UI and point your OpenTelemetry exporter at the Ingest domain.

Key environment variables:

# Web
LAT_ALLOWED_EMAIL_DOMAIN=acme.com        # required
LAT_BETTER_AUTH_SECRET=${{secret(64,"abcdef0123456789")}}
LAT_MASTER_ENCRYPTION_KEY=${{secret(64,"abcdef0123456789")}}
LAT_WEB_URL=https://${{Web.RAILWAY_PUBLIC_DOMAIN}}
LAT_API_URL=https://${{API Gateway.RAILWAY_PUBLIC_DOMAIN}}
LAT_INGEST_URL=https://${{Ingest.RAILWAY_PUBLIC_DOMAIN}}

# Workers (optional, replaces Mailpit)
LAT_SMTP_HOST=  LAT_SMTP_USER=  LAT_SMTP_PASS=  LAT_SMTP_FROM=

# API Gateway
BOOTSTRAP_TOKEN=${{secret(48)}}

Treat the Mailpit password like an admin password: whoever reads that inbox can sign in as any user. After you configure real email on Workers you can delete the Mailpit service. Do not rotate LAT_MASTER_ENCRYPTION_KEY after first use.

Why Deploy Latitude on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Latitude on Railway, you get the complete agent observability stack with generated secrets, health checks, private networking between services, managed SSL, and an instance that strangers cannot sign up to.