Built-in HTTP Proxy
You can only use the built-in HTTP proxy described here for running LiteFS on Fly.io. If you’re running LiteFS outside of Fly.io, you will need to use an alternative method for configuring writes to the primary node!
LiteFS uses a single primary node for writing data and that primary node replicates out to other replica nodes for fast reads. This poses two issues for applications:
Requests that write data must be forwarded to the primary.
Requests that only read data should wait until previous writes have been replicated to a node before reading from that node.
LiteFS provides a built-in HTTP proxy server that can handle these issues automatically for most web applications as long as they follow some common idioms:
GETrequests should not perform write operations (e.g.
Clients must have cookies enabled.
The built-in proxy is a thin layer in front of your application. It inspects HTTP requests and performs intelligent routing depending on the type of request and the node’s status.
All HTTP requests that go to the primary are handled normally since the primary node can perform writes and always has the latest data. The proxy simply adds a cookie to the outgoing response from the primary to tag the current replication position.
The proxy handles requests a bit differently on replicas since they cannot write
data and they may lag slightly behind the primary. First, write requests
PUT, etc) are forwarded to primary node using
This ensures that all writes occur on the primary.
For read requests (
GET), the replica will wait for the replication position on
the database to catch up to the position stored in the cookie set by the primary
server. This ensures that any writes forwarded to the primary are visible by the
replicas before processing the request.
By default, the proxy is disabled. You can enable it by setting fields in the proxy section of the config:
proxy: # Bind address for the proxy to listen on. addr: ":8080" # Hostport of your application. target: "localhost:8081" # Filename of the SQLite database you want to use for TXID tracking. db: "my.db"
You’ll also need to ensure that your application is running on the target port,
8081 in this example. Additionally, make sure your internal port
is configured to the proxy’s bind port in your
[[services]] internal_port = 8080 protocol = "tcp"