---
title: "Quickstart: your first repo"
url: https://loot.build/docs/quickstart
group: "Start"
status: written
summary: "A private .env living in a shared repo — the shortest path to seeing the thesis work."
---

# Quickstart: your first repo

> A private .env living in a shared repo — the shortest path to seeing the thesis work.

A private `.env` living in a shared repo — the shortest path to seeing the thesis work.

**This is a public alpha: the tool will change, your work is not at risk.** What that covers — your repo, the command surface, and anything hosted — is spelled out on [the install page](https://loot.build/install). What is currently broken is on [known issues](https://loot.build/known-issues).

```bash
# install
curl -sSf https://loot.build/install.sh | sh

loot init --identity alice

printf 'TOKEN=supersecret\n' > .env
printf '# My Project\n'      > README.md
printf '.env restricted=alice\n*.md internal\n' > .lootattributes

loot describe -m "initial work"   # records the tree AND names the change

rm -f .env README.md              # the plaintext is gone from the disk
loot surface                      # alice restores both, out of .loot/
```

The `.env` ciphertext lives in `.loot/` the whole time. Hand the whole thing to someone who was never granted a key — a second repo, with its own keypair — and it stays sealed:

```bash
loot new                        # finalize and sign it, so the change can travel
loot bundle ../project.bundle   # ciphertext + internal keys; a restricted key never rides

mkdir ../mallory && cd ../mallory
loot init --identity mallory    # a real second keypair, holding no grant
loot apply ../project.bundle
loot surface                    # README.md appears; .env stays sealed
```

mallory's `surface` writes no `.env` at all and says so — `1 sealed path(s) skipped`. She holds every byte of its ciphertext and no key for it. If she records and re-syncs, the sealed file is carried forward untouched — snapshot is visibility-aware, so a non-keyholder can never silently drop or expose content they can't read.

The name is not the key.

.loot/identity

holds the name loot prints; custody is

.loot/keyring

, and what opens a file is holding its key. Rewriting that file therefore hands you nothing — it cannot open content you had no key for, so it cannot stand in for a second identity. It is not inert in the other direction: the name is matched against a

restricted=

list at the moment you

seal

, so recording under a name that list omits writes content you will not be able to read back.

loot whoami

prints the name and the key together, which is where a parted pair shows.

For the other half — delivering a key, so a second identity _can_ read `.env` — run `loot tutorial`. Nine steps over a real relay, with `loot clone` and a sealed grant, in a throwaway temp dir: it touches no repo, key or global config of yours and deletes its tree on exit.