Caches

Blossom Caches provide Redis and Memcached with stable private endpoints and engine-aware operations across Blossom Cloud and Blossom BYOC (bring your own cloud). Create a Cache, choose its region and availability, and review the estimate. Blossom continues setup within your capacity limit.

Availability

A Cache is Dedicated, one node on its own Server, or Shared, running on your own Data Capacity with your other Shared Databases and Caches. Like a Database, a new Cache starts Shared where the Location offers Data Capacity, and Dedicated elsewhere. Shared Caches take a size and are priced exactly like Shared Databases; see Shared Sizes and Pricing. If the Capacity fails, Blossom recovers its resources together, and connections pause briefly.

A Dedicated Redis Cache can also run a standby, a setting like Multi-AZ rather than a separate resource. Check Standby with automatic failover when you create or edit the Cache, or set standby: true in the CLI or API; standby: false removes it. Blossom starts the standby on another Server once the primary is ready, and fails over to it automatically. The standby doubles the node and storage charge and needs Backup Storage. Move the writer on purpose with blossom cache_instance:switchover.

Read replicas are separate resources added after creation, from the Nodes page or with blossom cache_instance:replica:create. A Cache’s primary, standby, and replicas are kept apart, so one failure cannot remove both the primary and its recovery candidate.

Private Endpoints

The primary endpoint is based on the stable Cache id:

cache-abc123.blossom.internal

Redis replicas also have stable, read-only endpoints based on their Cache Node ids. Applications should not depend on provider addresses or Container names.

Cache ports are private. Redis credentials are generated by Blossom and redacted from Cache responses, Activities, and logs. Memcached has no native authentication and must never be exposed publicly. See Database And Cache Security.

Connect An Environment

An Environment Link delivers the private connection URL to every Service in the Environment:

environment_link:
  environment_id: environment-100
  target_type: CacheInstance
  target_id: cache_instance-100
  var_name: REDIS_URL

Redis links include the generated password. Memcached links default to MEMCACHED_URL. The Cache and Environment must belong to the same Account and region.

Rotate The Password

Rotate the Redis password when it may have leaked or on a regular schedule:

blossom cache_instance:credentials:rotate --id cache_instance-100 --follow

Blossom sets a new password inside Redis, including replicas and the standby, then restarts every linked Environment so its Services receive the new connection URL. The old password stops working. Connections pause briefly while the password changes and the Environments restart.

Show the new password with cache_instance:credentials, or use Rotate password on the Cache credentials page. A client configured outside an Environment Link must be updated by hand. Memcached has no password, so there is nothing to rotate.

To choose the Redis password yourself, open Set your own password on the credentials page, or pass it on stdin with cache_instance:credentials:rotate --password-stdin. A password needs 8 to 64 characters: letters, digits, and ! # % * + , - . / : = ? @ ^ _ ~.

Redis Protection

Redis uses append-only persistence for ordinary process recovery. With account Backup Storage, Blossom also creates encrypted recovery backups that can restore a new Cache or rebuild Redis after local data is lost.

Redis supports up to five direct read replicas and one dedicated standby. The standby is reserved for recovery and does not receive application traffic. Planned switchover and automatic failover move the stable primary endpoint, then rebuild the former primary as the new standby and reconnect the replicas. See Redis Recovery Backups.

Memcached remains intentionally ephemeral. Blossom recreates it empty after a failure and does not present backup, replica, or standby controls that imply durable data.

CLI

blossom cache_instance:init

writes cache_instance.yml:

cache_instance:
  name: production-cache_instance
  # location_id: location-100
  engine: redis # redis or memcached
  availability: shared # the default where the Location has Data Capacity; or dedicated, its own Server
  # size: small # Shared only: small (default), medium, large, or {cpu_vcpus: 0.5, memory_gb: 1}
  # standby: true # Dedicated Redis only: a standby with automatic failover; doubles the charge
  storage_gib: 10 # Redis keeps its data on this storage; Memcached takes none
  backup_storage_id: blossom_cloud # default for Redis; or your own backup_storage-...; not supported by Memcached

blossom cache_instance:create --data cache_instance.yml --follow
blossom cache_instance:list
blossom cache_instance:show --id cache_instance-100
blossom cache_instance:console --id cache_instance-100
blossom cache_instance:activity --id cache_instance-100

Your Location’s capacity ceiling is the standing approval: a Cache that would pass it is refused with the amount it needs, and nothing is created.

Turn the standby on or off with cache_instance:update, switch to it with cache_instance:switchover, and manage read replicas under cache_instance:replica:*. See the cache CLI reference.