Preview: Managed Upstash Redis with read replica support

We just switched on Managed Upstash Redis, a private, Redis compatible database, via our partnership with the admirable team at Upstash. You can deploy Upstash Redis today in any Fly region, both as a primary and a read-only replica. Give it a try with:

flyctl redis create

We want your feedback!

A Few Interesting Details

Upstash Redis on Fly is different than some other Redis offerings you’ll find in the wild. Check all the details in the docs. Briefly:

Your database is not exposed to the public internet! Each database is deployed on Fly infrastructure. It’s visible to your entire Fly organization via a private IPv6 address that routes traffic to the geographically nearest replica (or primary).

When using read replicas, you can use a single connection URL for all your app instances. Writes are automatically forwarded by Upstash Redis to the primary.

Upstash Redis is compatible with the Redis API, but isn’t stock Redis. Check their docs for details on supported commands.

Managed Services on Fly

We’re trying something new at Fly. Customers want managed services. But running managed services is a whole business in itself. And using internet-exposed services on other platforms, from Fly apps, has its downsides: potential latency in distant regions, exposure to attacks, and so on.

A happy middle path: providers provision services on Fly, for Fly customers. We’ve been working on plumbing to make this happen, like the Machines API and Flycast private load balancing. This gives providers just enough power to tightly control their deployments, and to expose their services to customers in a simple, secure fashion (and vice-versa).

Your feedback will help us figure out how upcoming integrations will work.

Thanks for your time.


This looks pretty cool! I took a look at it and was wondering if you’re able to provide a bit of information on how things work.

Does this mean that the servers/fly machines are inside the provider organisation? Or are they in the customer organisation but hidden?

If the servers are inside the provider organisation, does this mean that you have cross-organisation private networking? I see you mention the flycast private loadbalancing but currently this doesn’t work cross-organisation AFAIK.

I also noticed that the domain is used for the redis urls. This domain isn’t queryable publicly, only inside fly. Is this a private/internal custom DNS feature that’s currently hidden or is this custom functionality only for upstash/providers?


I think the services from partnership should add a naming prefix to distinguish them from the services provided by fly.

When I saw fly redis create, I thought it was a fly managed service like fly postgres create.

Have been running the upstash redis for job queues, cache and session storage. All very nice and very performant! I am missing seeing “my” cache servers in the dashboard however

Hello! I created a new app and used the managed redis but I’m facing extreme latency from all commands, below is a small sample from NewRelic. I just created and pointed the URL to the created instance, maybe I missed some config?

Both the app and the primary region of Redis are the same (dfw) so I would not consider that it’s “normal” this timings.

Right now I returned to point my old Heroku instance (which has low latency as expected from Redis) while I figure it out the problem

If you have replicas in secondary regions, could you try disabling them to see if it helps? In this preview stage, we may have latency issues with larger requests, so it would be good to know their size, roughly.

Hi @jsierles , thank you for your reply. I tried removing the replicas but the latency stays the same. I’m only using Redis as cache store for a small Ruby objects (maybe around 4kb each). I think the problem is not related to the objects since I get high latency in all redis calls (even excluding get/set , in the screenshot you see connect/auth they have the same high latency). Any ideas ?

Is there a plan for the Upstash Redis offering to expose metrics like the rest of the Fly apps? I’m obsessed with metrics, so I’d love to have those available. I’ve tested and don’t seem to see any Redis metrics available from the Prometheus endpoints.

I know this is still in preview, and you probably have all kinds of exciting stuff planned, but am curious mainly for my knowledge as I decide whether to adopt the service.

Ideally, the metrics for the following would be available:

  • records
  • data usage
  • connections
  • operations

The above would be especially useful when trying to select a plan once we get some use out of the service.


This looks neat.

Per docs:

If you’re using Redis as a fast, region-local cache, setup separate databases per-region and enable object eviction.

Matches my usecase.

Pricing wise… does that mean, if I setup one 100MB Fly Redis in each Fly region, I can issue 10K commands (per day) for free to all of those?

I was wondering why not KeyDB, and it looks like they have been snapped up (acquired) by a bigco.

I love the idea of having these kinds of services managed. Maybe MySQL, PostgreSQL, Elasticsearch cloud or Meilisearch could be next, as to not have to worry about managing them., planetscale, etc.

1 Like

We can take a look. Could you start a new post/thread for tracking this issue, with all the details you posted so far? Thanks.

Yes, we’ll be exposing metrics from Upstash, which should include these values and more.

1 Like

Yes, you’d get 10k free commands per day for each instance.

KeyDB is pretty cool, but in this case we were looking for a fully managed, Redis-compatible service. Upstash fit the bill, given they already designed their product for - and are planning features for - multi-region support.

FWIW, we did try KeyDB, but it fell over quickly in a multiregion setup. This is why we want managed services:we can focus on making the underlying platform great, while passing the great work others have done on to you :smiley:


This looks great !

I am trying to set up a database on a Remix App. I can’t figured out how to properly instantiate my redis client (using @upstash/redis) with env variable for URL and TOKEN of the database

Thank you for your help

Best regards

You won’t need to use that redis client, which is based on HTTP. Upstash Redis on Fly is deployed inside the Fly network and is available over TCP. Try using a client like ioredis, with ipv6 enabled, as mentioned in this thread.

1 Like

Thank you for your reply.

I switch to ioredis. The configuration was tricky but I endup with a redis path looking like that


The IPv6 can be found when connecting locally with fly redis connect or with fly dig

The private url (with the app name) was not working when using the ip and port was

Best regards


I really hope you guys revisit pricing for Upstash.
You can only provision one free instance per organization.
Then the next pricing is 10usd per month per region. This is significantly more expensive than most Fly VMs.
Many customers have a staging and production environments. If customer wants to use Upstash then it will for sure pay at least 10usd only for Redis - and staging Redis will be barely used.
Nonetheless the pricing is also incompatible with Upstash own pricing page - they charge 0.2cents per 100k commands!

1 Like

I started playing with the free tier yesterday and I love it! Super easy to set up and works like a charm.

One thing I’m not sure about is backups. Is there a way to make backups, and even automate periodic backups? I can see this is an existing Upstash feature but it seems like we can’t access the Backup button through the Fly integration.

Any plans on adding the upstash VMs / apps to appear in the dashboard?

Upstash Redis DBs are visible now in a tab on the main organization page. There isn’t much info there, but soon we’ll be adding some basic metrics. Vote for what you’d like to see :slight_smile: