Live Edit backing store#

Live Edit stores authoritative session and layer state in Valkey. All service replicas in one deployment must connect to the same backing store. Do not share that keyspace with an independent Live Edit deployment, and do not treat it as a disposable application cache.

Requirements#

Use Valkey 7.2 or newer, or a compatible Redis 7.x service supporting Streams, Lua scripts and transactions. Provision the store before installing Live Edit.

  • Set maxmemory-policy noeviction. Evicting keys can remove committed layer data; memory exhaustion should fail writes instead.

  • Set the server’s maxmemory below its container or host memory limit, leaving headroom for replication and persistence. Size it for the peak live dataset, retained updates and external values. Monitor the backing store’s memory usage and act before it reaches its limit.

  • Configure persistence and recovery appropriate to your data-loss requirements. Replication alone is not a substitute for a recovery plan.

  • Use TLS and authenticated connections in production. Allow service pods to reach every node/port advertised by a clustered backend, not only its bootstrap endpoint.

  • Permit the service’s required data, scripting, transaction, stream and pub/sub operations in the backing-store ACL. A read-only account is insufficient.

For self-hosted Valkey, configure persistent volumes and AOF before starting Live Edit. A typical server configuration includes:

maxmemory-policy noeviction
appendonly yes
appendfsync everysec

Select replication, failover and backup settings for the deployment’s availability and recovery requirements. The service’s own replica count does not provide Valkey redundancy. For managed stores, verify the provider’s eviction, persistence, failover, ACL and network settings; service startup is not a provider durability audit.

Endpoint selection#

Backing-store topology

TLS URL scheme

Single primary endpoint

rediss://

Cluster-aware endpoint

rediss-cluster://

Choose the scheme for the actual topology presented to the client. For example, a TLS cluster URL can be rediss-cluster://USER:PASSWORD@valkey.example.com:6379. Keep credential-bearing URLs in a Secret as described in Deployment.

When the endpoint contains no credentials, it can be configured directly:

valkey:
  url:
    value: "rediss-cluster://valkey.example.com:6379"

That setting supplies only the endpoint; configure its authentication separately. Only one of valkey.credentials.static.enabled, accessTokenFile.enabled or awsIam.enabled may be enabled. When none is enabled, the chart uses static authentication with credentials from the URL.

Authentication options#

Password or ACL credentials#

Use the live-edit-env Secret’s valkey-url key for the connection URL, including its username and password where required. Rotate the credential through your secret-management and deployment process. Changing the Secret’s contents alone does not restart pods or replace their environment variables.

Access-token file#

Use this mode when the backing store accepts renewable bearer credentials, such as a configured Microsoft Entra integration:

valkey:
  url:
    value: "rediss-cluster://valkey.example.com:10000"
  credentials:
    accessTokenFile:
      enabled: true
      username: "BACKING_STORE_PRINCIPAL_ID"
      path: /etc/secrets/access-token/valkey_access_token

Configure the token provider under serviceIdentity.accessTokenFile as described in External checkpoints. It must write the backing-store token to the path above and refresh it at least 195 seconds before expiry with the default refresh and polling settings.

The current chart also enables the service-token readiness check whenever this provider is enabled, even if checkpoints are disabled. The provider must therefore maintain a valid token at checkpoint.credentials.accessTokenFile.path (default /etc/secrets/access-token/access_token) as well, or the pod remains unready. For the combined Valkey and StorageApi checkpoint configuration, write both tokens under /etc/secrets/access-token with distinct filenames and the correct audience for each dependency. A Storage API token cannot be reused as a backing-store token unless that backing store explicitly accepts its audience.

AWS IAM#

For an IAM-enabled backend and pod identity configured with the required connection permissions:

valkey:
  url:
    value: "rediss-cluster://valkey.example.com:6379"
  credentials:
    awsIam:
      enabled: true
      service: memorydb
      username: "LIVE_EDIT_ACL_USER"
      region: "AWS_REGION"
      clusterHost: "CLUSTER_NAME"

clusterHost is the signing resource’s name, not the DNS endpoint. Select service: elasticache for the corresponding ElastiCache integration. Provision the backend’s IAM-enabled user and grant the pod identity access before installing; the chart does not create those cloud resources.

Durability and capacity checks#

With checkpoints disabled, Live Edit probes AOF at startup and refuses to start if it can confirm AOF is off. If a managed platform prevents that probe from determining the setting, startup can continue with a warning. Configure managed-store durability independently.

For recovery from complete live-store loss, configure external checkpoints in addition to backing-store persistence. Do not infer a guaranteed recovery point from a configured checkpoint interval; monitor completed backups and test restoration.

Size Valkey independently of service replicas. Increasing Live Edit replicas increases connections and potential load on the same store. Monitor memory, shard CPU, latency and connection usage with representative concurrent editing sessions and layer sizes.