Skip to main content

Connect from workloads

This page covers every way to connect to a MemoryStore instance: the private in-cluster address your platform workloads use, how credentials work (and how to avoid handling them by hand), and the optional TLS endpoint for workloads in your Crusoe VPC.

The connection details​

Every read of an instance returns a connection block:

{
  "connection": {
    "host": "ms-cache.cai-p-<short>.svc.cluster.local",
    "port": 6379,
    "username": "default",
    "credential_secret": "ms-cache-credential"
  }
}

Assembled as a URI, that's:

redis://:<password>@ms-cache.cai-p-<short>.svc.cluster.local:6379

Three things to understand about it:

  • The hostname is private. ms-<name>.cai-p-<short>.svc.cluster.local resolves only inside the platform. Workloads in your project (agents, functions, services) reach it directly; your laptop does not. There is no public endpoint.
  • In-cluster traffic is plaintext redis:// on port 6379. TLS exists only on the optional external endpoint described below.
  • The password is not in this response. Reads return the name of the Kubernetes Secret that holds it (ms-<name>-credential, with keys password and uri), never the value.

Users and passwords​

MemoryStore has exactly one user: default. There is no ACL user management — you cannot create additional users with narrower permissions. The password is the whole story:

  • It is generated at create time and shown once, in the create response (see the quickstart).
  • Every later read returns only credential_secret — the Secret name.
  • Admins can rotate it: POST .../memorystores/{name}/rotate-credential returns a fresh credential in the same shown-once way. Rotation is eventual: the server reads its password once at start, so the new password takes effect when the instance restarts (the platform triggers that restart for you). Until the rollout completes, the old password is still the one in force — write your retry logic accordingly.

Rotating before the instance has finished provisioning fails cleanly:

{"error":"this memorystore has no credential yet; wait for it to finish provisioning","request_id":"..."}

Connect from agents and functions​

The recommended pattern is: never copy the password into your code or an environment variable by hand. Instead, put it in your workload's secrets and read it from the environment.

CRUSOE_MEMORYSTORE_ADDR is not your instance

Agents run with an environment variable named CRUSOE_MEMORYSTORE_ADDR. It points at the platform's shared session store — the store that holds agent conversation sessions — not at any MemoryStore instance you created. To reach your own instance, use its connection.host and password explicitly, as shown below. See Use with agents for the full story.

Step 1 — give your workload the password. When you create an instance in the console, the credentials dialog offers to store the password in your project's Secrets for you (suggested name: memstore-<instance>-password). Or set it on an agent yourself; either way, see Secrets and environment variables for how secrets become environment variables in your agent.

Step 2 — connect with any Redis client. MemoryStore is Redis wire-compatible, so the standard client for your language works unchanged. Python, for example:

import os
import redis

r = redis.Redis(
    host="ms-cache.cai-p-<short>.svc.cluster.local",  # connection.host from the API
    port=6379,
    username="default",
    password=os.environ["MEMSTORE_CACHE_PASSWORD"],   # injected from your secrets
)
r.set("greeting", "hello")
print(r.get("greeting"))  # b'hello'

The same applies to functions and any other workload running in your project: private hostname plus password from the environment.

Connect from your Crusoe VPC (optional TLS endpoint)​

If you need to reach an instance from workloads outside the platform but inside your Crusoe VPC — for example, a VM you run — create the instance with "external_exposure": true. Once the route is programmed, the instance reports:

{
  "external_exposure": true,
  "externally_reachable": true,
  "external_endpoint": "rediss://cache-<short>.<domain>:443",
  "reachable_scope": "vpc"
}
  • The endpoint speaks TLS (rediss://, note the double s) on port 443. TLS terminates at the platform's shared data gateway.
  • It is reachable from your Crusoe VPC only — the gateway is firewalled to the VPC address range. It is never reachable from the public internet. reachable_scope: "vpc" in the API is the contract, not a hint.
  • The same default user and password apply.

From a VM in your VPC:

redis-cli --tls -h cache-<short>.<domain> -p 443 -a "$MS_PASSWORD" PING

You should see:

PONG

The external_endpoint field appears only once the route is actually programmed — if it's missing right after create, poll the instance until it shows up.

Connection checklist​

FromAddressProtocolAuth
Agents, functions, services in your projectms-<name>.cai-p-<short>.svc.cluster.local:6379redis:// (plaintext, in-cluster)user default + password from the credential Secret
Workloads in your Crusoe VPC (opt-in)rediss://<name>-<short>.<domain>:443TLSsame user + password
Public internet—not available, by design—

Next steps​