Forge pricing for jira plugin that indexes properties

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:

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

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