One Yurbi per customer server. The economics work.
Your software ships to customer servers — Yurbi is built for that architecture. Each customer gets a fully isolated instance, branded as your product. $500/deployment/year at list rate, volume discounts at scale.
You're in the right place if…
Installed application per customer
Your product ships as on-premise, customer VM, or customer-managed cloud — not a shared SaaS instance.
Data must stay in each customer's environment
A shared multi-tenant cloud instance isn't acceptable by architecture, compliance, or customer contract.
Replacing Crystal or SSRS in your product
Each customer has their own instance of your software and your embedded reporting layer.
Pricing can't scale geometrically
You need a model that doesn't compound per-user or per-report costs as your customer base grows.
Analytics as a differentiating feature
Without building and maintaining a custom reporting stack across every customer deployment.
Planning an on-prem to cloud migration
Richer analytics in your cloud version is one of the most effective on-prem customer migration incentives.
One Yurbi instance per customer — isolated, branded, independent
Per-customer reporting you build yourself multiplies with every deployment.
When your software ships to each customer's servers, a reporting layer you build by hand isn't one project — it's one per customer. Every new deployment adds another thing your engineers maintain, upgrade, and support, for as long as that customer exists.
Offering analytics as a feature of your cloud version that on-prem customers don't have is one of the most effective migration incentives. Yurbi runs in both environments with the same codebase, same API, and same flat pricing model — analytics move with customers as they migrate.
Built for the ship-to-customer-server model — and priced for it
We've watched on-prem ISVs try to stretch cloud-first BI tools across customer deployments and fight the licensing the whole way. Yurbi was built for per-deployment architecture from the start.
- Every feature in every tier — no paywalls between plans
- Flat, per-deployment pricing that doesn't spike with usage
- Runs on your customers' infrastructure — fully isolated per deployment
- You reach the engineers who built it — not a first-tier support queue
Common questions
Both models are supported. If you ship one instance per customer server, each gets its own Yurbi — completely isolated, independently branded. If you run a shared SaaS model, Yurbi's Tenant Mode handles isolation within a single deployment. Most on-prem ISVs use the per-deployment model. The $500/deployment add-on applies to each additional production deployment.
Yurbi has a full REST API covering user management, report execution, data source management, and scheduling. You can script provisioning, configuration, and updates the same way you manage the rest of your application stack. No auto-update touches customer environments without your involvement.
Deploying Yurbi alongside your application is a common pattern for on-prem ISVs. The specifics of bundling, licensing, and OEM rights are handled in your Yurbi agreement. Talk to us about your deployment model and we'll structure the licensing appropriately.
Volume discounts on additional deployments start after your first 10 and decrease significantly at scale. We don't publish tiers publicly because the right structure depends on your deployment count, growth rate, and contract term. Contact us before estimating — the list rate of $500 × N is not what large-scale ISVs actually pay.
Yurbi is fully air-gap capable — no required outbound connections to 5000fish during normal operation. The installer is downloaded once on an internet-connected machine and deployed to the target server. Updates follow the same pattern. Full security model →
Every customer gets a branded, isolated Yurbi — and the math stays simple.
Here's what it looks like once Yurbi ships alongside your product.
- Each customer runs a fully isolated instance, branded as your product — on their own servers.
- Your cost per deployment is a known number you can build into your own pricing.
- Your engineers aren't maintaining a separate reporting layer for every customer.
- When you need something, you talk to the people who built the platform.