reddb-cloud

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

1. Sign up at app.reddb.io.
2. Create an organization (or join one you were invited to).
3. Create a database — pick a name and a region.
4. Copy the connection string from the dashboard.
5. 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,        // from the dashboard
})

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

1. "How do I sign up / create a database / get a connection string?" → answer from this skill.
2. "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.
3. "What does it cost / what regions / what's on the plan?" → point them at reddb.io/pricing and the dashboard — do not memorize.
4. "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.