Alchemist: Adding Environment Variables and Secrets
Add a Stripe key or other secret directly in project Settings, or ask your project's agent for a secure link, no pasting values into chat, ever.
Some environment variables come pre-injected: storage, transactional email, and session signing work out of the box, so you don’t provision them yourself. Everything else, a Stripe key, a third-party API token, a feature flag, you add. There are two ways: type it directly into your project’s Settings, or ask your project’s agent for a secure link. Neither one ever puts the raw value in chat.
Pre-injected variables
| Variable | Purpose |
|---|---|
JWT_SECRET | Per-project secret for signing session cookies. Used by the auth middleware. |
R2_ENDPOINT, R2_BUCKET, R2_ACCOUNT_ID, R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY | Cloudflare R2 (S3-compatible) credentials for uploads. Every object key your project writes MUST start with its own R2_KEY_PREFIX, which is per-project and pre-injected alongside them. |
SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD, EMAIL_FROM | SMTP2GO transactional email credentials. Use EMAIL_FROM verbatim for the From header. |
The agent knows about these and reaches for them automatically when you ask for features that need storage or email, image upload, password reset emails, signup confirmations, and so on.
The email and storage variables above are a platform-managed group: bringing your own sender or your own storage account means overriding every variable in that group together, never just one. Setting only EMAIL_FROM to your own domain, for example, sends your mail through the platform’s SMTP account under a sender it never verified, and delivery fails outright. Tell your project’s agent you want to bring your own mail or storage account, and it walks you through overriding the whole group.
Auth providers (opt-in)
Email OTP login is always on. OAuth providers register themselves when both halves of their credential pair are present:
| Provider | Variables |
|---|---|
GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET | |
| Microsoft | MICROSOFT_CLIENT_ID, MICROSOFT_CLIENT_SECRET |
| GitHub | GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET |
Add the pair using either method below and the login page picks up the new button on the next deploy. No code change required.
Adding your own: directly in Settings
If you have dashboard access, this is the fastest path. Open your project at build.chipp.ai, go to Settings, and find the Credentials panel. It lists every variable your project knows about, grouped by integration, each with a status pill (needed or populated). Nobody, including Chipp staff, can ever read a populated value back out, the pill just flips color.
- Click a row to open it and type the value in directly. A single-line value gets a plain text field; a certificate, private key, or service-account JSON gets a textarea that survives pasted newlines.
- Need a variable that isn’t listed yet? Use Add manually to create a new one by name.
- A banner tells you when something changed since your last deploy, so you know to redeploy before the new value takes effect. Values apply automatically at the next deploy either way.
Adding your own: the secure link
Use this when you don’t have dashboard access yourself, or you’re handing the job to a contractor, client, or teammate who shouldn’t need a Chipp account. Ask your project’s agent, in the dashboard chat or in Slack:
@storefront-agent I need to add a STRIPE_SECRET_KEY to this projectThe agent mints a link and posts it back in the same conversation. Nothing else needs to happen first, you do not need a ticket running. Opening the link takes whoever has it to a small form at build.chipp.ai, no Chipp account required, and it applies the same way: automatically, at the next deploy on a managed project.
- The link expires, seven days by default. Ask your agent for a shorter or longer window if you need one.
- On a BYO-repo (dispatch-only) project, there is no deployment for Chipp to write into, so the agent gives guidance to relay to you instead of a link, unless the credential is for the agent’s own browser automation (logging into a third-party portal on your behalf), which always gets a link regardless of hosting mode.
- Treat the link like a password-reset link: share it only with the person who should submit the value, and let it expire rather than reusing it.
What NOT to commit
Never commit secrets to the repo. Every variable above, platform-injected or your own, is read from the environment, not from a checked-in .env file.
FAQ
Can I just tell the agent the value directly in chat? No, and it should refuse. If an agent asks you to paste a secret value directly, that is a bug, ask it to mint the link instead, or add it yourself in Settings.
Does the secure link work outside a running ticket? Yes. A ticket that pauses mid-run because it hit a missing credential uses this exact same mechanism, see Answering Agent Questions. The difference is you do not need a ticket running at all, you can ask proactively, any time.
What if I need more than one secret at once? Ask for all of them in the same message. One link can collect several named values. In Settings, just add each one as its own row.
Next steps
For the mid-ticket version of the secure link, see Answering Agent Questions. For connecting your project’s agent to Slack in the first place, see Your Project’s Agent in Slack.