Connect your app to Rindle Cloud

After you provision a database with the Cloud quickstart, connect your server code with its URL and database token. This page covers the SQL and Sync plans. A Postgres-sourced app uses the Rindle connection for reads and subscriptions, with a separate connection to its Postgres write authority. These are the same two values that rindle dev supplies for local development.

Use the SQL client for ordinary database requests. On the Sync plan, an API server can also authorize named queries and mutations for browser clients.

# The two values on your dashboard

Open the app’s Connect panel:

An app URL looks like https://app-<id>.rindle.cloud. The edge routes each protocol to the right process: writes reach the HCTree master. Sync reads and live-query traffic reach its follower. You do not configure master, follower, control-plane, or WebSocket addresses separately.

The token is a per-app secret. Put it in the API server’s secret store, never source control or browser-visible environment variables.

# SQL services and scripts

Use @rindle/sql-client for a SQL-plan app or ordinary server-side SQL against either plan:

import { createSqlClient } from "@rindle/sql-client";

export const db = createSqlClient({
  url: process.env.RINDLE_URL!,
  authToken: process.env.RINDLE_DATABASE_TOKEN!,
});

const rows = await db.execute({
  sql: "select id, title from issue where status = ?",
  args: ["open"],
});

The CLI uses the same values:

rindle sql "select count(*) from issue"
rindle sql --file scripts/backfill.sql

Several statements passed to rindle sql are applied as one atomic batch. For versioned schema or data changes, use rindle migrate apply instead.

# Synced app API server

On the Sync plan, continue the manual synced-app quickstart or use the scaffold. Those guides define the schema, named query registry, shared mutators, HTTP adapter, and browser client.

Set these environment variables on your deployed API server:

RINDLE_URL=https://app-<id>.rindle.cloud
RINDLE_DATABASE_TOKEN=<token-from-connect-panel>

The quickstart already reads both values and supplies them to createRindleApiServer as rindle: { url, token }. It also converts shared mutators with sharedApiMutators. Keep that wiring and replace the demonstration identity with your application’s authenticated session.

@rindle/api-server provides transport-independent handlers. Mount them in the server framework you deploy; The API server shows the boundary. Cloud hosts the data tier, not this application HTTP adapter.

# Browser client

Keep the browser client pointed at your application’s API. The quickstart uses api: { url: "" } for same-origin /api/rindle/* routes. If the API has a separate origin, configure its URL, credentials, and CORS policy for that deployment.

An authorized query lease returns the public WebSocket endpoint and a signed follower-affinity ticket. The ticket keeps lease and subscription traffic on the same follower. It is placement metadata; your API still authorizes each query. The browser never receives the database token.

# Local and Cloud use the same contract

For the same SQL or Sync topology, your schema, queries, mutators, SQL calls, and browser setup do not change between local and managed environments. Postgres requires its own source and mutation-backend setup.

# Migrations

After rindle deploy or rindle link has written .rindle/cloud.json, apply the same ordered migration files remotely:

rindle migrate status --cloud
rindle migrate apply --cloud

The binding is safe to commit. It identifies the app but contains no database token. The CLI authenticates the Cloud proxy with your rindle login session.

# Next steps

• SQL client — queries, sessions, transactions, and Drizzle.
• The API server — named queries and authoritative mutators.
• The browser client — optimistic writes, live views, and rebase.
• Scale & operate — plan changes and fleet convergence.