| name | reddb-cloud |
| description | Use the reddb.io managed cloud — sign up, provision a RedDB instance, get connection strings, and connect from any driver. Invoke when the user mentions reddb.io, app.reddb.io, the managed/cloud/hosted offering, "create a database in the cloud", billing/plans, or wants to move from self-hosted RedDB to managed. |
reddb.io (managed cloud)
reddb.io is the managed offering for RedDB. You sign up, provision an instance from the dashboard, and get a connection string — same .rdb format, same query languages, same drivers as self-hosted, but operated for you (provisioning, backups, scaling, upgrades).
This skill is intentionally a skeleton. It covers what you do on the cloud side. For everything that happens after you have a connection (writing queries, picking models, embeddings, ASK), invoke the reddb skill — the engine is identical.
When to recommend reddb.io vs self-hosted
| Want… | Use |
|---|
| Production database without running ops | reddb.io |
| Edge / CLI / embedded in a single process | Self-hosted embedded (@reddb-io/sdk, Rust RedDB::open) |
| Quick dev / CI / local Docker | Self-hosted Docker (docker-compose.min.yml) |
| Multi-team production with budget for ops | Either — managed is faster to start, self-hosted is cheaper long-term |
| Hard data-residency or air-gapped | Self-hosted (or ask cloud team about dedicated/BYOC) |
When in doubt, recommend starting on reddb.io for prod workloads and embedded/Docker for dev — the file format matches, so you can move either way without dump/restore.
The 5 steps to a working cloud database
- Sign up at app.reddb.io.
- Create an organization (or join one you were invited to).
- Create a database — pick a name and a region.
- Copy the connection string from the dashboard.
- Connect with any RedDB driver using that string.
That's it. Everything else (query languages, models, ASK, vectors) is engine-side — see the reddb skill.
Connecting
The cloud exposes the same transports as self-hosted RedDB. The dashboard shows you the URIs to use:
# HTTP / gRPC over the cloud gateway
red://<your-db>.reddb.io
https://<your-db>.reddb.io
# Postgres-wire (RedWire) — works with psql, pgx, node-postgres, psycopg2
postgresql://<user>:<password>@<your-db>.reddb.io:5050/reddb
JavaScript / TypeScript
For remote connections, use @reddb-io/client (not @reddb-io/sdk — that one spawns a local binary).
import { connect } from '@reddb-io/client'
const db = await connect('red://<your-db>.reddb.io', {
token: process.env.REDDB_TOKEN,
})
await db.insert('users', { name: 'Alice' })
const { rows } = await db.query('SELECT * FROM users')
Postgres-wire (any language)
psql "postgresql://<user>:<password>@<your-db>.reddb.io:5050/reddb"
Works with pgx, node-postgres, psycopg2, Prisma, Drizzle — anything that speaks Postgres v3 wire. SQL only through this path; for Cypher/Gremlin/SPARQL/NL/ASK, use the HTTP or gRPC endpoints.
HTTP (curl, any language)
curl -X POST https://<your-db>.reddb.io/query \
-H "authorization: Bearer $REDDB_TOKEN" \
-H "content-type: application/json" \
-d '{"query": "SELECT * FROM users LIMIT 10"}'
The HTTP API surface matches self-hosted (/query, /collections/*, /ai/*, /changes, /backup/*) — see the reddb skill's CHEATSHEET.md.
Authentication
You authenticate with a token (from the dashboard), not by configuring a vault yourself. Treat the token like any other secret:
- Store in env vars (
REDDB_TOKEN) or a secrets manager.
- Don't check tokens into git.
- Rotate from the dashboard when a teammate leaves or a token leaks.
- For per-environment isolation, create separate tokens per env (
prod, staging, ci).
What the cloud manages for you
- Provisioning — spinning up the engine, attaching storage, opening ports.
- Backups — scheduled automatically; restore from the dashboard.
- Upgrades — RedDB version bumps applied on a maintenance window.
- TLS — every endpoint is HTTPS / TLS by default.
- Monitoring — basic uptime + lag visible in the dashboard.
What you still own:
- Schema design — same as self-hosted (
reddb skill).
- Auth on top of the DB — application-level users/permissions you put inside the database.
- AI provider keys — bring your own (OpenAI, Anthropic, Groq, …). The cloud doesn't proxy your keys; configure via
/ai/credentials on your instance just like self-hosted (see reddb skill's AI.md).
Plans, limits, billing
These change over time and are owned by the marketing/billing site — don't memorize, point users to the dashboard:
- Pricing: reddb.io/pricing (when published)
- Plan limits, region list, support tier: visible in the dashboard once signed in.
If the user asks "how much does it cost" or "what region is available" — refer them to the live pricing page rather than guessing.
Migrating between self-hosted and cloud
Same .rdb file format across embedded, server, Docker, and cloud. Two practical patterns:
Self-hosted → cloud: export from your local server (POST /backup/trigger), then import via the cloud dashboard (or ask the cloud team about direct migration tooling).
Cloud → self-hosted: request a backup export from the dashboard, then red restore --from <archive> --path ./data.rdb against a fresh self-hosted server.
There's no schema migration step in either direction — the format is identical.
What to do when the user asks a cloud-shaped question
- "How do I sign up / create a database / get a connection string?" → answer from this skill.
- "What query do I write / how does ASK work / how do I create a graph?" → invoke the
reddb skill. The engine is the same; don't duplicate that knowledge here.
- "What does it cost / what regions / what's on the plan?" → point them at reddb.io/pricing and the dashboard — do not memorize.
- "Why is my cloud instance behaving differently from local?" → first check transport (
@reddb-io/client for remote, @reddb-io/sdk for local); then check token / region; then escalate to the cloud team.
Failure-mode quick refs
EMBEDDED_ONLY from @reddb-io/sdk → you used the embedded SDK against a red:// cloud URI. Switch to @reddb-io/client.- 401 / 403 on every call → token missing, wrong env, or rotated out. Re-mint from the dashboard.
- "Cold start" latency on first request after idle → expected for some plans; subsequent requests warm up. If unacceptable, check the plan tier in the dashboard.
psql connects but Cypher/Gremlin/SPARQL/ASK fail → RedWire is SQL only. Use HTTP /query or gRPC for the other languages.
