## fctc-website-under-construction pulumi-worker

This deploys the fctc under construction page into a Cloudflare worker using Pulumi.

### Bootstrap
Ran this from <repo-root>/infra/
```bash
uv init --no-readme --no-workspace
uv add pulumi pulumi-cloudflare
uv lock

pulumi logout  # this is here incase you were already logged into some pulumi backend

pulumi login --local  # this keeps Pulumi's state in a local file.  see ./notes/STATE.md

export PULUMI_CONFIG_PASSPHRASE=""
pulumi stack init dev  # setting the passphrase to an empty string for now.  see ./notes/PASSPHRASE.md

export CLOUDFLARE_API_TOKEN=...  # NOT pulumi config.  see ./notes/CLOUDFLARE.md

pulumi config set accountId  # see ./notes/CLOUDFLARE.md
```

### The Cloudflare token goes in the environment, not the config

`pulumi config set --secret` writes the value into `Pulumi.dev.yaml` as ciphertext, and
that file is committed. With the local backend the stack's secrets provider is a
passphrase, and this stack's passphrase is the empty string, documented three lines above.
Committed ciphertext plus a committed salt plus a documented passphrase is not encryption
— it is the token, spelled differently, readable by everyone with access to this repo.

`pulumi-cloudflare` reads **`CLOUDFLARE_API_TOKEN`** from the environment when
`cloudflare:apiToken` is absent, so nothing in `__main__.py` changes and neither does
`pulumi up`. The token just stops living in git.

**The empty passphrase is not the problem and does not need fixing.** It protects nothing
because nothing secret is in config any more, which is the arrangement that makes it
harmless. It becomes a problem again the moment someone runs `pulumi config set --secret`
— so if this stack ever does need a secret at rest, change the secrets provider first.
See `./notes/PASSPHRASE.md`.

### Brind it up
```
pulumi up
```