Valkey and Memcached, run for you.
Pick the engine and the version.
Choose the engine and its version: Valkey 8.0 to 9.1 or Memcached 1.6. Then pick a mode: Basic for one node, Standard for a primary with up to five replicas and automatic failover, or Cluster for shards. Your apps keep the clients they use today, over RESP2, RESP3 or the memcached protocol. Frazer runs it next to your databases, behind a private endpoint in your VPC, with ACL users, TLS and backups. On your own servers it is part of the server fee.
$ frazer keyvalue instances create cart-cache \
--mode standard --replicas 2 --node-type mem-m1-32 \
--site ovh-vint-hill --network acme-prod-vpc \
--persistence rdb --rdb-period 6h --tls --dry-run
Plan + Valkey 9.1 · Standard · 1 primary + 2 replicas
+ endpoints primary, reader in acme-prod-vpc
+ ACL user app · password kept in Frazer Secrets
+ daily backups · kept 7 days · final on delete
+ 4 default alert policies in Frazer Monitoring
Cost included in the server fee
✓ Disruption: none$ frazer keyvalue instances update cart-cache \
--node-type mem-m1-64 --dry-run
Plan ~ cart-cache · mem-m1-32 → mem-m1-64
new replicas of the new type sync first,
then one graceful failover; old nodes go
! Disruption: failover · connections reset once$ frazer keyvalue instances connect cart-cache --readonly
Login iam:lena@acme.example · +@read · expires in 1 h
Via Frazer Link · TLS · no public address
$ frazer keyvalue instances proxy cart-cache --port 6379
Local localhost:6379 for apps on your laptop$ frazer keyvalue instances import \
--from-rdb frazer://buckets/migr/acme.rdb \
--to acme-jobs --mode standard
Check RDB format version · accepted by Valkey 9.1
Plan + acme-jobs · Valkey 9.1 · Standard
seeded from the RDB fileTwo engines, the version you pick.
One way to run them.
Valkey gets every mode, endpoint, access control, backup and plan; Memcached runs as a pool of cache nodes. Pick the engine at create; the version moves forward by plan.
Valkeyrecommended
Versions 8.0, 8.1, 9.0 and 9.1. Search (vector and full text), JSON and Bloom filters as switches. Every mode.
Memcached
Version 1.6. For apps that speak the memcached protocol. A cache: no persistence or backups.
New versions arrive within 30 days of their upstream release. Patches apply in your maintenance window; moving to a newer version is a plan you approve, never a downgrade. A version leaves support with 12 months’ notice.
A primary, its replicas, one name.
The endpoint follows every failover.
In Standard mode your apps write through the primary endpoint and read through the reader. Three monitors you never see watch the primary; when it fails, a replica takes over and Frazer moves the endpoint, so any client works and sees one dropped connection. Backups are taken on a replica and kept in Frazer Storage.
Three modes, fixed at create.
Pick by size and by client.
Basic and Standard work with any client. Cluster spreads the keyspace over shards and needs a cluster-aware client. Moving to another mode means a new instance from a backup.
| Basic | Standard | Cluster | |
|---|---|---|---|
| Topology | One node | A primary and 1–5 replicas on different servers | 1–64 shards, each with 0–5 replicas |
| Client | Any | Any: the primary endpoint follows the primary | A cluster-aware client |
| Endpoints | primary | primary and reader | discovery on 6379, plus a port per node |
| Databases | 16 | 16 | 1, or up to 100 with cluster-databases |
| Largest | One node type | One node type, up to 102 GiB writable | Shards × node type, up to 64 × 102 GiB |
| Failover | None: restart and reload from disk | A quorum of monitors, then the endpoint moves | The cluster bus |
| Servers | One is enough | Two or more | Primaries and replicas spread across servers |
| For | Dev, staging, previews | Production caches, sessions, queues, rate limits | Large keyspaces, high throughput |
Sized by memory
Each node keeps 80 % of its memory writable; the rest is headroom for forks, replication and client buffers. Shared-CPU types are for Basic only and can power off when idle. A one-server site offers Basic only, and the create page says why.
| Node type | vCPU | Memory | Writable |
|---|---|---|---|
mem-s1-1shared CPU | 0.5 | 1.5 GiB | 1.2 GiB |
mem-s1-3shared CPU | 1 | 3 GiB | 2.4 GiB |
mem-m1-8 | 2 | 8 GiB | 6.4 GiB |
mem-m1-16 | 2 | 16 GiB | 12.8 GiB |
mem-m1-32 | 4 | 32 GiB | 25.6 GiB |
mem-m1-64 | 8 | 64 GiB | 51 GiB |
mem-m1-128 | 16 | 128 GiB | 102 GiB |
mem-c1-16high CPU | 8 | 16 GiB | 12.8 GiB |
Endpoints, nodes and checks.
On one page for each instance.
The overview shows the endpoints to copy and how to sign in, every node with its lag, the production checks and what changed lately. Maintenance arrives with a week’s notice and names the disruption it will cause.
The production checks
- Auth on
- TLS on
- At least one replica
- Persistence on, or cache-only acknowledged
- Eviction policy set
- Backups OK
- Maintenance window set
- Under half the keys without a TTL
What survives, said plainly.
Persistence, backups and failover.
An in-memory store is only as durable as you set it up to be. The create page and every plan say what a restart, a failover or a restore keeps.
| Mode | What survives a restart | Default |
|---|---|---|
| Off | Nothing: a pure cache | The Basic default |
| RDB | Data up to the last snapshot, taken every 1, 6, 12 or 24 hours | Standard and Cluster in production: every 6 hours |
| AOF | Up to the last second with fsync every second, or every write with always | Opt-in |
- Backups daily in your window and on demand, taken on a replica when there is one; kept 1 to 365 days, 7 by default, with a final backup on delete.
- A restore always creates a new instance; your app’s endpoint switches after checks.
- No point-in-time recovery. You get the data since the last snapshot, or the last second with AOF.
- Replication is asynchronous, so a failover can lose writes the old primary acknowledged. Use
WAITwhere a write must reach a replica. - A monthly restore drill into a scratch instance compares key counts and shows the result on the page.
See what fills the memory.
And which keys run hot.
Memory, hit ratio, latency per command and replication come with default alerts. Insights go further: the commands that were slow, and the keys and prefixes that take the space, from a sampled scan that runs on a replica when there is one.
Command log
Slow commands, large requests and large replies every 30 seconds, with arguments masked.
Big keys and key prefixes
From a sampled scan, on a replica when there is one, daily and on demand: the 50 biggest keys, memory by prefix, keys without a TTL.
Data browser
Read-only by default, as a short-lived user; edits need write permission and are audited.
Everything around the instance.
Run by Frazer, changed by plan.
ACL users from templates
Read-write, read-only and queue-worker rules; rotation keeps two valid passwords, so no downtime.
IAM login for people and agents
A short-lived user with rules from the role, at most 12 hours, every login audited.
TLS on in production
A CA per instance; certificates reload without a restart.
Resize by plan
New replicas of the new type sync, then one graceful failover. Shrinking below your data is refused.
Maintenance you can move
Seven days’ notice, reschedule up to 14 days, deny periods up to 90 days; staging first.
Import and export
Create from an RDB file in a bucket; export any backup to your bucket.
Tools for agents
List, describe, metrics, insights and a read-only scan over MCP; failover and flush wait for a person.
Memcached
For apps that already speak memcached: 1–20 nodes, a cache only, TLS on.
Who may read and write.
And what needs a person.
Who may do what
- Developer
- Creates and changes instances through plans that state their disruption.
- Viewer
- Reads instances and metrics; never writes data.
- Responder
- Reads, and may fail over.
- Agents
- Read, scan with previews capped at 1 KiB, and plan. Failover, flush and delete wait for a person.
What is logged
- Every IAM login, with its principal and expiry
- Failover and flush, as live actions
- Edits and deletes in the data browser
- ACL denials, failovers and maintenance, in the instance’s logs
At the cap
- Auth on by default; turning it off needs an explicit flag and fails a production check
KEYS,FLUSHALL,CONFIG,SHUTDOWNand other admin commands are denied to your users- Flush needs a typed confirmation and, in production, an approval
- A spend cap never stops an instance: it pauses fleet compute only. Delete keeps a final backup
Same rates as a VM.
Included on your own servers.
On your own servers, nodes, replicas and their disks are part of the per-core server fee. Backups count against the Frazer Storage allowance. On the Frazer fleet, nodes bill by the second at the vCPU and memory rates, with no managed premium.
See every pricemem-m1-16 (2 vCPU, 16 GiB): $0.172 per node-hourIn-memory store, answered.
Will my client library work?
Yes. Valkey speaks RESP2 and RESP3, so the client libraries your apps use today connect unchanged. Basic and Standard take any client; Cluster mode needs a cluster-aware one. The connect snippets on each instance page show the client for your language.
What happens to writes when the primary fails?
In Standard mode a quorum of monitors promotes a replica and Frazer moves the primary endpoint to it. Clients see one dropped connection and reconnect to the same name.
Replication is asynchronous, so writes the old primary acknowledged can be lost. Use WAIT where a write must reach a replica. Basic mode has no failover: the node restarts and reloads from disk.
Is there point-in-time recovery?
No. With RDB you get the data since the last snapshot; with AOF, up to the last second. Backups restore only into a new instance, and your app’s endpoint switches after checks.
Can I change the mode later?
No, the mode is fixed at create. To move to Cluster, create a new instance from a backup. Replicas and node type change in place, through a plan that states its disruption.
How do I bring an existing cache?
Create the instance from an RDB file in a Frazer bucket. Valkey reads files from Valkey and from Redis® Open Source 7.2 or earlier, and the plan checks the format version first. From a newer server, Frazer copies the keys over RESP instead. Or replicate live from the running source over Frazer Access or a VPN, then switch.
What about Memcached?
Memcached 1.6 is for apps that already speak the memcached protocol: 1 to 20 nodes, a cache only, with no persistence or backups, reachable only through private endpoints with TLS on. For anything new, the create page recommends Valkey Basic with allkeys-lru.