To connect your TypeScript permissions file (written in the Ory Permission Language, OPL) to your self-hosted Ory Keto instance, you need to follow these steps: 1. Write Your Permission Model in OPL (TypeScript Subset): - Create your permission rules in a

.ts

file using the OPL syntax. This file defines your namespaces, relationships, and permissions as TypeScript classes and functions. For example:

typescript    import { Namespace, Context } from "@ory/keto-namespace-types"     class User implements Namespace {}     class Document implements Namespace {      related: {        owners: User[]        editors: User[]        viewers: User[]        parents: Folder[]      }       permits = {        view: (ctx: Context): boolean =>          this.related.viewers.includes(ctx.subject) ||          this.related.editors.includes(ctx.subject) ||          this.related.owners.includes(ctx.subject) ||          this.related.parents.traverse((parent) => parent.permits.view(ctx)),      }    }     class Folder implements Namespace {      related: {        owners: User[]        editors: User[]        viewers: User[]        parents: Folder[]      }    }

[Define permissions in the OPL](https://www.ory.sh/docs/keto/modeling/create-permission-model#define-permissions-in-the-opl) 2. Convert OPL to Keto Configuration: - Ory Keto does not natively execute TypeScript files. Instead, the OPL file is used as a configuration input, which Keto parses and loads at startup. You need to place your OPL file (e.g.,

namespaces.keto.ts

) in the location specified by your Keto configuration under the

namespaces

key. - In your Keto config file (e.g.,

keto.yml

), reference your OPL file:

yaml      namespaces:        - file: ./namespaces.keto.ts

- Make sure the file path matches your deployment structure. 3. Start Ory Keto: - When you start Ory Keto, it will read the OPL file, parse the permission model, and use it to evaluate permission checks. No additional compilation or transformation is required; Keto's parser handles the OPL file directly as part of its configuration loading process. - If there are syntax errors or issues in your OPL file, Keto will report them at startup. Note: - The knowledge sources do not provide a step-by-step CLI command for uploading or compiling the OPL file for self-hosted Keto; they indicate that the OPL file is referenced in the configuration and loaded at startup. - If you are using Ory Network (cloud), you can upload the OPL file via the Ory Console or CLI, but for self-hosted Keto, it is managed via the config file as described above. For more details and examples, see the official documentation on [defining permissions in the OPL](https://www.ory.sh/docs/keto/modeling/create-permission-model#define-permissions-in-the-opl) and the [Ory Permission Language specification](https://www.ory.sh/docs/keto/reference/ory-permission-language). If you need to migrate or synchronize configurations between Ory Network and self-hosted Keto, you can use the Ory CLI to export and import configuration files, but the core process for self-hosted Keto is to reference your OPL file in the config and restart the service to apply changes [Configure Ory Permissions](https://www.ory.sh/docs/guides/cli/configure-permission-service).

The errors you are seeing indicate that the configuration format for the

namespaces

key in self-hosted Ory Keto is incorrect. According to the knowledge sources, the

namespaces

configuration expects an array of objects, each with at least a

name

and an

id

property. There is no mention in the official documentation of a

file

property being supported for loading OPL/TypeScript files directly in the config for self-hosted Keto. Here is the correct format for the

namespaces

section in your Keto config:

yaml namespaces:   - id: 0     name: groups   - id: 1     name: reports

[See example in the RBAC guide](https://www.ory.sh/docs/keto/guides/rbac#rbac-with-ory-keto) The OPL/TypeScript permission model is not referenced directly in the config file for self-hosted Keto. Instead, you define your namespaces and their IDs in the config, and then you use the OPL files for validation, development, or when working with Ory Network (cloud). For self-hosted Keto, you must define the namespace structure in the config file as shown above. Summary: - The

file

property is not valid in the

namespaces

array for self-hosted Keto. - Each namespace must be an object with at least

id

and

name

. - The OPL/TypeScript file is not referenced in the config for self-hosted Keto. If you want to validate your OPL/TypeScript namespace definitions, you can use the CLI command:

keto namespace validate <namespace.yml>

[See CLI validation docs](https://www.ory.sh/docs/keto/cli/keto-namespace-validate#keto-namespace-validate) I'm sorry, but the knowledge sources do not provide a way to directly load a TypeScript/OPL file in the self-hosted Keto config. You must define your namespaces in the config YAML as shown above.

For self-hosted Ory Keto, you do not directly incorporate the TypeScript OPL (Ory Permission Language) file into the Keto server configuration. Instead, you define your namespaces and relationships in the Keto config file (YAML/JSON/TOML), using the required structure (with

id

and

name

for each namespace). The OPL file is primarily used for development, validation, and as a reference for your permission model, but it is not loaded or executed by the self-hosted Keto server at runtime. Key points: - The

namespaces

section in your Keto config must look like this:

yaml   namespaces:     - id: 0       name: groups     - id: 1       name: reports

The config does not support a

file

property or direct reference to a TypeScript/OPL file [Reference: Configuration](https://www.ory.sh/docs/keto/reference/configuration). - The OPL file is used for: - Designing and documenting your permission model. - Validating your model using tools or the Ory CLI. - Migrating to Ory Network, where you can upload the OPL file via the Console or CLI. - For self-hosted Keto, you must manually ensure your config and your OPL file are in sync. The OPL file is not consumed by the server. If you want to validate your OPL file, you can use the Ory CLI for validation, but you still need to manually update your Keto config with the correct namespace structure. Summary: You cannot directly incorporate or reference a TypeScript/OPL permission file in your self-hosted Keto configuration. You must define your namespaces in the config file, and use the OPL file for development and validation purposes only. If you need to migrate to Ory Network, you can upload the OPL file there, but not in self-hosted Keto [Reference: Configuration](https://www.ory.sh/docs/keto/reference/configuration). If you need more details on how to structure your config, let me know!

To use parent-child traversal (such as with the

.traverse

function in OPL) in self-hosted Ory Keto, you need to: 1. Model your relationships and permissions in OPL (TypeScript subset): Write your permission model using the Ory Permission Language, where you define how permissions like

view

or

edit

can be inherited through parent-child relationships. For example, a document can be viewed if the user can view its parent folder:

typescript    import { Namespace, Context } from "@ory/keto-namespace-types"     class User implements Namespace {}     class Document implements Namespace {      related: {        viewers: User[]        parents: Folder[]      }       permits = {        view: (ctx: Context): boolean =>          this.related.viewers.includes(ctx.subject) ||          this.related.parents.traverse((parent) => parent.permits.view(ctx)),      }    }     class Folder implements Namespace {      related: {        viewers: User[]      }       permits = {        view: (ctx: Context): boolean =>          this.related.viewers.includes(ctx.subject),      }    }

[See example in the Ory Permission Language specification](https://www.ory.sh/docs/keto/reference/ory-permission-language#examples) 2. Translate your OPL model into Keto namespaces and relationships: For self-hosted Keto, you cannot directly load the OPL file. Instead, you must: - Define your namespaces in the Keto config file (YAML/JSON/TOML) with

id

and

name

. - Use the OPL file as a reference for how to structure your relationships and permissions. 3. Create the relationships (relation tuples) in Keto: Use the Keto API or CLI to create the actual relationships that represent your parent-child structure. For example: -

Document:doc1

has parent

Folder:folder1

-

User:user1

is a viewer of

Folder:folder1

This is done by creating relation tuples like:

{      "namespace": "Folder",      "object": "folder1",      "relation": "viewers",      "subject_id": "user1"    }    {      "namespace": "Document",      "object": "doc1",      "relation": "parents",      "subject_id": "folder1"    }

[See example in GitHub issue](https://github.com/ory/keto/issues/1330) 4. Keto will evaluate traversals at runtime: When you perform a permission check (e.g., "Can user1 view doc1?"), Keto will follow the parent relationship from the document to the folder and check if the user has the required permission on the parent, as defined in your OPL model. Important: - The OPL file is not directly loaded by self-hosted Keto. You must ensure your namespace config and relationships match your OPL model. - Traversal works as long as your relationships (relation tuples) and namespace definitions are set up to reflect the parent-child structure, and your permission logic (as described in OPL) is correctly implemented in your system. If you encounter issues where traversal does not work as expected, double-check your relation tuples and ensure your namespace and relationship structure matches your intended model. There are known issues and discussions about traversal in self-hosted Keto, so if you run into problems, reviewing [related GitHub issues](https://github.com/ory/keto/issues/1330) may help. In summary: You use parent-child traversal in self-hosted Keto by modeling the relationships and permissions in OPL, translating that model into Keto namespaces and relation tuples, and ensuring your data reflects the intended hierarchy. Keto will then handle the traversal logic during permission checks.

You are correct—there have been reports that the

.traverse

functionality in OPL (Ory Permission Language) does not always work as expected in self-hosted Ory Keto. For example, users have described situations where, even with the correct parent-child relationships and OPL model, permission checks using

.traverse

return

false

when they should return

true

. A concrete example from a GitHub issue shows this problem:

typescript class Document implements Namespace {   related: {     viewers: User[];     parents: Folder[];   };    permits = {     view: (ctx: Context): boolean => this.related.parents.traverse((p) => p.permits.view(ctx)),   }; }

With the following relation tuples: -

Folder:folder_1

has viewer

User:user_1

-

Document:document_1

has parent

Folder:folder_1

A check for

User:user_1

viewing

Document:document_1

returns

false

, even though the traversal should allow it. The same user can view the folder directly, but not the document via traversal. This behavior has been confirmed by others and is documented as an open issue in the Ory Keto repository [OPL traverse.(...) not working](https://github.com/ory/keto/issues/1330). Summary: - The

.traverse

function does not always work by default in self-hosted Keto, even if your relationships and OPL model are correct. - This is a known issue, and the Ory team has acknowledged it and indicated plans for improvements. If you are experiencing this, you are not alone, and it is not due to a misconfiguration on your part. You may want to follow the linked GitHub issue for updates or workarounds as they become available.

Based on the knowledge sources, the

.traverse

functionality in OPL (Ory Permission Language) is not described as an exclusive feature of Ory Network. It is part of the OPL specification and is intended to work in both Ory Network and self-hosted Ory Keto, as shown in the official documentation and examples for self-hosted Keto [Ory Permission Language specification](https://www.ory.sh/docs/keto/reference/ory-permission-language#examples). However, there are open issues reported by users where

.traverse

does not work as expected in self-hosted Keto, even when the model and relation tuples are correct. The Ory team has acknowledged these issues and indicated that improvements are planned, but there is no statement in the knowledge sources that this is an intentional limitation or an exclusive feature of Ory Network [OPL traverse.(...) not working](https://github.com/ory/keto/issues/1330). In summary:

.traverse

is not meant to be exclusive to Ory Network, but there are currently unresolved issues with its functionality in self-hosted Keto. If you rely on this feature, you may encounter problems until these issues are addressed.