Choosing a deployment

The SDK behaves identically wherever you point it. What changes is who operates the server, where your traces sit, and which product surfaces exist at all. That last one is the part people are usually not told, so this page leads with it.

The four options

	Hosted cloud	Your own AWS	Local	Open source
Operated by	Metergraph	You	You	You
Runs on	Metergraph’s AWS	ECS Fargate in your account, by Terraform	Docker Compose, one machine	Docker Compose, one machine
Source	Commercial	Commercial	Commercial	Apache-2.0
Traces leave your boundary	Yes	No	No	No
Stores prompts and completions	Yes	Yes	Yes	Never
Spend dashboard	Yes	Yes	Yes	Yes
Analysis and recommendations	Yes	Yes	Yes	—
Alerts	Yes, with Slack and GitHub delivery	Raised in-product only	Raised in-product only	—
Account needed to try it	Email verification	Contact Metergraph	Contact Metergraph	None

Most teams should start on the hosted cloud, because it needs no infrastructure from you and the free allowance is enough to find out whether any of this is worth having. You would run it yourself to keep traces inside a boundary you control, to satisfy a data residency or compliance requirement, or to reach models on a private network.

Hosted cloud

Nothing to operate. A free workspace on email verification, 100,000 captured calls per month, 90 days of metadata retention. This is the only deployment with public signup, billing, MetergraphBot pull requests, Slack and GitHub alert delivery, the MCP surface for coding agents, and importing from another observability tool.

Prompts and completions are stored, subject to the controls you configure.

Your own AWS account

One installation per AWS account, deployed with Terraform: ECS Fargate for the API, the worker, and the one-off analysis task. Traces and provider keys are stored only in that account, under your own IAM, network and audit controls. Nothing about a call is sent to Metergraph.

This deployment runs under the byoc-core profile, and that profile is narrower than hosted on purpose. It is customer-operated, so it excludes the hosted control plane and everything that reaches outside your account.

What byoc-core actually has

Capabilities are enforced at both boundaries a user can see: an unavailable operation answers 404 capability_unavailable, and the dashboard omits the navigation and controls for it. There is no half-enabled state and no feature that silently does nothing.

The hosted profile grants nineteen capabilities. byoc-core grants eight.

Capability	Hosted	byoc-core
telemetry	Yes	Yes
alerts	Yes	Yes
api_keys	Yes	Yes
membership	Yes	Read only
reports	Yes	Yes
analysis_runs	Yes	Yes
optimization	Yes	Yes
workspace_settings	Yes	Read only
signup	Yes	—
billing	Yes	—
platform_admin	Yes	—
evaluations	Yes	—
datasets	Yes	—
simulations	Yes	—
canaries	Yes	—
external_delivery	Yes	—
provider_probes	Yes	—
agent_api	Yes	—
import_sync	Yes	—

What that means in practice

These are the concrete things that are absent, and the routes that answer 404 capability_unavailable when something asks for them anyway.

• No public signup or invitations. You provision identity users and membership yourself. /v1/auth/signup and /v1/organization/invitations are unavailable.
• Workspace settings are read-only. PATCH /v1/organization is unavailable.
• No billing. There is nothing to upgrade to. /v1/upgrade-requests is unavailable.
• No external delivery. No Slack alerts, no GitHub issues, no MetergraphBot pull requests, no email. /v1/recommendation-deliveries, /v1/github-installations, /v1/email and the approve endpoints on reports and recommendations are all unavailable. The deployment refuses to start at all if a Slack webhook or GitHub App credential is configured, which is a stronger guarantee than a disabled button.
• No evaluation authoring, datasets or simulations. /v1/campaign, /v1/sme-reviews, /v1/judge-qualifications, /v1/dataset, /v1/simulation and the route constraint and evaluation endpoints are unavailable.
• No canaries. /v1/canaries and the canary action on a recommendation are unavailable. model_for() is still safe to leave in your code; it simply always returns your default.
• No agent or MCP surface. /v1/agent is unavailable, so a coding agent cannot query this deployment.
• No import from another tool. /v1/import-sync is unavailable.
• No platform administration or catalog editing. /v1/admin and /v1/catalog are unavailable.

Alerts are still raised and visible in the product. Only their delivery out to Slack and GitHub is absent, because that delivery runs from Metergraph’s own infrastructure and by design has no path into your account.

Analysis works, and selects the Bedrock pipeline profile so its own model calls run inside your account.

Absent is not broken

If you hit 404 capability_unavailable, the deployment is behaving correctly. The response names the capability, so the fix is knowing which profile you are on, not filing a bug.

Local

The same commercial build on one machine with Docker Compose. Useful for evaluating Metergraph against your own traffic before committing to anything, on a single host you control.

Your traces stay on the machine. The only outbound traffic is the image pull at install time and, when you run an analysis, the model calls it makes through your own provider account with your own key. Both need a route out, so there is no offline install.

Every image is pinned by digest in a signed release manifest, and the start script verifies the manifest signature and both image digests with cosign before Compose runs. Nothing starts that was not published by the Metergraph release workflow. See run it locally and verifying a release.

Your AWS account or one machine

Both keep traces and provider keys inside your boundary and send nothing to Metergraph. They differ in what has to exist first, how long it takes, and which models the analysis can compare.

	Your AWS account	One machine
Configured with	Terraform, 13 required inputs	A .env file
Prerequisites	VPC and private subnets, a private DNS zone, a TLS certificate, a KMS key, a Cognito domain prefix, an SNS topic, Bedrock model access	Docker with Compose, cosign, and the read-only registry credential Metergraph issues
Time to first trace	An hour or two where the prerequisites already exist	Minutes
Runs on	ECS Fargate, RDS and an internal load balancer: about 60 resources the module creates inside a VPC you pass in	Six Compose services on one host
Analysis models	Bedrock, the model ARNs you enable	Anthropic, OpenAI, or your Vercel AI Gateway account
Upgrades and backups	Yours, the same staged sequence as the install	Yours, re-run ./bin/start on a new release
Best suited to	Production, under controls you already govern	Evaluating against your own traffic, on a single host you control

The hour or two assumes the prerequisites are already in place. Creating a private DNS zone, a certificate, a customer-managed key or Bedrock access for the first time is the part that takes longer, and it is work in your account rather than in Metergraph.

The analysis models are the difference most likely to decide it. In your AWS account the analysis runs on Bedrock, which is what keeps those calls inside your network, so it can only compare models Bedrock serves in your region. On one machine it calls Anthropic, OpenAI or the gateway directly. If a model you care about is not available to you on Bedrock, raise it with us before you deploy.

Open source

The Apache-2.0 server and dashboard. No account, no key minting, no network egress, one command. This is the option to reach for when a structurally content-blind deployment is the requirement, rather than a configured one.

It is a different codebase from the three above, not the commercial build with features switched off. It gives you ingest, pricing from a community-maintained effective-dated catalog, and the spend dashboard. It does not have analysis, recommendations, alerts, datasets or any of the hosted control plane, and it is not going to grow them.

Its content guarantee is structural: every incoming row is projected through a fixed column allowlist, so prompts and completions are discarded at ingest even when the SDK is configured to send them, and a test asserts that a marker string placed in a request never reaches the database. That holds whether or not you trust whoever is running it.

It runs Postgres 16, where the hosted service and the customer-local stack run Postgres 17.

The three stacks take different commands

The open-source server, the customer-local edition and the AWS deployment are configured differently and do not share a quickstart. MG_TOKENS, port 8787 and a bare docker compose up are the open-source stack, and only the open-source stack. Check which one a set of instructions is for before you run it.

Moving between them

Capture is identical everywhere, so switching is one environment variable:

# hosted
unset METERGRAPH_INGEST_URL

# anything you run yourself
export METERGRAPH_INGEST_URL=http://localhost:8787

What does not move is your data. Each deployment has its own database, and there is no export-and-reimport path between them. Traces captured against one stay there. Choose with that in mind, and start on the hosted cloud only if you are comfortable that the first few weeks of history may be history you leave behind.

Run it locally The customer-local edition, step by step.

Your own AWS account Terraform, ECS Fargate, and what byoc-core expects of you.

Content and privacy If the deployment question is really a content question, start here instead.