Swiftpack.co - Package - Mordil/RediStack

Swiftpack.co is a collection of thousands of indexed Swift packages. Search packages.


Non-blocking, event-driven Swift client for Redis.

RediStack logo

SSWG Maturity Apache 2 License Swift 5.2+ Redis 5.0

Build Status Documentation Coverage

The GitHub repository is a read-only mirror of the GitLab repository. For issues and merge requests, please visit GitLab.


RediStack (pronounced like "ready stack") is a non-blocking Swift client for Redis built on top of SwiftNIO.

It communicates over the network using Redis' Redis Seralization Protocol (RESP2).

This library is primarily developed for Redis v5, but is backwards compatible to Redis v3¹.

The table below lists the major releases alongside their compatible language, dependency, and Redis versions.

RediStack Release Swift Redis SwiftNIO SwiftLog SwiftMetrics
from: "1.0.0" 5.1+ 3.x¹ ..< 6.x 2.x 1.x 1.x ..< 3.0
.branch("master") 5.2+ 3.x¹ ... 6.x 2.x 1.x 1.x ..< 3.0

¹ Use of newer Redis features on older Redis versions is done at your own risk. See Redis' release notes for v6, v5, v4, and v3 for what is supported for each version of Redis.

Supported Operating Systems

RediStack runs anywhere that is officially supported by the Swift project².

² See the platform support matrix below for more details.


To install RediStack, just add the package as a dependency in your Package.swift.

dependencies: [
    .package(url: "https://gitlab.com/mordil/RediStack.git", .branch("master"))

Getting Started

RediStack is quick to use - all you need is an EventLoop from SwiftNIO.

import NIO
import RediStack

let eventLoop: EventLoop = ...
let connection = RedisConnection.make(
    configuration: try .init(hostname: ""),
    boundEventLoop: eventLoop

let result = try connection.set("my_key", to: "some value")
    .flatMap { return connection.get("my_key") }

print(result) // Optional("some value")

Note: Use of wait() was used here for simplicity. Never call this method on an eventLoop!


The docs for the latest tagged release are always available at docs.redistack.info.


For bugs or feature requests, file a new issue.

For all other support requests, please email support@redistack.info.


SemVer changes are documented for each release on the releases page.


Check out CONTRIBUTING.md for more information on how to help with RediStack.


Check out CONTRIBUTORS.txt to see the full list. This list is updated for each release.

Swift on Server Ecosystem

RediStack is part of the Swift on Server Working Group ecosystem - currently recommended as Sandbox Maturity.

Proposal Pitch Discussion Review Vote
SSWG-0004 2019-01-07 2019-04-01 2019-06-09 2019-06-27

Language and Platform Support

Any given release of RediStack will support at least the latest version of Swift on a given platform plus 2 previous versions, at the time of the release.

Major version releases will be scheduled around official Swift releases, taking no longer 3 months from the Swift release.

Major version releases will drop support for any version of Swift older than the last 3 Swift versions.

This policy is to balance the desire for as much backwards compatibility as possible, while also being able to take advantage of new Swift features for the best API design possible.

The following table shows the combination of Swift language versions and operating systems that receive regular unit testing (either in development, or with CI) against the current version of RediStack.

Platform Swift 5.2 5.3 5.4 Trunk
macOS Latest (Intel)
Ubuntu 20.04 (Focal)
Ubuntu 18.04 (Bionic)
Ubuntu 16.04 (Xenial)
Amazon Linux 2
CentOS 8
CentOS 7

For older versions of RediStack, view each summary below.

RediStack 1.x
Platform Swift 5.1 5.2 5.3
macOS Latest (Intel)
Ubuntu 20.04 (Focal)
Ubuntu 18.04 (Bionic)
Ubuntu 16.04 (Xenial)
Amazon Linux 2
CentOS 7
CentOS 8


Apache 2.0

Copyright (c) 2019-present, Nathan Harris (@mordil)

This project contains code written by others not affliated with this project. All copyright claims are reserved by them. For a full list, with their claimed rights, see NOTICE.txt

Redis is a registered trademark of Redis Labs. Any use of their trademark is under the established trademark guidelines and does not imply any affiliation with or endorsement by them, and all rights are reserved by them.

Swift is a registered trademark of Apple, Inc. Any use of their trademark does not imply any affiliation with or endorsement by them, and all rights are reserved by them.


Stars: 47
Last commit: 2 days ago

Related Packages


RediStack 2.0.0 Alpha 1 - 2021-02-22T18:58:35

API Docs are always available at docs.redistack.info

RedisCommand has been repurposed from the RedisCommandHandler.OutboundIn type to now a generic general-purpose value representation of a given command keyword, it's argument payload, and its expected deserialized result type.

These changes are primarily driven by the desire to support MULTI commands, as outlined in #88.

In RediStack 1.x, commands were inseparable from the method extension that generated them, and they were all eagerly executed in both sending and receiving.

By turning them into a lightweight value representation, a command can be delayed in being sent or its response in being deserialized.

As such, the following notable changes have happened:

  • RedisClient.send now accepts just a single RedisCommand instance, but otherwise behaves as before: it will deserialize the response to the RedisCommand.ResultType for you
  • RedisCommandHandler.OutboundIn is now a tuple of (RESPValue, EventLoopPromise<RESPValue>) with the first element being the fully serialized command to be sent.
  • All command extension methods on RedisClient are now static factory methods on RedisCommand
    • The name of the static factory extension will match the name as used by Redis itself
    • In some cases, the previous extension methods on RedisClient still exist, but are just convenience methods for calling the appropriate RedisCommand factory method.
      • There is no established rule on when these extensions will be supported. The ones that remain are ones that tend to make sense from an English prose perspective of relationship of the action being invoked and the client

        For example RedisClient.publish(_:to:) still exists, because RedisClient.publish(message, to: channel) reads a little better than RedisClient.send(.publish(message, to: channel)), since the client itself is doing the publishing and there is an implicit relationship between clients and PubSub channels.

        As a counter-example, RedisClient.linsert(_:into:before:) is now only available as RedisClient.send(.linsert(_:into:before:)) because it's a general command with no clear relationship between the command being invoked and the specific client doing the invocation.


  • Swift 5.2 is now the minimum supported Swift version (b148491)
  • RedisCommand and the extension methods on RedisClient have seen a significant refactor with no deprecation support to be provided !144
    • As a consequence of the changes, RedisComandHandler.OutboundIn is now (RESPValue, EventLoopPromise<RESPValue>)


Several pieces of API have been deprecated. They will be removed in the next major version.

  • RedisLifetimeKey has been moved and renamed to RedisKey.Lifetime !143
  • RedisLifetimeKey.Lifetime has been renamed to RedisKey.Lifetime.Duration !143
  • RedisCommand.flushall extension has been added !144


  • The README has been updated to indicate the in-development status of 2.0.0 (40d521c)
    • Historical version information, such as CI testing is available as extra details in the README (ba35a1f)
  • Swift 5.4 CI testing has been added (e2e8890)