Skip to main content
Pylva is cost infrastructure for AI agent businesses. Use Pylva Cloud when you want the fastest managed path, and self-host from the public repository when you need direct control over deployment and operations.

​
Pylva Cloud

Pylva Cloud is the managed version of Pylva. It is for teams that want to install the SDK, create an API key, and start reviewing customer-level cost without running the infrastructure themselves. Cloud handles the operational work around hosting, storage, upgrades, migrations, monitoring, retention, and scale. It is also the natural path for hosted billing workflows and customer-facing usage surfaces. For the security and data responsibility boundary, see Security And Data Handling. For the hosted end-user visibility surface, see Customer Portal.

​
Public repository

The public repository at github.com/Pylva/pylva is the product surface developers need to trust and inspect:
  • SDKs and framework callbacks.
  • Shared telemetry and API schemas.
  • Event ingest and validation.
  • Cost attribution by customer and step.
  • Server-side pricing logic.
  • Dashboard surfaces for cost, customers, pricing, rules, and keys.
  • Billing and customer portal surfaces, with license terms defined by path.
  • Local self-host setup - the repository README walks through Docker Compose, migrations, and the dev server.
The goal is simple: the data path that meters customer cost should be inspectable. Builders should be able to understand what Pylva collects, what it does not collect, and how usage becomes cost. For a direct list of what Pylva needs and what it never needs, see Security And Data Handling.

​
Self-hosting

Self-hosting is the control path. It is useful when a team wants to run Pylva on its own infrastructure, inspect every component, or keep deployment decisions internal. Self-hosting also means your team operates the system. Plan for PostgreSQL, ClickHouse, Redis, migrations, upgrades, backups, monitoring, and incident response. For many teams, Pylva Cloud is the lower-effort path because those responsibilities are handled for you. Self-hosted workspaces use the explicit self_hosted entitlement source rather than Pro, Scale, or Enterprise. Their finite, operator-configurable defaults are 10,000,000 telemetry events per month, 500 distinct end-users, 365 days of telemetry retention, and 365 days of billing-record retention. Event-cap enforcement is enabled by default; Plans and limits lists the environment variables for changing those values or explicitly disabling the monthly event cap.

​
Why use Cloud if self-host exists?

Use Cloud when you want less operational work and a faster production path:
  • Managed infrastructure and upgrades.
  • Hosted storage and retention.
  • Higher-scale ingest without operating the data stores.
  • Production monitoring and operational response.
  • Hosted billing workflows.
  • Hosted customer-facing usage and portal surfaces.
Commercial plans and subscription billing are Cloud-layer concerns. Self-hosting uses its own configurable capacity and retention limits without assigning a commercial plan. See Plans and limits. Use self-host when control matters more than operational convenience.

​
Licensing

Pylva uses a path-based license map. Files are MIT by default unless LICENSE-MAP.md lists a different license for that path. The current public map keeps the product core MIT and marks listed billing, Stripe, and customer portal paths as Elastic License 2.0. Always use the repository LICENSE, LICENSE-MAP.md, and path-level notices as the source of truth for exact rights and restrictions. Do not assume formal compliance programs, enterprise identity features, contractual uptime commitments, dedicated support, private deployments, or enterprise governance unless a Pylva page or agreement explicitly says they are available.