Saphan StudioDocs
Deployment

CouchDB: the one step that is left to your hand

The wizard names this step and does not guess at it — the databases to create, the security document each one needs, and the setting that cannot be changed later.

Saphan keeps law and evidence in CouchDB. The first-run wizard tests the address you give it and writes the credentials, and then it names one step and stops: creating the databases is not automated.

That is deliberate, and it is worth understanding before you do it by hand. The database names, the roles that may write to each, and one storage setting that cannot be changed after the databases exist are decisions about your deployment. A wizard that guessed at them would be guessing at something irreversible.

The installer is resumable. Do this step, then run the same command again and it continues from where it stopped.

1 · The system databases

The CouchDB image does not create them. Until they exist, authentication and the change feed behave in ways that are easy to misread as bugs — so this is the first thing to do, not a detail. With your admin credentials:

curl -X PUT -u "$COUCHDB_USER:$COUCHDB_PASSWORD" http://127.0.0.1:5984/_users
curl -X PUT -u "$COUCHDB_USER:$COUCHDB_PASSWORD" http://127.0.0.1:5984/_replicator
curl -X PUT -u "$COUCHDB_USER:$COUCHDB_PASSWORD" http://127.0.0.1:5984/_global_changes

2 · Four databases, one per class of thing Saphan stores

The four classes differ in how they change and in whether they can be rebuilt, and that is what decides your backup duty:

classchanges byrebuildable?
lawa ratification actyes — it can be dropped and rebuilt from the repository
working materialsupersessionno — the database is the only copy
recordappend onlyno — the database is the only copy
telemetryappend onlyno — the database is the only copy

Three of the four are the only copy of what they hold. Whatever backup you run, it has to cover those three.

The names are yours to choose. Create one database per class:

curl -X PUT -u "$COUCHDB_USER:$COUCHDB_PASSWORD" http://127.0.0.1:5984/<your database name>

3 · A security document per database

Each database needs a _security document restricting who may write to it. The shape is the same; the role differs by class:

curl -X PUT -u "$COUCHDB_USER:$COUCHDB_PASSWORD" \
  http://127.0.0.1:5984/<database>/_security \
  -H 'Content-Type: application/json' \
  -d '{"admins":{"names":[],"roles":["<role>"]},"members":{"names":[],"roles":[]}}'
databasewho writesshape
lawthe ratification act alonesingle writer, world read-only
working material, recordthe engine's own actengine-written
telemetrythe capture path onlycapture-only

The role names are yours, and they must match the credentials the engine and the capture path actually authenticate with. A role named here that nothing authenticates as is a database nothing can write to.

4 · The setting you cannot change afterwards

CouchDB's shard and replica counts — q and n — are fixed when a database is created and cannot be changed later. Changing your mind means creating new databases and copying the data across. Decide them before step 2, not after.

When it is done

Run the setup command again; it continues from where it stopped, and Verifying an install is how you check what you have.

On this page