Run it yourself

There are three ways to run Metergraph yourself. Choose based on how much of the product you need, where you want to operate it, and whether you want a commercial build or the Apache-2.0 server.

The three options

Open source serverApache-2.0, content-blind, and focused on ingest, pricing and the spend dashboard.

Customer-local bundleThe full commercial product on one machine, with traces and provider keys kept there.

Your own AWS accountA production installation in your VPC, with Terraform and AWS services you operate.

Option	Quick facts
Open source server	Apache-2.0. Docker Compose on one machine. Postgres 16. Content is discarded at ingest. Start with MG_TOKENS=dev-token docker compose up.
Customer-local bundle	Commercial signed bundle. Docker Compose on one machine. Postgres 17. Content is captured unless you turn it off. Verify the release, then run ./bin/start.
Your own AWS account	Commercial Terraform module. ECS Fargate, RDS, S3 and SQS in your AWS account. Content is captured unless you turn it off. Start by applying Terraform.

Open source server

Choose this when you need the smallest, most private deployment and the spend dashboard is enough. It needs no Metergraph account, key minting or outbound network access. The server strips prompts and completions at ingest, so it never stores content.

The server and dashboard come from the public PioneerSquareLabs/metergraph repository. It runs on one machine with Docker Compose and serves on http://localhost:8787.

Run the open source server

Customer-local bundle

Choose this when you want the commercial dashboard, alerts and optimization analysis on one machine, with traces and provider keys kept there. It is a signed release bundle, not a repository to clone. The stack runs on Docker Compose, serves on http://127.0.0.1:8080, and uses Postgres 17 plus local object storage and queues.

You need Docker Compose, cosign, and a pull-only registry credential from Metergraph. A provider key is needed for automatic workload classification and manually started analyses. The release bundle includes the start script, which verifies the signed manifest and image digests before it starts the stack. Workload classification starts automatically after 10 usable traces by default and refreshes at most once per 24 hours; the threshold is configurable in the bundle’s .env.

Run the customer-local bundle

Your own AWS account

Choose this for a production installation inside controls you already govern. Terraform deploys the commercial build into one AWS account, with ECS Fargate for the API and workers, RDS for relational data, S3 and SQS for storage and queues, Cognito for identity, and Bedrock for analysis model calls.

You own the network, IAM, backups, upgrades and runtime operations. The deployment has no Metergraph control plane or operator access across the boundary. It is the most involved option and requires an existing VPC, private subnets, a private DNS zone, a certificate, a KMS key, a Cognito domain prefix, an SNS topic and Bedrock model access.

Deploy to your own AWS account

Shared guidance

Capture is the same in all three options. Point the SDK at the deployment by setting METERGRAPH_INGEST_URL and use the key issued by that deployment. Data does not move between deployments because each one has its own database.

Keep the stacks separate

The commands are not interchangeable. MG_TOKENS, port 8787 and a bare docker compose up belong to the open source server. The customer-local bundle uses ./bin/start on port 8080. AWS uses Terraform and ECS.

Verify a customer-local releaseCheck the signed bundle and image digests before starting it.

Operate a deploymentDay-two commands for workspaces, keys, backups and upgrades.