Steada Apply

Private alpha

Connect through the TLS proxy after founder approval.

Steada private alpha is a founder-operated Valkey endpoint for accepted design partners. Each tenant runs in its own isolated, memory-capped container; billing, self-serve provisioning, SLA, and compliance commitments are not active.

Endpoint cutover in progress

The data-plane endpoint is moving to redis.steada.dev:6380. It becomes live once the DNS and TLS cutover completes; until your founder confirms cutover, connect using the endpoint shared with you out of band. The certificate already covers the new name.

The short answer

After founder approval and a lifecycle record, point a standard Redis client at redis.steada.dev:6380 over TLS, authenticate with the out-of-band runtime password, and verify against the public CA certificate. Run a redis-cli --tls PING smoke test first, keep your current backend behind a flag for rollback, and use only low-risk cache or rate-limit workloads with TTLs.

Endpoint redis.steada.dev:6380
Protocol Valkey RESP over TLS with password authentication.
Access Port 6380 is public for Lambda clients; SSH and raw Valkey stay firewall-restricted.
Backups restic backup timer plus restore verification before the endpoint is marked usable.
Lifecycle Each design-partner database has founder metadata, quota notes, backup status, and credential version history.
Gates Access, metering, restore, monitoring, and incident evidence must pass before expanding private-alpha usage.
redis-cli smoke test 
redis-cli --tls -h redis.steada.dev -p 6380 -a "$KEYNEST_VALKEY_PASSWORD" PING
Repository smoke test 
KEYNEST_VALKEY_HOST=redis.steada.dev \
KEYNEST_VALKEY_PORT=6380 \
KEYNEST_VALKEY_PASSWORD="$KEYNEST_VALKEY_PASSWORD" \
npm run service:verify
Founder lifecycle record 
go run ./cmd/founderctl alpha create \
  --id acme-cache \
  --owner "Acme" \
  --support-contact ops@example.com \
  --workload sessions \
  --provider digitalocean \
  --region nyc3 \
  --plan cost-optimized-alpha \
  --endpoint redis.steada.dev:6380
Readiness gate 
npm run service:usage -- --host redis.steada.dev --port 6380 --tls
npm run phase1:restore-drill -- --host redis.steada.dev --port 6380 --tls
go run ./cmd/founderctl alpha check-gates --id acme-cache

Before connecting traffic

  • Confirm the workload qualifies for private alpha and has a named support contact.
  • Create a founder lifecycle record before sharing credentials.
  • Use the runtime password shared out of band.
  • Use the public CA certificate for normal TLS verification.
  • Use TLS and set explicit connection timeouts.
  • Do not store production secrets, regulated data, or unrecoverable state during private alpha.

First client: Emcognito

  • emcognito-new-ui runs on Lambda, so no source CIDR is required.
  • Store the Steada password in the Emcognito secret manager.
  • Use a key prefix such as emcognito:<service>:<purpose>:<id>.
  • Start with a low-risk cache or rate-limit workload with TTLs.
  • Keep the current backend available behind a feature flag for rollback.

Frequently asked questions

How do I connect to the Steada private alpha?
Once the founder has approved your workload and created a lifecycle record, point a standard Redis client at redis.steada.dev:6380 over TLS, authenticate with the runtime password shared out of band, and verify the public CA certificate. A quick redis-cli --tls PING confirms the path before you send real traffic.
Is the private alpha production-ready?
No. It is a founder-operated endpoint for accepted design partners. Each tenant already runs in its own isolated, memory-capped container, but billing, self-serve provisioning, an SLA, and compliance commitments are not active, so you should not store production secrets, regulated data, or unrecoverable source-of-truth state during the alpha.

Connection background: the Valkey project and Redis client docs. Compatibility boundaries: beta compatibility guide.

Last reviewed