Sneak peak: global lock service

As part of our Postgres rollout, we needed global locking for leader election.

We launched a shared Consul cluster to make this work, and are using the ACL system to provide app level access to it. To enable it, add this to your fly.toml:


This will inject a FLY_CONSUL_URL environment variable in your app, like this:


There’s no username on that URL (note the leading :), but the token is in the password field, and the path section (/app-name-23sxdf) is the prefix that token has write access to.

The ACL policies for apps look like this:

key_prefix "app-name-23sxdf/" {
  policy = "write"

node_prefix "app-name-23sxdf/" {
  policy = "write"

session_prefix "app-name-23sxdf/" {
  policy = "write"

This lets you register with the catalog, write to the KV store, and create lock sessions for your registered nodes. You can’t run a consul agent with it, but you can make consul API calls.

Here’s how you’d register an agent:

curl -H "X-Consul-Token: <token>" \
    "" \
    -XPOST \
    -d '{"Name":"app-name-23sxdf/kurt","Address":"fdaa:0:1:a7b:ab6:0:a:2"}'

We’re using it with Stolon. We forked docker/libkv to add support for Consul auth + ACLs, then had to fork Stolon to use the new libkv. Fun times.

If you are trying to launch clusters that need elections on Fly, this might be a useful service for you. Feel free to poke at it and see how it goes.


Will all edge locations be part of the same datacentre as defined by consul? Curious to know how the KV store will work; e.g. single global store, regional stores, replicated stores, etc.

Right now we just run this as one datacenter. We’ll probably run one per continent, possibly one per region in Singapore/Sydney/Tokyo/HKG. I don’t think federated sessions ever shipped in Consul.