Skip to content
ZedCloud

Data and services overview

Apps rarely run alone. On ZedCloud a database, a cache, a bucket or an AI gateway is just another block on the canvas. Add one, draw a line to your app, and the app receives the connection details as environment variables.

What’s available

Section titled “What’s available”
DatabasesPostgres (with pgvector, PostGIS or TimescaleDB) and MySQL.
CacheValkey, a Redis-compatible key-value store.
Object storageAn S3-compatible bucket with a file browser.
AI gatewayLiteLLM: one OpenAI-compatible endpoint for OpenAI, Anthropic, Gemini and more.
SecretsEncrypted values shared with every linked app.
ObservabilityGrafana with logs, traces and metrics for the whole workspace.

How linking works

Section titled “How linking works”
api

running

main@7c21d0e

dbstaged

not deployed

Postgres

DATABASE_URL

cachestaged

not deployed

Valkey

REDIS_URL

filesstaged

not deployed

Object storage

S3_*

aistaged

not deployed

LiteLLM

OPENAI_BASE_URL

Linked and staged: these links inject their variables at the next Deploy.
  1. Add the service from the palette and give it a name.
  2. Drag from the app’s dot (or a cron job’s) onto the service to link them.
  3. Press Deploy. The app is restarted with the new variables.

The service always sets its main variable, for example DATABASE_URL for Postgres or REDIS_URL for Valkey. Each service page lists every variable it sets.

Common alternative names. Many apps read a different name, such as POSTGRES_URL or AWS_ACCESS_KEY_ID. ZedCloud scans your code on every build. When your code reads a well-known alternative name and not the main one, that name is set too, so most apps work with no changes.

Your own values win. A variable you set by hand on the app is never overwritten by a link.

Rename what the app sees. Every injected variable has a pencil button: rename DATABASE_URL to PRIMARY_DB and the app gets only the new name. Clear the name to go back.

Build values from parts. Your own variables can refer to fields of a linked node with ${label.field}:

Terminal window
DB_HOST=${orders-db.host}
PUBLIC_URL=${self.url}

${self.host} and ${self.url} are the app’s own address. The env panel has an insert a value from a linked node helper, and Split into parts writes DB_HOST, DB_PORT, DB_USER, DB_PASSWORD and DB_NAME for you. A reference to a node that isn’t linked is left as-is and the panel warns you before you deploy.

Accounts

Section titled “Accounts”

Databases, caches and some other services have accounts: separate logins with different rights. New databases come with an app account and a readonly account next to root.

  • Connect as on the link picks the account the app uses. Apps should use the app or a read-write account, not root.
  • Also inject adds up to 10 more accounts to the same app, as <VARIABLE>_<ACCOUNT> (for example DATABASE_URL_READONLY).
  • Up to 20 accounts per node. Names are 3 to 31 lower-case letters, digits or _, starting with a letter.
  • Rotating an account’s password means redeploying the apps that use it. You can’t delete an account an app still uses.

Size and data

Section titled “Size and data”
  • Memory 16 MB to 4 GB and CPU 0.1 to 4 per node. Without a setting a node gets 512 MB and 1 CPU.
  • Services that keep data have their own volume, which survives restarts and redeploys.
  • Some services have a size limit on their volume (volumeSizeMB, 64 MB to 50 GB). You get a warning at 80% and 100%; a node more than 10% over its limit is stopped until it is back under.
  • The service type (for example Postgres or MySQL) can’t be changed after it is created.