Plan locks and live collections

Collections unlocked by a plan, and how fields change once a collection is live.

Collections locked to a plan

A collection can be locked to plans or products, on top of its safety rule: only a person who holds one of them reads or writes it. The setting is requiresAny: up to 10 access keys (["access:pro", "access:studio"]), any one of which opens it. With no requiresAny, the default, the collection is not locked. Your human ticks plans and products in its Unlocked by row on its page in the dashboard's Data, or names them under "unlockedBy" in the collection file, and Gemmein keeps their keys. A person who holds none of them gets 403 entitlement_required. See Payments.

Fields in live collections

In Development, collections take their fields from your writes. When you go live, the fields are fixed on community, shared and direct, the safety rules where people write into each other's view. Live writes there with a field the collection does not have are refused (invalid_shape), and links must point at records that exist (unknown_record). Every other safety rule stays free-shape forever.

Development continues after you go live, and Development collections keep taking new fields. When your next version adds fields that Live does not have yet, run npx gemmein go-live again: it presents each change for you to approve. Once promoted, Live accepts the new fields. Until then, unknown fields are refused (invalid_shape), so newly generated code cannot silently change what live data accepts. shared, community and direct promote the same way. Fields already fixed never change, and every promote run is recorded in the audit log.

Field defaults and how they read back through get, list, expand and where: see the reference. The invalid_shape error and what to do about it: see Errors.