What is CouchDB's permission model — admin party, database admins, and database readers?

CouchDB has a two-tier permission hierarchy: server-level admins and database-level members. Understanding each tier and the dangerous default state ("admin party") is essential before deploying any CouchDB instance.

Admin Party — when CouchDB is first installed, there are no server admins configured. In this state, every request (including anonymous HTTP calls) has full admin privileges. This is the admin party. You must immediately create at least one server admin via Fauxton or the API to exit admin party mode. CouchDB 3.x requires an admin to be set during installation and will not start without one.

# Create the first server admin (exits admin party)
curl -X PUT http://localhost:5984/_node/_local/_config/admins/admin \
  -d '"mys3cretpass"'

Server Admins — stored in the CouchDB config file (not the _users database). They can create/delete databases, manage all users, and access all databases. There is no per-database restriction for server admins.

Database-level Security — set via the _security document on each database. Contains two lists:

• admins — users and roles that can write design documents and manage the database's security settings.
• members — users and roles that can read and write regular documents. If the members list is empty, the database is public-read.

Regular users are stored in the _users database as documents with IDs like org.couchdb.user:{username}. Roles are arbitrary strings assigned to users and checked against the database security object.