Skip to main content
Most of the configuration options for LiteFS are set via a litefs.yml config file. You can find a fully-commented version of litefs.yml in the LiteFS repository.

Config file search path

LiteFS will search the following paths to find the config file:
  1. The current directory: ./litefs.yml
  2. The home directory: ~/litefs.yml
  3. The system configuration directory: /etc/litefs.yml
You can also explicitly set the config path using a command line flag:

Environment Variables

LiteFS can evaluate environment variables within the configuration file. Variables can be referenced using either the $MY_VAR syntax or the ${MY_VAR} syntax. Basic string equality & inequality expressions can also be evaluated using either single or double quotes:
Environment variable evaluation can be disabled by specifying the -no-expand-env flag from the command line arguments.

FUSE directory

LiteFS uses a FUSE directory mount to intercept Linux file system calls to track when SQLite transactions start and end so they can be replicated. The recommended path is /litefs and it is the directory your application should use when interacting with the database.

Internal data directory

LiteFS acts as a passthrough file system so all your database files still need to be stored internally on a regular file system. This internal data directory should be saved on a persistent volume so you don’t lose your data between restarts. LiteFS also stores transaction files (called LTX files) in this directory. These files are periodically removed through an internal process called retention enforcement.

Supervisor / Exec

LiteFS provides the option to run as a supervisor to another process. Typically, this would be the command you run for your application. This is useful so that LiteFS can mount itself and connect to the cluster before starting your application. It will pass signals to your application and it will automatically shutdown when your application shuts down.

HTTP API Server

LiteFS communicates with other nodes’ API over HTTP. This can be configured in the http section of the config. The default port for LiteFS is 20202. This port MUST NOT be publicly accessible.

HTTP Proxy Server

LiteFS includes a built-in HTTP proxy server that handles data consistency and request forwarding for most web applications. It is disabled by default but can be enabled by specifying a bind address & target.

Lease Management

Leadership is managed by using an external lease system. This can be done using either Consul or by specifying a single, static primary node.

Consul Leasing

Consul is the recommended lease backend as it allows leadership to change when the primary node stops. The url and advertise-url are required so that the node can connect to Consul and broadcast its LiteFS API URL.

Static Leasing

If you do not wish to run a separate Consul instance and you can tolerate downtime of your primary node, you can run LiteFS with a static lease. A static lease means that only a single, fixed node will ever be the primary. There is no additional configuration section for static leasing. Simply set the lease.candidate config field to true on the primary and false on the replicas. You will need to set lease.hostname and lease.advertise-url on the primary as well.

Other options

Exit on error

Skip sync

Trace Log

The trace log provides a very low-level log of events inside LiteFS. It is typically only used for debugging issues and is turned off by default. This log can produce a lot of disk IO when enabled.