Self-hosting guide.

• Go 1.25+ (brew install go on macOS)
• SQLite (bundled with Go, no install)
• Optional: Docker / a Linux host for production

git clone https://github.com/mesedi-ai/mesedi
cd mesedi/backend

# First run only: fetch deps
go mod tidy

# Run the service (creates mesedi-dev.db + runs migrations on first run)
go run cmd/api/main.go

The backend listens on :8080 by default and serves three things:

• The ingest API (executions, events, webhooks).
• A local-dev HTML dashboard at /ui/.
• A public /health endpoint.

12-factor environment variables, with command-line flags overriding env vars:

• MESEDI_PORT (default 8080): TCP port the HTTP server binds to.
• MESEDI_LOG_LEVEL (default info): debug / info / warn / error.
• MESEDI_DB_URL: Postgres connection string. Empty for SQLite (the default during single-instance dev).
• MESEDI_DASHBOARD_URL: public origin of your Next.js dashboard. Used to construct playbook links in webhook payloads.

In both SDKs, pass baseUrl / base_url to configure().

# Python
mesedi.configure(
    api_key="mesedi_sk_...",
    base_url="https://mesedi.yourdomain.com",
)

// TypeScript
configure({
  apiKey: "mesedi_sk_...",
  baseUrl: "https://mesedi.yourdomain.com",
});

The default is SQLite on a single persistent volume, which is what the hosted Cloud version runs today (Fly.io with a 10GB volume in iad / Ashburn, VA). For single-instance, low-volume deployments this is sufficient: SQLite handles tens of millions of rows comfortably, and the dashboard's admin storage view shows utilization and per-project breakdown.

For multi-instance deployments and higher write concurrency, Postgres migration is on the production-hardening roadmap. Until then, the recommendation is single-instance SQLite with a daily backup of the volume.

The local-dev environment bootstraps a fixed dev key (mesedi_sk_dev_local_only) on first run. This key is hardcoded and non-secret, never use it for anything other than local development. For real deployments, mint keys through the dashboard's API Keys page; only the prefix and a hash are stored.

Self-hosting gives you full control over the data path and avoids any vendor lock-in. What you take on:

• Backups and disaster recovery (we run daily volume snapshots on Cloud; you'll need your own).
• Upgrades. Pull, rebuild, redeploy. Schema migrations run on backend startup.
• Backend monitoring. The hosted version has external uptime monitoring via Upptime; you'll want similar for your own deploy.

The hosted Cloud version handles all of the above for the Hobby and Pro tiers. See pricing for the comparison.

HTTP API reference covers the wire format your SDKs (or your hand-rolled instrumentation) post to the self-hosted backend.

Failure classes and playbooks explains the detectors that will run over the telemetry once it lands.