Redis Server in Caddy

Give applications a Redis endpoint from the Caddy process you already run. The caddy-swytch module embeds Swytch’s Redis server, including its supported commands, data structures, and client protocol.

The integration was previously called caddy-server. Its module path is github.com/swytchdb/caddy-swytch.

xcaddy build --with github.com/swytchdb/caddy-swytch

Use the module version appropriate to your Swytch release. Its command compatibility follows the Swytch dependency it embeds.

Add the global option outside your HTTP site blocks:

{
    swytch {
        listen 127.0.0.1:6379
        password {env.REDIS_PASSWORD}
        max_memory 256mb
    }
}

Set REDIS_PASSWORD in Caddy’s environment and configure your client with the same password. For ACLs, replace password with acl_file /etc/swytch/users.acl.

To use a Unix socket, replace listen with unix_socket /var/run/swytch.sock. The path must not already exist at first start.

For DNS peers, add matching cluster_passphrase values and a join DNS name. For Cloud, use connection_secret instead of both options. See the module configuration reference.

Standalone memory-only state disappears when the runtime stops. Cloud uploads are asynchronous; starting a second instance is not a guarantee that every key has another holder.

An unchanged reload keeps the runtime, connections, and state. Configuration changes or changed ACL/TLS file contents require a restart; the module rejects those reloads while leaving the current server running.

Cluster discovery can delay Caddy startup. The module does not start Swytch’s separate CLI metrics listener, and Caddy’s automatic certificate management is not wired to the Redis TLS listener.

To share Caddy certificates, configure caddy-storage separately. Check dependency compatibility before building both modules into one binary.