Deploying & scaling Rindle

Rindle has one authoritative HCTree write master. A plain SQL deployment can stop there. A synced deployment adds one or more read-only rindled followers for named queries, incremental views, and subscriptions. Every successful write still receives one total commit order, no matter how many transactions execute concurrently or how many followers serve reads.

Applications see one edge, not those individual processes:

RINDLE_URL=https://app.example.com
RINDLE_DATABASE_TOKEN=<server-only-bearer>

The edge routes SQL and migrations to the master and follower protocols to the selected read replica. A query lease tells the browser which public WebSocket endpoint and follower-affinity ticket to use. The ticket controls placement, not authorization.

# Deployment shapes

# Master-only SQL

The smallest durable shape is one rindle-replicator. Its HCTree database is the authoritative state and it serves the public SQL surface, interactive transactions, ordered migrations, and backup shipping. Use it with @rindle/sql-client, Drizzle, or rindle sql when live queries are not required.

# Master plus one follower

Add one rindled follower for the complete synced-app stack. The follower restores from the master’s lineage, tails its journal into a WAL2 SQLite database, and owns materialized queries and live subscriptions. The pair can share a host for local or small deployments. They remain separate processes.

# Read-scaled fleet

One master can feed multiple followers. Reads, distinct materializations, and subscriptions scale across them while all writes retain the same sequencing point. A stable edge and signed affinity tickets keep each browser’s lease and WebSocket on one follower and re-place it after a failure.

This multi-follower shape is built for self-hosting. It is not currently a Rindle Cloud SKU.

# Writes: one order, concurrent execution

“One write master” does not mean “one transaction at a time.” The master pools HCTree BEGIN CONCURRENT connections. Disjoint transaction bodies can execute in parallel. HCTree validation assigns successful commits the cid that defines the journal order.

• RINDLE_WRITE_CONNECTIONS controls open transaction capacity (default 8).
• RINDLE_WRITE_THREADS controls execution parallelism (default 1). Raise it toward the cores available to the master.
• Replayable pure-write conflicts retry inside the master.
• A read-bearing conflict re-drives the authoritative mutator, because replaying only its generated SQL is unsound.

Followers scale reads. Adding another write master is an application-level sharding decision, not a replica-count change.

# Local lifecycle

rindle dev owns the normal development lifecycle in one command:

rindle dev --migrate --gen shared/schema.gen.ts -- \
  vite dev --port 3000

It:

1. evaluates rindle.ncl once
2. starts the master, followers, and rindle-dev-edge
3. waits for readiness
4. applies and watches migrations
5. generates and watches schema
6. injects RINDLE_URL plus RINDLE_DATABASE_TOKEN
7. forwards signals
8. stops the fleet with the app command

When you need to supervise only the data fleet, use rindle up. rindle exec -- … remains as a compatibility adapter that runs one command with bindings derived from rindle.ncl. For new projects, use rindle dev.

The native development edge always runs, even for one follower, so local code exercises the same unified ingress and affinity path as production.

# Durability and recovery

With a backup block, the master ships logical journal segments and portable bases to an S3-compatible store. The durable manifest watermark bounds local journal garbage collection. Maintenance compacts segments, creates new bases, enforces retention, and scans for orphans. Off-master rindle backup drill jobs prove the same generation can be restored.

A new follower restores a WAL2 database from the latest portable base and replays the tail. A replacement master restores and promotes an HCTree leader from the same lineage. A follower older than retained history restores instead of requesting an unbounded replay.

# Rindle Cloud on OVH

Rindle Cloud’s Cloudflare-hosted control plane records billing, placement, DNS, and versioned intent. It commits desired state to the fleet repository. rindle-poold converges packed processes on the assigned OVH box and reports the applied generation. Cloudflare Tunnel publishes the stable app-<id>.rindle.cloud ingress.

The hosted menu is deliberately fixed:

• SQL, $5/month — master only.
• Sync, $10/month — the same master plus one follower on the same fleet box.

Each serving process gets a 5 GB database, 1 CPU, and 512 MB of memory. Streaming backup is included. The dashboard does not currently expose host, region, machine-size, volume-size, or follower-count controls.

# What is available

# Run it yourself, or have us run it

• Self-host — operate the master, followers, edge, backup lineage, and restore drills in infrastructure you control.
• Rindle Cloud — use the fixed SQL or Sync plan on Rindle’s packed OVH fleet and let the control plane converge it for you.

Both use the same schema, SQL client, API server, browser client, migration files, and correctness contract.

# Next steps

• Cloud quickstart — provision SQL or Sync.
• Connect your app — use one URL and one token.
• The three-tier architecture — the application shape around the data tier.
• Run the daemon — the read-only follower in full.