- Persistent: to set up fast persistent storage for your application
- Ephemeral: to set up a non-persistent cache for your application
Supported versions
You can select the major and minor version. Patch versions are applied periodically for bug fixes and the like. When you deploy your app, you always get the latest available patches. Note that versions 3.0 and higher support up to 64 different databases per instance of the service, while Redis 2.8 only supports a single database.Service types
Depending on your needs, you can set up Redis as persistent or ephemeral.Relationship reference
For each service defined via a relationship to your application, Upsun automatically generates corresponding environment variables within your application container, in the$<RELATIONSHIP-NAME>_<SERVICE-PROPERTY> format.
Here is example information available through the service environment variables themselves,
or through the PLATFORM_RELATIONSHIPS environment variable.
- Service environment variables
- `PLATFORM_RELATIONSHIPS` environment variable
You can obtain the complete list of available service environment variables in your app container by running
upsun ssh env.Note that the information about the relationship can change when an app is redeployed or restarted or the relationship is changed. So your apps should only rely on the service environment variables directly rather than hard coding any values.Persistent Redis
By default, Redis is an ephemeral service that stores data in memory. This allows for fast data retrieval, but also means data can be lost when a container is moved or shut down. To solve this issue, configure your Redis service as persistent. Persistent Redis stores data on a disk, restoring it if the container restarts. To switch from persistent to ephemeral Redis, set up a new service with a different name.Usage example
1. Configure the service
To define the service, use theredis-persistent endpoint:
Note that changing the name of the service replaces it with a brand new service and all existing data is lost.
Back up your data before changing the service.
2. Define the relationship
To define the relationship, use theredis endpoint :
- Using default endpoints
- Using explicit endpoints
You can define
SERVICE_NAME as you like, so long as it’s unique between all defined services and matches in both the application and services configuration.The example above leverages default endpoint configuration for relationships. That is, it uses default endpoints behind the scenes, providing a relationship (the network address a service is accessible from) that is identical to the name of that service.Depending on your needs, instead of default endpoint configuration, you can use explicit endpoint configuration.With the above definition, the application container now has access to the service via the relationship SERVICE_NAME and its corresponding service environment variables.Configuration example
Use in app
To use the configured service in your app, add a configuration file similar to the following to your project. This configuration defines a single application (myapp), whose source code exists in the <PROJECT_ROOT>/myapp directory.myapp has access to the redis service, via a relationship whose name is identical to the service name
(as per default endpoint configuration for relationships).
From this, myapp can retrieve access credentials to the service through the relationship environment variables.
myapp/.environment
.environment in the myapp directory — is automatically sourced by Upsun into the runtime environment, so that the variable CACHE_URL can be used within the application to connect to the service.
Note that CACHE_URL, and all Upsun service environment variables like REDIS_HOST,
are environment-dependent.
Unlike the build produced for a given commit,
they can’t be reused across environments and only allow your app to connect to a single service instance on a single environment.
A file very similar to this is generated automatically for your when using the upsun ify command to migrate a codebase to Upsun.
Ephemeral Redis
By default, Redis is an ephemeral service that serves as a non-persistent cache. Ephemeral Redis stores data only in memory and requires no disk space. When the service reaches its memory limit, it triggers a cache cleanup. To customize those cache cleanups, set up an eviction policy. Make sure your app doesn’t rely on ephemeral Redis for persistent storage as it can cause issues. For example, if a container is moved during region maintenance, thedeploy and post_deploy hooks don’t run and an app that treats the cache as permanent shows errors.
To prevent data from getting lost when a container is moved or shut down,
you can use the persistent Redis configuration.
Persistent Redis provides a cache with persistent storage.
Usage example
1. Configure the service
To define the service, use theredis endpoint:
Note that changing the name of the service replaces it with a brand new service and all existing data is lost.
Back up your data before changing the service.
2. Define the relationship
To define the relationship, use theredis endpoint :
- Using default endpoints
- Using explicit endpoints
You can define
SERVICE_NAME as you like, so long as it’s unique between all defined services and matches in both the application and services configuration.The example above leverages default endpoint configuration for relationships. That is, it uses default endpoints behind the scenes, providing a relationship (the network address a service is accessible from) that is identical to the name of that service.Depending on your needs, instead of default endpoint configuration, you can use explicit endpoint configuration.With the above definition, the application container now has access to the service via the relationship SERVICE_NAME and its corresponding service environment variables.Configuration example
Use in app
To use the configured service in your app, add a configuration file similar to the following to your project. This configuration defines a single application (myapp), whose source code exists in the <PROJECT_ROOT>/myapp directory.myapp has access to the redis service, via a relationship whose name is identical to the service name
(as per default endpoint configuration for relationships).
From this, myapp can retrieve access credentials to the service through the relationship environment variables.
myapp/.environment
.environment in the myapp directory — is automatically sourced by Upsun into the runtime environment, so that the variable CACHE_URL can be used within the application to connect to the service.
Note that CACHE_URL, and all Upsun service environment variables like REDIS_HOST,
are environment-dependent.
Unlike the build produced for a given commit,
they can’t be reused across environments and only allow your app to connect to a single service instance on a single environment.
A file very similar to this is generated automatically for your when using the upsun ify command to migrate a codebase to Upsun.
Multiple databases
Redis 3.0 and above support up to 64 databases. But you can’t set up different access rights to each database. When you set up a relationship connection, access to all of the databases is automatically granted. The way to access a particular database depends on the client library you’re using:- PHP
- Python
- Node.js
Use the Redis
select command:Eviction policy
When Redis reaches its memory limit, it triggers a cache cleanup. To customize those cache cleanups, set up an eviction policy such as the following: The following table presents the possible values:| Value | Policy description |
|---|---|
allkeys-lru | Removes the oldest cache items first. This is the default policy when maxmemory_policy isn’t set. |
noeviction | New items aren’t saved when the memory limit is reached. |
allkeys-lfu | Removes least frequently used cache items first. |
volatile-lru | Removes least recently used cache items with the expire field set to true. |
volatile-lfu | Removes least frequently used cache items with the expire field set to true. |
allkeys-random | Randomly removes cache items to make room for new data. |
volatile-random | Randomly removes cache items with the expire field set to true. |
volatile-ttl | Removes cache items with the expire field set to true and the shortest remaining time-to -live value. |
Access your Redis service
After you’ve configured your Redis service, you can access it using either the Upsun CLI or through the Redis CLI.Upsun CLI
Unlike the Redis CLI, connecting via the Upsun CLI does not require additional authentication steps if you are already authenticated in your terminal. Access your Redis service by running the command:Redis CLI
Retrieve the hostname and port you can connect to through thePLATFORM_RELATIONSHIPS environment variable.
To do so, run the upsun relationships command.
After you’ve retrieved the hostname and port, open an SSH session.
To access your Redis service, run the following command:
If you have a Grid project, note that the CONFIG GET and CONFIG SET admin commands are restricted.
To get the current configuration, run the following command:
Use Redis as a handler for PHP sessions
A PHP session allows you to store different data for each user through a unique session ID. By default, PHP handles sessions using files. But you can use Redis as a session handler, which means Redis stores and retrieves the data saved into sessions. To set up Redis as your session handler, add a configuration similar to the following:Exporting Data Persistent
This section applies only to persistent Redis services configured withtype: redis-persistent.
Ephemeral Redis (type: redis) stores data only in memory; its data does not need to be exported.
The recommended approach is to use the BGSAVE command to write a point-in-time RDB snapshot to disk,
then download it.
- Open an SSH tunnel:
Terminal
- Trigger a background save and wait for it to complete:
Terminal
- Download the RDB dump file from the container:
Terminal
.rdb file can be imported into any Redis or Valkey instance by placing it in the data directory
and restarting the service.