Choosing a deployment

The SDK behaves identically wherever you point it. The deployment determines who operates the server, where traces are stored, and which product surfaces are available.

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

Use the hosted cloud when you do not want to operate infrastructure. Run Metergraph yourself when traces must stay inside a boundary you control, when you have a data-residency or compliance requirement, or when models are 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, and importing from another observability tool.

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

Hosted, local and BYOC core expose Agent Access. The open-source server also supports bounded, metadata-only agent reads. Availability of a server transport does not prove a client can reach or authenticate to it. Use the agent setup guide to choose a reachable client and the right credential for your deployment.

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 twenty capabilities. byoc-core grants nine.

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	Yes
import_sync	Yes	—
scheduled_imports	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 always returns your default.
• Agent Access metadata is available. /v1/agent supports bounded workspace reads; retained trace content and replay are unavailable on byoc-core. See Connect a coding agent.
• 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.

Unavailable capabilities return 404

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	Seven 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. It needs no account or key minting, makes no outbound calls, and stores no content.

It is a separate codebase from the three commercial deployments. It provides ingest, pricing from a community-maintained effective-dated catalog, and the spend dashboard. It does not provide analysis, recommendations, alerts, datasets, or the hosted control plane.

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
# commercial customer-local default
export METERGRAPH_INGEST_URL=http://127.0.0.1:8080
# OSS default
# export METERGRAPH_INGEST_URL=http://localhost:8787

Data does not move between deployments. Each deployment has its own database, and there is no export-and-reimport path between them. Traces captured against one stay there.

Run it yourselfCompare the open source, customer-local and AWS options.

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

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

Connect a coding agentCompare Agent Access transports and capabilities across deployments.