rqlite 8.36.16 adds Docker configuration for foreign-key enforcement
ENABLE_FK adds the existing foreign-key flag to the container command. Its presence-based interpretation makes false-looking values a configuration trap.
The most consequential detail in rqlite's new Docker setting is how it reads a value. rqlite 8.36.16, released on 3 April, lets the container entrypoint enable foreign-key constraints through ENABLE_FK. The script checks whether the variable is nonempty. It does not parse a boolean, so the string false enables the flag just as 1 does.
This is a small packaging change to a behavior the server already supports. I appreciate rqlite's compact deployment model, and environment-based configuration makes that model easier to express in container definitions. The exact interpretation still belongs in the deployment's configuration contract, especially when the setting changes which writes the database accepts.
The entrypoint adds an existing server flag
The implementing commit adds an initially empty fk_flag variable. If ENABLE_FK is nonempty, the script sets that variable to -fk. It then includes the result in the generated server command.
A Docker environment entry can therefore request enforcement with a value such as the following. This fragment is an input to the container environment, not SQL.
ENABLE_FK=1
Leaving the variable unset or empty omits this generated flag. Setting it to 0, false, or no still supplies a nonempty string and therefore adds -fk. A configuration template that always emits textual booleans needs to account for that rule.
The versioned entrypoint has separate handling for the default run command and arguments beginning with a flag. Default startup constructs the server command with the data directory. Supplying flags merges those options with the generated command. Other commands execute as supplied, so the environment variable is meaningful through the entrypoint paths that construct the server invocation.
The Dockerfile installs this entrypoint and uses run as its default command. That connection explains why the new variable works for the normal image startup path. It is shell translation into a server option, rather than a new environment-variable parser inside SQLite.
Declaring a relationship and enforcing it are separate
SQLite's foreign-key documentation distinguishes a schema declaration from runtime enforcement. A foreign key expresses a relationship between a child row and a parent key. Runtime configuration determines whether SQLite checks that relationship during modifications.
The database opening code in this release passes the foreign-key setting into the data-source names for its read-write and read-only handles. It also retains the setting on the database object. The Docker addition supplies the existing server-level choice through a different deployment input.
This explains why adding the environment variable can affect an unchanged schema. A table may already declare its references. Turning on enforcement makes those declarations participate in the acceptance of subsequent changes. The release does not need to rewrite the table definition to make that difference observable.
The distinction also prevents a misleading upgrade claim. Installing this image does not mean every container automatically enables foreign-key enforcement. The entrypoint adds the flag only when the variable is nonempty. The patch gives deployment configuration a way to choose the behavior, and leaves the absence of that choice meaningful.
The setting must be consistent with the application model
Foreign-key enforcement places part of the application's relational assumptions inside the database engine. When the engine rejects a child value without a matching parent, the application receives a failure at the write that violates the relationship. Without enforcement, application code has to maintain that relationship by its own means.
That is why this setting deserves more attention than an ordinary convenience variable. A deployment definition can change accepted writes while the application binary and schema remain identical. Configuration review should treat the chosen enforcement mode as part of the database's behavior.
My preference is to make that decision visible in the container definition. The new environment setting supports that without requiring an operator to replace the entire entrypoint command. It also keeps the actual server behavior represented by the existing -fk option.
The implementation is deliberately small. It neither translates false-looking words nor adds a special conflict check for a separately supplied foreign-key flag. The practical configuration should avoid depending on undocumented precedence between contradictory inputs. A single explicit choice is easier to understand from the generated command.
The patch belongs to packaging
The release changelog identifies the Docker environment support as this release's change. Its date heading contains an invalid day, while the GitHub release supplies the usable 3 April publication date. Nothing in the patch changes the syntax of a foreign-key declaration or implements a new constraint algorithm.
For container users, the result is a direct mapping from a nonempty ENABLE_FK value to -fk in the server invocation. That mapping is the behavior to preserve when templating deployment files. An empty or absent variable leaves the generated command without that flag, while any nonempty value requests enforcement.