Setting a secret

Everything optional in Charcha is switched on by putting a value on your Worker. Turnstile, email notifications, the dashboard password: all the same operation, done once per value.

You do not need a terminal, a checkout, or anything installed. If you deployed with the button, the dashboard is the shorter route anyway.

From the Cloudflare dashboard

Six clicks, and it takes effect on the next request. Nothing needs redeploying.

1. Open the Cloudflare dashboard and go to Compute (Workers).
2. Click your Charcha Worker in the list. If you took the default it is called charcha.
3. Go to Settings.
4. Find Variables and Secrets and click Add.
5. Set Type to Secret, put the name in Variable name, and paste the value.
6. Click Deploy.

The name has to match exactly, character for character, including case. TURNSTILE_SECRET_KEY is not the same as Turnstile_Secret_Key.

Choosing Secret rather than Text matters. A secret is write-only once saved: you can replace it, and nobody can read it back out of the dashboard, including you. A plaintext variable is visible to anyone with access to that Cloudflare account.

Cloudflare’s own page on this is Environment variables and secrets, which stays current if their interface moves.

Changing one later

Same path, except the existing row has an Edit next to it. Replacing a value is how you rotate a leaked key, and it is the only way to revoke the dashboard password, since there is no reset link and no second account.

Replacing CHARCHA_DASHBOARD_PASSWORD signs out every open session, including the one you are doing it from. Sessions are signed with a key derived from the password rather than stored anywhere, so there is nothing to revoke individually and a new password invalidates all of them at once. That is worth expecting rather than discovering mid-triage, and it is also the only way to end a session you no longer trust.

Use a generated value, openssl rand -base64 24 or whatever your password manager offers, and keep it there. This password is typed once and never from memory, so a memorable one buys you nothing.

Your dashboard warns you when it is shorter than 15 characters, which is NIST’s figure for a password used on its own without a second factor. That is a length check and only a length check. A long password that has turned up in a breach somewhere is no safer, and nothing in Charcha has looked. Generating a fresh one settles both questions at once.

Checking it landed

Your Charcha dashboard has a Setup tab at /admin that reports which values the Worker can see. It shows whether a secret has something in it, never what the something is. That is the fastest way to confirm you typed the name right, and it is worth looking at once after each value you add.

From a terminal, if you prefer

If you have a checkout of the repository Cloudflare created and Node installed:

pnpm wrangler secret put TURNSTILE_SECRET_KEY

It prompts for the value rather than taking it as an argument, so the secret does not end up in your shell history. Swap the name for whichever value you are setting.

This is genuinely optional. It exists because some people would rather type than click, not because the dashboard route is a workaround.

The values Charcha reads

Name	Turns on	Where it comes from
CHARCHA_DASHBOARD_PASSWORD	The moderation dashboard at /admin	You choose it. Collected during deploy
IP_HASH_SECRET	The per-address half of the rate limit	Any long random string. Collected during deploy
TURNSTILE_SECRET_KEY	The bot check	Cloudflare Turnstile, when you add a widget
RESEND_API_KEY	Email when a comment arrives	Resend
AKISMET_API_KEY	Checking comments against Akismet	Your account at akismet.com

The first two are asked for while you deploy, because Charcha cannot run usefully without them. The rest are yours to add whenever, and everything they control stays off until you do.

AKISMET_API_KEY is the only one that changes what your readers are owed. Turning Akismet on sends a commenter’s IP address, email and words to Automattic, so read what it sends before you set it.

The four values that stopped being secrets

Your notification addresses, your site’s home page address and the allowed origins are not secrets. They are ordinary rows in your database, so the Setup tab in your dashboard has a field for each and a Worker can write them. Asking you to open a terminal to change an address printed on your own site was never the right shape.

Three names still work if you set them before that changed: CHARCHA_NOTIFY_FROM, CHARCHA_NOTIFY_TO and CHARCHA_SITE_URL. A deployment running on them carries on running. The Setup tab says where each value is coming from and offers to take it over, and once you have saved it there you can delete the secret.

Email is still all or nothing. The key and both addresses are needed together, and setting some of them leaves the feature off rather than half on. Email notifications covers the rest.

When nothing seems to happen

Every one of these fails quietly by design, which is helpful for readers and unhelpful for you. Two checks catch nearly everything.

Look at the Setup tab first. If it says a value is missing, the name is wrong or the save did not go through, and no amount of staring at Resend or Turnstile will help.

If Setup says the value is there and the feature still does nothing, the value itself is wrong. A mistyped Resend key produces silence rather than an error, and silence is indistinguishable from the feature being switched off. Turnstile has a louder failure: a secret with no matching sitekey on your page holds every comment for review, so your queue fills with ordinary-looking comments. Add it to your site covers that pair.