Engula Configuration Guide#

Engula uses configuration syntax compatible with Valkey 7.2. When migrating from Redis 7.2, common settings can usually be understood through the same compatibility model. Except for the engula-* directives documented here, common settings such as networking, persistence, replication, memory eviction, ACL, TLS, and logging primarily follow Valkey 7.2 configuration parameters.

In practice, migration rarely requires rewriting an existing redis.conf. Start from the current Redis / Valkey configuration, then add Engula-specific directives only where they are needed, such as whether to enable Engula RDB after migration, earena size limits, or license file path.

Configuration Files#

Engula can start with built-in defaults and no configuration file. That mode is useful for quick tests, but production deployments should use an explicit configuration file and keep runtime changes synchronized with configuration management.

Typical startup:

1engula-server /etc/engula/engula.conf

If you already maintain a Redis / Valkey configuration file, use it as the main file and include a small Engula fragment near the end:

1include /etc/engula/engula-only.conf

Keeping the include near the end makes override order easier to reason about. General Redis / Valkey settings stay in the main file, while Engula-specific settings stay in a focused fragment that is easier to audit during upgrades.

When running multiple instances, isolate at least these settings per instance:

Directive Format#

Configuration directives use a whitespace-separated format:

1keyword argument1 argument2 ... argumentN

Examples:

1replicaof 127.0.0.1 6380
2requirepass "hello world"
3engula-rdb 1

Quote arguments that contain spaces:

1engula-license "/etc/engula/customer license.lic"

For the full list of common directives, see the Valkey 7.2 configuration documentation. Use that link as a reference for common syntax and parameters; concrete availability, defaults, and Engula-specific directives are governed by the versioned configuration files linked below.

Command-Line Overrides#

Every configuration directive can also be passed on the command line. The command-line form uses the same directive name with a -- prefix:

1engula-server --port 6380 --replicaof 127.0.0.1 6379 --engula-rdb 0

Command-line overrides are useful for tests, container entrypoints, and temporary changes. For production, keep the final values in configuration files.

Runtime Configuration#

Engula supports the Redis / Valkey runtime configuration workflow:

1CONFIG GET <pattern>
2CONFIG SET <parameter> <value>
3CONFIG REWRITE

Not every directive is runtime-modifiable. Directives marked as startup-only must be set in the configuration file before the instance starts.

Engula-specific directives are hidden configs. They are not returned by CONFIG GET *, so query them by exact name:

1CONFIG GET engula-rdb
2CONFIG GET engula-earena-max-value-size

Runtime change examples:

1CONFIG SET engula-rdb 0
2CONFIG SET engula-earena-max-value-size 16777216
3CONFIG SET engula-disable-string yes

engula-rdb and engula-disable-* apply to Engula 2.2 and later; for older versions, use the configuration file for that version as the reference.

Runtime changes are not automatically written back to the configuration file. To persist them, prefer updating the source configuration in your configuration-management system. If you use include fragments or automated config management, verify where and how CONFIG REWRITE writes the file before using it in production.

Versioned Configuration Files#

Treat the linked configuration text files as the source of truth for concrete directives. This page explains how to choose and use them; when directives are added or changed, update the relevant .conf file first.

Configuration files for Engula 2.2: full.conf and engula-only.conf.

Configuration files for Engula 2.1: full.conf and engula-only.conf.

Configuration files for Engula 2.0: full.conf and engula-only.conf.

full.conf is the complete Engula configuration file for the selected version, including Redis / Valkey compatible settings and Engula-specific settings. engula-only.conf contains only engula-* directives and is intended for use through include after an existing Redis / Valkey configuration.

The available engula-* directives differ by version. During upgrades, do not copy an old Engula fragment directly into the new version; start from the target version's engula-only.conf.

Common Configuration Scenarios#

Minimal Standalone Instance#

1port 6379
2dir /var/lib/engula
3logfile "/var/log/engula/engula.log"

Use Engula RDB#

1engula-rdb 1
2save 900 1
3save 300 10
4save 60 10000

With engula-rdb 1, local SAVE / BGSAVE use the Engula RDB format. This mode is mainly intended to improve RDB SAVE / LOAD operational efficiency after all cluster nodes have been migrated to Engula. During migration and rollback observation, if Redis / Valkey 7.2 nodes still need to remain available as a fallback path, use traditional-RDB compatibility first and evaluate Engula RDB after the migration is complete.

Replication paths also consider whether the peer declares Engula RDB capability and may fall back to traditional RDB when needed; still validate SAVE / LOAD and replication behavior in a test environment before production rollout.

Use Traditional RDB#

1engula-rdb 0

Use traditional RDB when handing files to native Redis / Valkey tooling, debugging across versions, integrating with a path that does not support Engula RDB yet, or keeping Redis / Valkey 7.2 nodes available during migration / rollback observation.

Limit earena Eligibility#

1engula-enable-earena yes
2engula-earena-max-value-size 16777216

Values above the threshold fall back to normal object storage. This is useful when workloads contain many large values and you want to control which records enter earena.

engula-earena-max-value-size applies to Engula 2.1 and later; engula-enable-earena and engula-disable-* apply to Engula 2.2 and later.

Use Engula as a Cache#

1maxmemory 1gb
2maxmemory-policy allkeys-lru
3appendonly no

Cache mode uses Redis 7.2 compatible configuration. Once the memory limit is reached, keys are evicted according to the configured policy. Engula's earena, compression, and RDB settings can be used together with cache settings.

Best Practices#

• When reusing an existing Redis / Valkey configuration, keep common settings unchanged first and add only the required engula-* directives.
• Give each instance its own dir, logfile, and port to avoid overlap in replication or cluster deployments.
• Do not rely on no-config startup in production; keep configuration in version control or a configuration management system.
• Use CONFIG GET <exact-name> for hidden configs. Do not use CONFIG GET * to decide whether an engula-* directive exists.
• Runtime changes to engula-disable-string, engula-disable-set, and engula-disable-hash (Engula 2.2+) affect later writes only; existing data is not migrated immediately.
• Validate RDB format, license, and compatibility-level changes on a test instance before applying them to production replication or client traffic.

Relationship to Redis 7.2 Configuration#

Engula is designed for low-cost migration: the current version primarily follows Valkey 7.2 configuration parameters, and Redis 7.2 configurations can usually be migrated through the same compatibility model. Engula-specific capabilities live under the engula-* namespace.

For directives not explicitly covered on this page, use the Valkey 7.2 configuration documentation for common defaults, behavior, and tuning guidance; the target Engula version's configuration file remains the final reference.