Steada Sign in

Compatibility

Use native RESP over TLS, prove command fit, and keep rollback close.

Steada supports bounded Redis-compatible workloads. It does not claim a formal SLA, completed compliance coverage, global replication, Redis modules, or full Upstash REST parity yet.

Default path Native Redis/Valkey RESP over TLS with password authentication.
REST preview Narrow compatibility experiments only; not a full Upstash REST replacement.
Best fit Cache, sessions, rate limiting, and low-risk queue-lite metadata with TTLs.
Migration gate Command audit, test dataset, rollback trigger, and verification commands before cutover.

Default allowed commands

  • PING, AUTH, HELLO
  • GET, SET, SETEX, MGET, MSET, DEL, EXISTS
  • EXPIRE, PEXPIRE, TTL, PTTL, PERSIST
  • INCR, INCRBY, DECR, DECRBY
  • Basic hashes when approved: HGET, HSET, HGETALL, HDEL

Conditional review

  • Small lists, sets, and sorted sets for bounded metadata use.
  • Pub/Sub for non-critical notifications.
  • Lua scripts only after the exact script and rollback behavior are reviewed.

Unsupported at launch

  • Formal SLA, completed compliance certification, or regulated-data commitments.
  • Multi-region active-active replication and Redis modules.
  • Production KEYS scans or long-running analytics workloads.
  • Workloads that cannot roll back to the current provider.
  • Source-of-truth data without an independent recovery path.
Migration checklist 
1. Capture provider, region, spend, dataset, commands, payload, connections.
2. Audit command usage from code, logs, or provider metrics.
3. Confirm TLS and password auth in the client.
4. Test a representative dataset with TTLs.
5. Verify PING, GET/SET, TTL, counters, and app smoke test.
6. Define rollback triggers before credentials are shared.

Workload notes

  • Caches should be reproducible and tolerate misses.
  • Sessions need a re-authentication or provider fallback path.
  • Rate limiting should have reviewed burst behavior and abuse limits.
  • Queue-lite usage must be recoverable metadata, not the only durable job source.

Frequently asked questions

Will my existing Redis client work on Steada?
In most cases yes. The default path is native Redis/Valkey RESP over TLS with password auth, and Valkey preserves the Redis 7.2 command surface, so standard Redis clients connect unchanged. Code bound to the Upstash REST API or the @upstash/redis HTTP client needs a normal TCP client to move. Steada does not claim full Upstash REST parity yet.
Which workloads fit Steada?
Cache, sessions, rate limiting, and low-risk queue-lite metadata with TTLs are the best fit — anything where a miss, re-auth, or fallback path is acceptable and the workload can roll back to its current provider. Source-of-truth data without an independent recovery path is not a fit for the first production launch.
What is not supported at launch?
No formal SLA, completed compliance certification, or regulated-data commitments; no multi-region active-active replication or Redis modules; no production KEYS scans or long-running analytics; and no workloads that cannot roll back. These are deliberate boundaries, not bugs — the first production launch keeps the surface bounded and reversible.

Ready to migrate a workload? Provision it in the dashboard. Command surface reference: the Valkey command list and the Redis "What is Valkey?" overview.

Last reviewed