# One state, two people
Keep the state in a store that a team shares, and see what two checkouts of one root share and what each keeps to itself. Who did what, and the mistake that makes two estates out of one.
Level: intermediate · Time: 12 minutes · Needs: B7 and Lab 2
You will learn: Where does the state live when two people work on one root? What does the state record about who changed what? How does a checkout end up with an estate of its own?
Done when: Dan's checkout plans no changes after Ada applied, pravo state log names both actors, and you can say why a wrong prefix is a second estate.
Track B ran everything on one machine, with the state in a directory next to the specification. A team does not work that way. Two people have two checkouts of one repository, and the state has to be where both can reach it. In OpenTofu that is a backend block, and the state is one file that every apply downloads, rewrites and uploads under one lock.
:::compare
```hcl title="backend.tf"
terraform {
backend "s3" {
bucket = "northwind-state"
key = "prod/terraform.tfstate"
region = "eu-west-1"
}
}
```
```cue title="main.cue"
$settings: pravo.#Settings & {
state: pravo.#S3State & {
backend: "s3"
bucket: "northwind-state"
prefix: "prod"
region: "eu-west-1"
}
}
```
:::
pravo keeps the state as one record per resource, in a store that the specification names. Two checkouts of the same root read and write the same records, each apply locks the records it writes and no others, and every change is a transaction that says who ran what. This track follows a team of three, Ada, Dan and Eve, and in this lesson two of them share a state for the first time. Every lesson of the track runs against `tools/fakes3`, the in-memory S3 server in pravo's source, on port 9000, so nothing here needs an account.
:::figure Two checkouts of one root. The specification is in each checkout, the records are in the bucket, and a transaction names the actor that wrote it.
:::
## Point the root at a store
Work in an empty directory. Ada's checkout is `ada/`. The `$settings` block names the store, and everything else is a root as in Track B. The endpoint and `path_style` are for the in-memory server; a real bucket needs the bucket, the prefix and the region, and the credentials that the AWS tools already use.
```cue file=ada/main.cue title="ada/main.cue" hl="8-16"
package team
import (
"pravo.dev/pravo"
rnd "pravo.dev/providers/hashicorp/random"
)
$settings: pravo.#Settings & {
state: pravo.#S3State & {
backend: "s3"
bucket: "northwind-state"
prefix: "prod"
region: "eu-west-1"
endpoint: "http://127.0.0.1:9000"
path_style: true
}
}
$random: rnd.#Provider
port: $random.#Resource.random_integer & {min: 20000, max: 29999, seed: "web"}
```
Ada initialises the root and applies. `--actor` names her in the transaction and `--reason` says why. pravo records both and verifies neither; the lesson [Seal the state](c03-seal-the-state.md) adds a name that is verified.
```sh run
pravo -C ada init > /dev/null
pravo -C ada --actor ada --reason "Reserve a port for the web server" apply --auto-approve | tail -n 1
```
```text out
Apply complete! Resources: 1 added, 0 changed, 0 destroyed. [txn ]
```
Nothing was written next to `main.cue`. The records went to the bucket, and `pravo state pull` copies them to a directory to look at:
```sh run
pravo -C ada state pull copy
find ada/copy -type f | sort
```
```text out
Copied 4 objects from s3://northwind-state/prod to copy
ada/copy/meta.json
ada/copy/outputs.json
ada/copy/resources/port.json
ada/copy/txn/.json
```
One object for the record of `port`, one for the transaction that wrote it, one for the outputs, which are empty so far, and `meta.json` for the state as a whole. A second resource would be a second object. That is the whole difference from one state file, and everything in this track follows from it.
## A second checkout
Dan clones the repository. Here a copy of Ada's checkout stands for the clone, `cue.mod` included: a root is the files, and the store is named in them.
```sh run
cp -r ada dan
rm -r dan/copy
```
:::predict Dan runs `pravo plan` in his checkout. Ada's apply wrote nothing into his directory. What does the plan say?
Ask where the plan reads the records from.
::reveal
`No changes`. The plan reads the records from the bucket, and the bucket already holds `port`. Dan's directory holds the specification, which is the same as Ada's.
:::
```sh run
pravo -C dan plan | tail -n 2
pravo -C dan state list
```
```text out
No changes. The specification matches the state. 1 record was not read; run pravo drift to compare it with the infrastructure.
Graph: planned 0 · skipped 1 · not read 1
port
```
Dan adds a resource and applies it under his own name.
```cue file=dan/main.cue title="dan/main.cue" hl="21"
package team
import (
"pravo.dev/pravo"
rnd "pravo.dev/providers/hashicorp/random"
)
$settings: pravo.#Settings & {
state: pravo.#S3State & {
backend: "s3"
bucket: "northwind-state"
prefix: "prod"
region: "eu-west-1"
endpoint: "http://127.0.0.1:9000"
path_style: true
}
}
$random: rnd.#Provider
port: $random.#Resource.random_integer & {min: 20000, max: 29999, seed: "web"}
pet: $random.#Resource.random_pet & {length: 2}
```
```sh run
pravo -C dan --actor dan --reason "Name the web server" apply --auto-approve | tail -n 1
```
```text out
Apply complete! Resources: 1 added, 0 changed, 0 destroyed. [txn ]
```
## Who did what
Ada has not pulled Dan's commit yet. Her checkout still says one resource, and the state says two. `pravo state log` lists every transaction, newest first, with the actor, the reason and the records it wrote:
```sh run
pravo -C ada state log | head -n 12
```
```text out
apply applied