You Probably Need Fewer Runtime Licenses Than You Think

What’s a runtime instance, and how many will I need?

Unless you’re a one-person shop, if you’re evaluating SpiceGrinder for real production use, you’ll eventually hit this question: how many runtime instances do you actually need to license? The honest answer is usually “fewer than you’d guess” — but getting there means understanding what actually needs a license, since it’s not what most licensing models train you to expect.

A runtime instance is a process actively generating data for real use. It’s based on the processes, not the number of people using it or the number of models to be run. Building a model, testing it, iterating on it in the GUI or with a quick CLI run — none of that needs a runtime instance license. A runtime instance license only comes into play when a process loads a model specifically to generate data that’s actually going to be used — feeding a downstream system, populating a test environment, whatever your real workload is.

Licenses are concurrency-based. It doesn’t matter how many models you have, how many people are involved, or how many times a day you generate data. What matters is how many of these production-use generation processes are running at the same moment. A single license can cover a process that runs at 9am and a completely different one that runs at 2pm, even on a different server, as long as those runs never overlap.

A process holds that license for as long as it has a model loaded for generation — start to finish. For a one-shot grind run, that’s the whole invocation, since it loads a model and exits when it’s done. For a longer-running process, it’s however long that process keeps a model resident.

Practical concerns: If your workflow spins up a separate process every time something needs data — a CI job here, a scheduled task there, a few different teams generating on their own schedules — you only run into licensing conflicts when some of those happen to overlap in time. Two data-generation jobs that both kick off during the same five-minute window might need two concurrent licenses for that window, even if neither one runs for more than a few seconds, if they wind up overlapping.

That’s easy to hit by accident once you have more than a couple of independent, scheduled, or parallel workflows — not because you actually need that much throughput, but because of scheduling coincidence.

This is exactly the problem the Service API solves. Instead of many short-lived processes each briefly holding their own license, you run one long-lived service that holds a single license for as long as it’s up — and it can serve many separate generation requests through that one process, including requests against different models, cached and switched between as needed. Work that used to mean five separate processes competing for five concurrent licenses becomes five requests handled (sequentially) by one already-licensed process.

For most teams — even ones with several models and several consumers — a single Service instance can cover the whole workload, because it consolidates what would otherwise be scattered, occasionally-overlapping demand into a single continuously-running license.

The most common cases where you’d actually want more than one runtime instance are:

1. You need real, simultaneous generation throughput beyond what one process can keep up with. Since a single instance handles its work one job at a time by design, if your volume genuinely requires parallel processing rather than just non-overlapping scheduling, you can add additional processes (each with their own license) as needed.
2. You have different environments that are not permitted to share servers by your policies or network topology.

In short: license for the peak number of production-use processes you’ll ever have running at once, not the number of models, people, or jobs you run over time — and if that peak is driven by scheduling rather than real throughput needs, the Service API is very likely to bring it down to a very low number, possibly even one.

Check out our post on monitoring SpiceGrinder to see how the auditing feature can help you track your license usage.