Database service

Redis

The Redis integration provisions a Redis instance — a shared, Dreambase-managed server namespaced by key prefix, or a dedicated instance on the platform of your choice — then reports its connection string back to Dreambase and exposes key/value operations, health checks, and metrics.

Redis is one of the Database service integrations. It handles its own webhook route:

POST/redis/webhook
Provision a Redis instance (shared or dedicated)

What it does

On DEPLOYMENT_CREATED the service either hands back a namespaced slice of a shared Redis server or provisions a dedicated instance on a chosen platform, then reports its connection urlback to Dreambase. Unlike a SQL database, Redis has no lightweight per-tenant “database” concept, so it combines both models the other database integrations split across two services (compare PostgreSQL and PostgreSQL Server) into a single service, switched by the serverType input.

Server type

  • shared (default) — use the Dreambase-managed Redis server (REDIS_SHARED_SERVER_URL). Tenants are isolated by a key prefix (<namespace>:<environment>:), since Redis exposes only a handful of numbered databases. Ideal for MVPs and development, with no setup required.
  • dedicated — provision your own Redis instance on the platform selected via the provider input.

Providers (dedicated)

The provider input selects where the instance is deployed:

  • docker (default) — a local redis:latest container, for development.
  • upstash — serverless Redis via the Upstash API.
  • render — a managed Key Value instance on Render.
  • railway — a Redis service on Railway.
  • aiven — a managed Redis/Valkey service on Aiven.
  • digitalocean — a managed Redis/Valkey cluster on DigitalOcean.

Provider-specific inputs

Each provider reveals only its relevant inputs. Cloud providers need credentials (e.g. upstashEmail + upstashApiKey, renderApiKey + renderOwnerId, railwayApiToken or railwayProjectToken + railwayProjectId, aivenToken + aivenProject, doApiToken) plus optional naming, region, and plan fields; docker takes a host port and password. Most fields auto-generate sensible defaults when left blank. Secrets accept a {{env.KEY}} reference so they stay out of the canvas.

Inputs

InputApplies toDescription
serverTypeallEither shared (default) or dedicated.
namespacesharedKey-prefix namespace (default app). Keys live under <namespace>:<environment>:.
providerdedicatedWhere to deploy the instance (default docker).
port, passworddockerHost port (auto-assigned from 6380) and optional AUTH password.
upstashEmail, upstashApiKey, name, regionupstashUpstash account credentials plus optional database name and region.
renderApiKey, renderOwnerId, name, plan, region, maxmemoryPolicyrenderRender API key and owner id plus optional Key Value settings.
railwayApiToken / railwayProjectToken, railwayProjectId, railwayEnvironmentId, passwordrailwayAn account/team token or a project token, the target project, an optional environment (default production), and an optional password (auto-generated). The instance is exposed via a Railway TCP proxy so its URL is reachable.
aivenToken, aivenProject, aivenCloud, aivenServiceType, name, planaivenAiven token and project plus optional cloud, engine (redis/valkey), name, and plan.
doApiToken, doName, doRegion, doSize, doEnginedigitaloceanDigitalOcean token plus optional cluster name, region, node size, and engine.

Outputs

  • url — the Redis connection string (redis:// or rediss://).
  • keyPrefix — the prefix namespacing this deployment's keys (shared server type only).
  • provider — the server type or provider used to deploy this instance.

Functions

Key/value operations, callable via a FUNCTION_CALLevent. On a shared instance every key is transparently prefixed with the deployment's namespace, so callers work with plain key names.

  • get, set (optional ttlSeconds), del, exists — basic key operations.
  • incr — atomically increment an integer key (optional by).
  • expire, ttl — manage and read a key's time-to-live.
  • type — the data type stored at a key.
  • keys — list keys matching a glob pattern, scoped to the namespace.

Metrics

On METRIC_UPDATE the service reports memory_used, total_keys (scoped to the namespace on a shared server), connected_clients, ops_per_second, and uptime.

Events it handles

  • WEBHOOK_CHALLENGE — verify the webhook endpoint.
  • HEALTH_CHECK — confirm the instance is reachable.
  • METRIC_UPDATE — report memory, key count, clients, throughput, and uptime.
  • DEPLOYMENT_CREATED — provision/attach the instance and return its connection details.
  • DEPLOYMENT_DELETED — stop tracking the deployment: a local Docker container is removed and a shared namespace's keys are cleared. Managed cloud instances are left running (see below).
  • DOWNLOAD_STARTED — generate Docker run/compose setup snippets.
  • FUNCTION_CALL — run a named key/value function.

Serverless limitations

The dedicated docker provider spawns a local redis:latest container and is meant for local or long-running hosts. When running serverless, use the shared server type or a cloud provider (upstash, render, railway, aiven, digitalocean).

Cloud instances aren't auto-deleted

On DEPLOYMENT_DELETED the service removes a local Docker container and clears the keys under a shared namespace, but it does notdelete managed instances you provisioned on a cloud provider — those keep running until you remove them from the provider's own dashboard or API. This avoids destroying data the deployment record no longer tracks.