Launch a cache with a console

The cache-console stack stands up a managed Valkey cache with a web console already attached to it. You get an EU-resident in-memory key-value store and a Redis Commander admin UI wired to it, so you can browse keys, inspect values, and run commands from your browser the moment the stack reaches Running.

What the cache-console stack is, and who it is for

Valkey is an in-memory key-value store: fast, ephemeral, and ideal for caches, session stores, rate limiters, and queues. The catch is that an in-memory store has no built-in UI. To look at what is actually in your cache you normally install a client, open a TLS connection, and type commands by hand.

This stack removes that step. Redis Commander is a web admin UI for Redis and Valkey: it connects to the cache, lists every key, lets you drill into values, and gives you a console to run commands directly. Pairing it with the cache means you can see and edit your data from a browser without installing anything.

The stack is for teams who want that outcome without the plumbing:

• Developers who want a fast, managed cache and a way to peek inside it during development.
• Teams running session stores, rate limiters, or queues on Valkey who need to inspect live keys when debugging.
• Anyone who wants their cache to stay in their own EU-resident store rather than a third-party SaaS.

Composition

The stack composes two FoundryDB primitives, wired together at launch:

Resource	What it is	Spec
cache	A managed Valkey 8.1 service: the in-memory key-value store. This is the durable home for your cached data.	tier-1, 25 GB standard storage
console	A hosted Redis Commander app, attached to the cache. Serves the browser admin UI: key browser, value inspector, and command console.	tier-1, 10 GB standard storage

Valkey is the engine. Redis Commander is a stateless admin layer on top: it keeps no data of its own and reads everything live from the cache. Because Valkey speaks the Redis protocol, any standard Redis or Valkey client connects to the same cache directly, with no lock-in.

cache-console stack composition & launch

RUNNING Stack wired · web console live

Stack Templatecache-consolelaunch ⇉Valkeycache · :6379Redis CommanderREDIS_* ← cacheserve →Web Consolebrowse keys · commands

Template · launchValkey (cache)Redis Commander (console)wiring (REDIS_* injected)

Prerequisites

• An API token. See Authentication.

Unlike the rag-chatbot stack, the cache-console stack does not include an inference resource, so you do not need a configured inference provider to launch it.

Export your token for the commands below:

export FOUNDRYDB_TOKEN="your-api-token"

Launch it

Option A: one-click in the console

Open the Stacks catalog in the console, pick Launch a cache with a console, review the cost preview, and click Launch. The console runs the same preview, accept, and launch flow described below and shows the live endpoint once the stack reaches Running.

Option B: the API

The launch is a two-step flow: preview the cost first, then send the launch request with the cost you accepted. This guarantees you always see an up-to-date estimate before any billable resource is created.

1. Preview the cost

curl -X POST https://api.foundrydb.com/stacks/preview \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template_name": "cache-console"}'

The response breaks the cost down per resource:

{
  "template_name": "cache-console",
  "currency": "EUR",
  "monthly_total": 39.00,
  "line_items": [
    {
      "symbolic_name": "cache",
      "kind": "database",
      "description": "Valkey tier-1 + 25 GB standard storage",
      "monthly_cost": 21.00,
      "is_ceiling": false
    },
    {
      "symbolic_name": "console",
      "kind": "app",
      "description": "Redis Commander app tier-1 + 10 GB standard storage",
      "monthly_cost": 18.00,
      "is_ceiling": false
    }
  ],
  "warnings": []
}

monthly_total is the figure you pass to the launch request. The cost preview is computed fresh on every call, so always preview right before launching.

2. Accept and launch

Pass the monthly_total from the preview as accepted_monthly_cost:

curl -X POST https://api.foundrydb.com/stacks \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-cache",
    "template_name": "cache-console",
    "accepted_monthly_cost": 39.00
  }'

The response is 201 Created with the stack in Pending status. Capture its id:

export STACK_ID="the-id-from-the-response"

If accepted_monthly_cost has drifted from the current estimate by more than EUR 0.01, the launch returns 409 Conflict and you re-preview. If it is omitted entirely, the launch returns 400 Bad Request.

3. Poll for status

The stack provisions asynchronously. Poll GET /stacks/{id} until status reaches Running:

curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Typical progression is Pending then Provisioning then Wiring then Running. Most stacks complete within a few minutes. Once the stack is Running, the endpoint_url field carries the live Redis Commander URL:

{
  "id": "...",
  "name": "my-cache",
  "status": "Running",
  "endpoint_url": "https://my-cache-console.foundrydb.com",
  "resources": [
    { "symbolic_name": "cache", "kind": "database", "status": "Running", "service_id": "..." },
    { "symbolic_name": "console", "kind": "app", "status": "Running", "service_id": "..." }
  ]
}

First run

Open the console and sign in

Open the endpoint_url in a browser. Redis Commander serves its UI at that URL behind HTTP basic auth, so it is never world-open. The user is admin and the password is minted at launch. Retrieve it through the console app's credential reveal, the same way any FoundryDB app exposes a generated secret:

curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" | jq '.resources[] | select(.symbolic_name=="console")'

The reveal returns the HTTP_PASSWORD value generated for the console. Sign in with admin and that password.

Browse keys

The left pane lists the keys currently in your Valkey cache, grouped by the : separator so namespaced keys form a tree. A fresh cache is empty, so the tree starts bare. Click any key to inspect its value, type, and time-to-live in the right pane.

Set and get a value

You can write directly from the console. Use the command console (the input at the bottom of the UI) to set a key and read it back:

SET greeting "hello from foundrydb"
GET greeting

OK
"hello from foundrydb"

The key now appears in the key browser on the left. Click it to see its value and set a TTL if you want it to expire.

Run a command

The console is a full Redis-protocol command line against your cache. Anything a Valkey client can do, you can do here:

SET visits 1
INCR visits
INCR visits
GET visits

OK
(integer) 2
(integer) 3
"3"

That is a working counter in your cache, set and read entirely from the browser.

Connect a client directly

The console is for inspection and debugging. Your application connects to the same cache over the network with any standard Redis or Valkey client. External clients reach Valkey over TLS on port 6380 (the plaintext port 6379 is reserved for cluster-internal traffic and is firewalled to external clients). Retrieve the cache host, a username, and its password from the cache resource (see Valkey for the user and password endpoints), then:

redis-cli -h <cache-host> -p 6380 --tls \
  --user <cache-user> --pass <cache-password> \
  GET greeting

"hello from foundrydb"

The value you set in the browser is the same value your client reads over the wire. One cache, two ways in.

How the wiring works

The stack engine does not introduce a new provisioning path. It calls the same APIs you would call yourself, in dependency order, and injects the configuration each resource needs.

For the cache-console stack:

1. The cache resource is provisioned first: a managed Valkey 8.1 service.
2. The console resource is provisioned and attached to the cache. During the Wiring phase, the engine resolves the cache's connection details and injects them into Redis Commander.
3. Redis Commander connects on first boot and comes up serving the admin UI.

The console connects to Valkey through discrete REDIS_* connection variables rather than a single combined host string. The engine injects each piece separately so a password containing special characters can never corrupt the connection:

Variable	Value
REDIS_HOST	The cache's private address on the peered network.
REDIS_PORT	The Valkey engine port.
REDIS_USERNAME	The resolved cache username. Valkey authenticates with ACL users.
REDIS_PASSWORD	That user's password.

The console reaches the cache over the platform's private network fabric, not the public internet, so this internal hop never crosses the open network. There is no connection string to copy, no firewall rule to open by hand, and no environment variable to paste into a settings panel. The console already knows where the cache is and how to reach it the moment the stack reaches Running.

Cost and EU residency

The cache-console stack costs the sum of its two resources, shown in your cost preview at launch (tier-1 Valkey plus a tier-1 Redis Commander app). Each child resource is an ordinary service in your account, billed through your normal plan. You can scale either one individually after launch, for example moving the cache to a larger tier as your working set grows.

Both resources are EU-resident. The Valkey cache, the Redis Commander console, and the traffic between them all stay within the platform's European footprint. Residency is not a setting you remember to flip; it is where the platform runs.

Teardown

Delete the whole stack with one call:

curl -X DELETE https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Returns 202 Accepted. The reconciler deletes the console first, then the cache, in reverse dependency order. Teardown is atomic and leaves no orphaned cache or app behind. A Valkey cache is in-memory, so anything you want to keep should be exported first. Teardown is irreversible.

Next steps

• Valkey: scale, secure, and connect directly to the cache under your console.
• Stacks Overview: how stacks compose primitives, the catalog, and the lifecycle.
• Launch a Stack: the full preview, launch, retry, and teardown reference.
• Upgrades: adopt new template versions of the stack in place.