Custom docker Image = Openfga server + internal database

[jbolanosg]

Hi, I want to use OpenFGA for authorization in a new Next.js project running on Kubernetes. I plan to configure OpenFGA as a sidecar to my application to reduce latency. For this, I'm thinking of creating a custom Docker image based on the official OpenFGA image and adding the following steps:

Install SQLite inside the container.

Install the OpenFGA CLI.

Create a shell script that does the following:

a. Connect to a GitLab repository (URL provided through an environment variable) to fetch the latest version of the model to use in OpenFGA (model.fga) and default tuples to initialize (tuples.json).

b. Create the SQLite database (or drop and recreate it if it already exists).

c. Start OpenFGA with:

nginx
Copiar
Editar
openfga migrate --datastore-engine sqlite --datastore-uri 'file:/path/to/openfga.db'
openfga run --datastore-engine sqlite --datastore-uri 'file:/path/to/openfga.db'
d. Use the OpenFGA CLI to complete the configuration:

pgsql
Copiar
Editar
fga store create --model model.fga # using the model from GitLab

for each tuple in tuples.json:

fga tuple write <<tuple_content>>
e. Retrieve from an environment variable the URL of an API that returns additional tuples (role-to-org, user-to-role relationships). Use the Node.js SDK to insert these tuples into OpenFGA. This step is meant to emulate the behavior of OPAL_DATA_CONFIG_SOURCES in OPAL Server. See: https://docs.opal.ac/getting-started/running-opal/run-opal-server/data-sources

f. Implement a polling logic (similar to OPAL_POLICY_REPO_POLLING_INTERVAL) to periodically refresh the model and default tuples from GitLab. After fetching, compare with previous versions and apply changes to the OpenFGA server using the Node.js SDK.

g. Similarly, implement polling for the external API (step e), compare results with previous data, and apply differences to the OpenFGA server.

For data updates, in my particular case, we plan to use Keycloak as the IAM and will rely on the extension at:
👉 https://github.com/embesozzi/keycloak-openfga-event-publisher

The goal is to start OpenFGA with fresh model + tuple data, and allow frequent updates using the strategies described above—similar to how OPAL Server + Client operate, but using SQLite internally within the pod. This way, we achieve millisecond-level authorization checks, no need for a centralized database, and no external dependencies.

If this works, we could implement a sidecar OpenFGA server with only internal SQLite that refreshes itself periodically via GitLab and an external API linked to Keycloak—effectively serving as a GitOps-style self-updating sidecar.

Do you see this as viable? Are there any performance or security risks with this kind of implementation?

I’m asking because it seems logical and could be a powerful, dependency-free solution—having OpenFGA run as a sidecar with optimal performance.

I'm new to OpenFGA, but I really like the project and its authorization modeling approach. I'm seriously considering replacing our initial plan using Permit.io (GitOps-based approach with OPAL Server + Client) with this solution. If the above works, it would greatly reduce complexity.

Thanks in advance to the OpenFGA experts for your insights. If this sounds feasible, I’d love to move forward with creating this custom image.

[aaguiarz]

Hi @jbolanosg

If your data does not change frequently are you are OK with a delay between the moment the data is updated in the central OpenFGA server until it's available in all OpenFGA nodes, that can work. However, the solution will have more moving parts if you just call OpenFGA directly. I'd only take that path if the latency you get from a remote call is really not acceptable for you. Simpler solutions usually work better, and most OpenFGA customers are usually OK with the additional latency. If you the amount of data is not large and does not change much, latency should be pretty low.

An approach you can try, instead of refreshing tuples periodically, is to have each OpenFGA server in a sidecar using the /changes endpoint to retrieve the tuples that were modified, and write them locally. This will be more efficient than reading all tuples.

If the amount of data is not big, you can bootstrap your OpenFGA sidecars by reading the authorization model from the server, writing it to the local OpenFGA, and then use /changes to get all the data.

If you end up giving this approach a try let us know. We are not aware of anyone doing it, but it can be useful with low data volume and low change frequency.

[jbolanosg]

Thank you for your response. However, having a central database makes our implementation more difficult, which is why we're considering using SQLite inside each pod. In fact, a new idea we’re exploring is building a Docker image that bundles the OpenFGA executable together with SQLite, and handling the synchronization logic using Node.js and the Node.js SDK.

Regarding tuple updates or bulk loading, this would happen daily or every few hours to ensure that the OpenFGA server has the same data in its database as Keycloak. Any data changes that occur between bulk loads would be sent via events from Keycloak, so in theory, the tuples in the OpenFGA server should always match what's in Keycloak.

I’d appreciate it if you could point me to where I can read more about the /changes endpoint. Also, is there a recommended way to compare the current tuples in the OpenFGA server with the full set of tuples retrieved via the API that queries Keycloak?

[aaguiarz]

Can you expand why a central database would make the implementation more difficult? You still need to have maintain one for synchronizing from KeyCloak, correct? The difference would be making a call to the sidecar vs making a call to the central server.

You can learn about the changes endpoint here https://openfga.dev/api/service#/Relationship%20Tuples/ReadChanges, or here https://openfga.dev/docs/interacting/read-tuple-changes

If you use the /changes endpoint you would not need to compare the current tuples. If you want to compare them, you'd need to use the /read API to get the data from the local instance, the /read API for the remote database, and compare them. It does not seem simple/efficient. With /changes you apply the writes/deletes from the central database to the local one.

[jbolanosg]

What I understand is that the central database must be queried frequently to perform authorization checks, making it a single point of failure in the authorization process. Therefore, the database selected for OpenFGA must be highly available to ensure that authorization can be executed whenever required. In summary, there is a dependency between authorization and the availability of the central database.

In our company’s context, we only have one PostgreSQL database with high availability, hosted in Azure, and it would be the only option to configure with OpenFGA. However, the following context suggests that this setup would introduce latency in OpenFGA operations:

We are defining an authorization solution as the standard for all our new applications (microservices on Kubernetes) and legacy applications (WinForms), which currently run on our internal network. We plan to migrate their current authorization method to OpenFGA or the selected alternative.

We will have applications running on AKS in Azure, which will work well with the centralized PostgreSQL database mentioned earlier.

We will also have applications running on OKE in Oracle OCI (our standard database is Oracle, and we are migrating to PaaS on Oracle OCI). If these applications use OpenFGA (as a sidecar) against the PostgreSQL database in Azure, they would experience poor response times and increased authorization latency.

Additionally, OpenFGA would be the authorization solution used in Docker containers across each subnet of our on-premises network in Colombia, replacing the current method for our legacy WinForms applications. If these Docker containers in different locations in Colombia connect to the Azure database, we believe the response times would not be acceptable.

Another point we’ve considered is that the database used by OpenFGA only stores the model, tuples, and any changes since the last load, which can be constructed from external sources (Keycloak and a Git repository). Therefore, we could consider that an embedded SQLite database within the OpenFGA container would be sufficient and free of single points of failure. With that in mind, every time the OpenFGA container starts, we can initialize the SQLite database from:

Model → Git repository.

Static tuples → Git repository.

Dynamic tuples (e.g., user membership changes to a client role in a client ID in Keycloak), which can be obtained from Keycloak events. In this case, we need to develop a component that distributes the changes from Keycloak events to all interested containers in AKS (Azure), OKE (Oracle OCI), and multiple Docker containers on the on-premises network. We plan to develop this component using DAPR (https://dapr.io/) with the Pub/Sub pattern.

All of this is why we are considering the OpenFGA solution with an embedded database inside the Docker container.

Sorry in advance if I don’t explain things clearly — Spanish is my first language.

[aaguiarz]

Hi Jorge,

Thanks for the explanation, I understand the rationale now.

I think that creating a service thats reads from the central OpenFGA service and reads to the local one using the /changes endpoint is the best approach. It would make sense at some moment to have that as a standard component in the OpenFGA project, so it can be deployed in the sidecar too, but I don't think we'll be able to spend time on it soon.

If you want to further discuss the scenario feel free to add me in Linkedin (it's in my Github profile) and we can have a quick call in Spanish :)

Regards,

Andres