Forge pricing for jira plugin that indexes properties

Pierre Ibrahim

Hello all,

I'm wondering if I can get some clarity around this topic as the Forge cost estimator assumes the developer knows the usage of their plugin.

I'm working on a very small plugin that would only index space attributes in JIRA so they can be JQL'd.

The entire plugin is just a manifest.yml file that declares the attributes so they be indexed. Over time we may add more attributes to the index.

The plugin itself does nothing else. It will not be deployed to the marketplace, it'll only be deployed on my employer's JIRA sites.

What would the forge cost be in this instance? The only close thing I can find on the estimator is the "Key Value Store", but I'm not sure of the storage needed for reads/writes to provide my employer an accurate estimate.

Any guidance here is appreciated.

Thank you

Andrey - Guenov Labs

Jean's answer is right on the cost — but I'd add the reason why, plus two things that will bite you later.

On cost. Forge moved to consumption-based pricing on 1 January 2026 and the old quota system was retired. You're billed on things you actually consume: function invocations, hosted storage (KVS / Custom Entity Store / SQL / Object Store), egress, LLM calls. A manifest-only jira:entityProperty declaration consumes none of them — the index lives in Jira's own index, and the property values live on the Jira platform, both covered by your existing subscription. So $0, and it stays $0 as long as nothing in the app runs.

The thing worth flagging: something has to write those entity properties. If that's an external script or CI job hitting PUT /rest/api/3/issue/{key}/properties/{propertyKey}, you stay at $0 on the Forge side. If you later add a product trigger or scheduled function inside the app to set them, that's where invocations — and cost — start. Worth deciding now which side of that line you want to be on.

Two gotchas on the module itself:

1. The 100-value cap. The docs are explicit: all your jira:entityProperty modules combined can't declare more than 100 values. You said you may add attributes over time, so I'd start on jira:entityPropertySetinstead — it bundles multiple properties under one module with no limit. Migrating later means re-indexing, so it's cheaper to pick it up front.
2. entityType defaults to issue. You said "space attributes," so if you mean project-level properties you need to set it explicitly:

<span>modules</span><span>:</span>
  <span>jira:entityProperty</span><span>:</span>
    <span>-</span> <span>key</span><span>:</span> <span>space-attrs</span>
      <span>entityType</span><span>:</span> <span>project</span>
      <span>propertyKey</span><span>:</span> <span>space-attrs</span>
      <span>values</span><span>:</span>
        <span>-</span> <span>path</span><span>:</span> <span>costCentre</span>
          <span>type</span><span>:</span> <span>string</span>
          <span>searchAlias</span><span>:</span> <span>costCentre</span>

and then in JQL you prefix with project: project.costCentre = "R&D", or the long form project.property['space-attrs'].costCentre = "R&D".

One last practical note: pick your type carefully, because it decides which operators you get. string gives you exact match only (=, !=), text tokenizes and gives you ~ but no exact match or ordering, number and date give you ranges and ORDER BY. Getting that wrong is the most common reason a property indexes fine but won't query the way people expect.

Docs: Jira entity property , Platform limits and usage