Engula Configuration Guide

Engula is fully compatible with Valkey/Redis 7.2 configuration semantics. For most production environments, you can rely directly on the official Valkey configuration documentation and apply it without modification.

Authoritative reference: Valkey Configuration Documentation

This guide provides an overview of configuration management in Engula, including file-based and command-line configuration, runtime modification, and Engula-specific configuration parameters (reserved placeholders for future extensions).

Quick Start

Engula can start without a configuration file, using built-in defaults. However, for production deployments, a configuration file is strongly recommended to ensure predictable and reproducible settings.

Default Behavior

  • Default file names: engula.conf or redis.conf (supported interchangeably)
  • Start with a custom configuration file:
    1engula-server /path/to/engula.conf

When running multiple instances (e.g., replicas, clustered nodes), adjust the following parameters for isolation:

  • dir
  • logfile
  • port (or bind address)
  • replicaof
  • requirepass
  • masterauth

Example launch:

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

Configuration File Format

Engula uses the same syntax and directive format as Valkey/Redis 7.2.

Form:

keyword argument1 argument2 ... argumentN

Examples

replicaof 127.0.0.1 6380 requirepass "hello world"

Quoting and Escaping Rules

  • Use single or double quotes for strings with whitespace.
  • In single-quoted strings, characters can be escaped with backslashes (\).
  • Double-quoted strings may additionally contain ASCII symbols represented by backslashed hexadecimal notation, e.g., "\xff".

For the full list of supported directives, refer to the Valkey Configuration Reference.

Command-Line Configuration Overrides

All configuration directives can also be passed as command-line options. The format mirrors the configuration file, except that each keyword is prefixed by --.

Example: Start a replica on port 6380 replicating a primary running on 127.0.0.1:6379:

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

Internally, Engula merges these flags with any provided configuration file into an in-memory temporary configuration, ensuring consistent treatment between CLI and file-based directives.

Runtime Configuration Changes

You can query and modify most configuration settings dynamically, as in Valkey/Redis, using:

  • CONFIG GET <pattern>
  • CONFIG SET <parameter> <value>

Important Notes

  • Not all directives are mutable at runtime.
  • Runtime changes do not automatically persist back to engula.conf.
  • To make changes permanent:
    • Edit the configuration file manually, or
      • Use CONFIG REWRITE to automatically rewrite fields that differ from the current configuration.
      • Preserves comments.
      • Omits default values that have not been explicitly changed.

Using Engula as a Cache

Engula can be configured as a high-performance in-memory cache, similar to Memcached.

Example (2MB maximum memory):

maxmemory 2mb maxmemory-policy allkeys-lru

In this configuration:

  • Keys are automatically evicted using an approximate LRU algorithm when the memory limit is reached.
  • Applications do not need to explicitly assign TTLs to individual keys using EXPIRE.

For more information about caching modes and eviction policies, see the Valkey Configuration Guide.

Compatibility with Valkey/Redis 7.2

Engula maintains full configuration-level compatibility with Valkey/Redis 7.2:

  • Identical file format and directive keywords.
  • Support for the same command-line flags (prefixed with --).
  • Equivalent semantics for CONFIG GET, CONFIG SET, and CONFIG REWRITE.
  • Default values and behaviors aligned with Valkey unless noted otherwise.

When in doubt, refer to the authoritative Valkey reference documentation.

Engula-Specific Configuration Options

The following directives are Engula-specific placeholders, reserved for future extensions. They are not required for standard operation and have no effect unless supported by your Engula build.

Option Description
engula.feature_toggle_foo Reserved for internal feature gating.
engula.storage_engine Intended to select the internal storage engine backend.
engula.compaction_tuning Placeholder for background compaction tuning.
engula.observability.exporter Reserved for configuring metrics and log destinations.
engula.threadpool.size Placeholder for customizing worker thread pool size.
engula.security.enclave_mode Intended for enabling enhanced process isolation.
engula.network.io_model Placeholder for selecting the network I/O driver (e.g., epoll, io_uring).

Future documentation will specify detailed semantics, supported values, and default parameters.

Best Practices

  • Use a dedicated configuration file per server instance to avoid port, directory, or log conflicts.
  • After startup, verify key settings using:
    1CONFIG GET dir
    2CONFIG GET port
    3CONFIG GET logfile
  • If runtime configuration changes are required, use CONFIG REWRITE to persist them before restarting.
  • In containerized or automated environments:
    • Mount engula.conf as a read-only volume, and
    • Apply environment-specific overrides with command-line flags.

Configuration Examples

Minimal Standalone Instance

port 6379 dir /var/lib/engula logfile "/var/log/engula/engula.log"

Replica of a Primary Instance

port 6380 replicaof 10.0.0.10 6379 dir /var/lib/engula-replica logfile "/var/log/engula/replica.log"

Memory-Bound Cache Configuration

maxmemory 1gb maxmemory-policy allkeys-lru appendonly no

Summary

For all non-Engula-specific configuration directives, behaviors, and defaults, consult the official Valkey documentation:

📘 Valkey Documentation – Configuration

Engula’s configuration system fully mirrors Valkey/Redis 7.2, ensuring predictable behavior and easy migration.