A Store is the top-level container in OpenFGA. Think of it as one project or one workspace. Everything for one authorization setup lives inside it, and nothing leaks out to other stores.

You need a boundary. Without one, all your rules and data would sit in a single shared pile. Stores give you clean separation.

Each store is fully isolated. A Check inside store A can never see tuples that live in store B. This lets you keep different apps, or different environments (dev, staging, production), completely apart.

A store holds three things.

The rules. A store can hold many versions of the model over time. Each version gets its own model ID. When you change the rules, you write a new version; the old one stays. Your tuples keep working, and you can point a Check at a specific model version if you want.

The data. All the small facts like:

(account:123, assignee, role:manager)

This is usually the biggest part, sometimes millions of rows.

Saved tests. You write example questions with expected answers, like “manager should be allowed to approve → true”. They let you check that your model still behaves correctly after a change.

Every store has a unique store ID (a long string). This ID is the key to everything.

1. Create a store once. OpenFGA gives you back its ID.
2. Scope every API call to that ID (write a model, add tuples, run a Check).
3. Isolate by design. One store's data never mixes with another's.

This is a design choice, not a fixed rule. Common patterns:

• One store per environment: separate dev, staging, production. Safest start.
• One store per application: give each unrelated app its own store.
• One store per tenant: strong isolation, but more stores to manage.
  Many teams instead keep all tenants in one store and separate them using object IDs (like organization:acme vs organization:globex).

<note tip> A good default: start with one store per environment, and only split further when you have a real reason. </note>

• OpenFGA official site
• Create a store