Use Upstash Redis with Fly.io Apps (2026)

Upstash Redis is a serverless Redis provider that works great with Fly.io apps because it decouples your Redis instance from your application’s compute.

Let’s see this in action. Imagine you have a Fly.io app that needs to store session data. Instead of running Redis on the same Fly.io machine as your app (which would tie your Redis scaling to your app scaling and introduce complexity), you can use Upstash.

Here’s a typical scenario:

Your Fly.io app, running on a virtual machine (VM), needs to fetch user session data. It makes a TLS-encrypted connection to your Upstash Redis endpoint. Upstash Redis, a separate, managed service, retrieves the session data and sends it back to your Fly.io app.

This separation is powerful. Your Fly.io app can scale up and down based on traffic, and your Upstash Redis instance can handle its own load independently. You don’t need to worry about provisioning VMs for Redis, managing its uptime, or patching it. Upstash handles all of that.

To set this up, you’ll need a few things:

1. An Upstash Redis account: Sign up at upstash.com.
2. An Upstash Redis database: Create a new Redis database within your Upstash console.
3. Your Fly.io application: Ensure it’s deployed and running on Fly.io.

Once you have your Upstash Redis database, you’ll get connection details. These typically include:

• Endpoint URL: This is the hostname and port for your Redis instance (e.g., redis://your-redis-host:6379).
• Username: Often default for Upstash.
• Password: Your database’s access password.

You’ll store these credentials securely within your Fly.io application. The recommended way to do this is using Fly.io’s secrets.

Let’s say your application is written in Node.js using the ioredis library. You’d configure it like this:

const Redis = require('ioredis');

const redis = new Redis({
  port: 6379, // Replace with your Upstash Redis port
  host: 'your-redis-host.upstash.io', // Replace with your Upstash Redis hostname
  username: 'default', // Replace if different
  password: process.env.UPSTASH_REDIS_PASSWORD, // Store this in Fly.io secrets
  tls: {
    rejectUnauthorized: true // Important for secure connections
  }
});

async function storeSession(sessionId, sessionData) {
  await redis.set(`session:${sessionId}`, JSON.stringify(sessionData));
  await redis.expire(`session:${sessionId}`, 3600); // Session expires in 1 hour
}

async function getSession(sessionId) {
  const data = await redis.get(`session:${sessionId}`);
  return data ? JSON.parse(data) : null;
}

// Example usage
async function main() {
  const sessionId = 'user123';
  const sessionData = { userId: 1, theme: 'dark' };

  await storeSession(sessionId, sessionData);
  console.log('Session stored.');

  const retrievedData = await getSession(sessionId);
  console.log('Retrieved session:', retrievedData);
}

main().catch(console.error);

On your Fly.io app, you’d set the UPSTASH_REDIS_PASSWORD secret using the flyctl CLI:

flyctl secrets set UPSTASH_REDIS_PASSWORD='your_actual_upstash_password' -a your-app-name

The tls: { rejectUnauthorized: true } option is crucial. It ensures that your application is connecting to the actual Upstash Redis endpoint and not an imposter, as it verifies the server’s TLS certificate. Upstash’s Redis instances are typically accessed over TLS, so this is a standard security practice.

The real magic here is that Upstash Redis is built on a different architecture than traditional Redis. It’s a distributed system where commands are processed by a cluster of stateless command-processing nodes that talk to a shared, durable log. This makes it highly available and scalable without the need for complex replication or failover configurations that you’d manage yourself if you ran Redis on VMs. Your Fly.io app just sees a Redis endpoint, and Upstash handles the rest under the hood.

When you connect to Upstash Redis from Fly.io, you’re not just connecting to a database; you’re connecting to a highly available, globally distributed system that scales independently of your application’s compute. This means your application’s performance isn’t bottlenecked by your database’s infrastructure, and vice-versa. You can easily upgrade your Upstash plan to handle more memory or throughput without touching your Fly.io deployment.

Understanding the underlying architecture of Upstash, particularly its separation of command processing from data storage via a distributed log, is key to appreciating its resilience and scalability benefits. This design allows for zero-downtime scaling and high availability, as new command processors can be added or failed ones replaced without disrupting data access.

The next step in optimizing your app’s data layer on Fly.io might be exploring Upstash Kafka for event streaming.