Replit secrets: configure values and keep a safe recipe
Keep credentials out of code, test the settings your app needs, and save a setup recipe that contains names and checks without secret values.
Updated 5 min read
Use Replit’s documented Secrets workflow for credentials instead of embedding them in source files, and verify that the running app can use the settings it needs. Keep the setup instructions separate from the values: Replit’s projects and files guide (opens in a new tab) also warns that copied apps need secrets and deployment configuration set up again. fenbs can keep the names, purpose, checks, and next step without holding the credentials.
What belongs in a secret and what belongs in the recipe?
A secret is a value that grants access, such as an API key or service password. An environment variable is a named setting that an application reads while it runs. Some environment variables hold secrets; others hold ordinary settings. Treat the value according to what it allows someone to do, rather than assuming every setting is safe to share.
Your recipe should explain what the application expects without supplying the private value. For example, “The email service needs a credential supplied by the account owner” is useful to a teammate. Copying that credential into a task, chat, screenshot, or example file creates another place you have to protect.
| Keep in the setup recipe | Keep out of the setup recipe |
|---|---|
| The exact setting name your code expects. | The secret value. |
| Why the app needs it and which feature uses it. | A screenshot that exposes the credential. |
| Who can supply or replace it. | Sign-in details or private recovery information. |
| A harmless way to check that the feature works. | Logs that print the value during testing. |
How should you prepare and enter the required values?
Start from the application’s requirements rather than adding settings at random. Find the names the code expects and identify which service supplies each value. Follow the current Replit setup guidance (opens in a new tab) for entering secrets. Use your app’s actual setting names and obtain the values from the service owner.
- List each required setting name and the feature that needs it. Mark private values so nobody copies them into the shared recipe.
- Confirm which running app you are configuring. Keep a test setup distinct from a published app when recording your work.
- Get the correct value from the person or service responsible for it. Check that it belongs to the intended account and use.
- Enter the value through the documented Secrets workflow, checking the name against the code that reads it.
- Run a harmless check of the dependent feature and record the outcome without displaying the value.
Check for simple input mistakes before changing application logic: an unexpected space, a misspelled name, an omitted setting, or the wrong account’s credential. Change one suspected issue at a time. If someone else supplies the credential, they can enter it themselves while you keep only the instructions and the result.
How can you test access without exposing the value?
Test the smallest behavior that proves the app has what it needs. A presence check can tell you whether a required setting is available without printing it. A separate test action can tell you whether the outside service accepts it. Those results answer different questions: a value can be present and still be wrong or lack the required access.
- Check that the app reads the exact expected setting name.
- Report only whether the setting is present or missing.
- Use a test action with a result you can recognize and undo when necessary.
- Record the service’s error text only after removing credentials and private information.
- Repeat the relevant check in the published app before declaring the task complete.
Keep test results precise. “The setting is present, but the service refuses the request” is more useful than “Secrets broken.” Replit’s Project Editor overview (opens in a new tab) describes an editor with a running preview and publishing tools. Record where you tested so the next person does not mistake a preview result for a published-app result.
What should you check when a setting appears missing?
Ask four questions in order: which app is failing, which setting does its code expect, where was that setting configured, and what evidence shows the value can be used? This keeps the investigation focused. Repeatedly replacing a key without answering those questions can hide a name mismatch or a configuration problem.
A copied app is an important case. Replit explicitly says that copying project files does not finish a move: secrets, the database, and deployment configuration must be set up again. Review the destination’s requirements rather than assuming that a working source app proves the copy is ready. The Replit Agent introduction covers the assistant itself, while Claude Code versus Replit covers a broader choice of working environment.
If the failure is tied to a new address, use the separate Replit custom-domain checks to compare the published destinations. Keep an address failure separate from a missing runtime setting until the evidence links them. This makes the next fix easier to review and the result easier to explain.
What should you save for the next person?
Keep a short recipe with the setting name, purpose, who supplies it, where you tested, and the expected outcome. Add the next step when a check fails. The record should let another person set up an authorized environment without asking you to send a credential through chat.
Setting name: EMAIL_SERVICE_KEY Purpose: send test messages from the app Supplied by: the person who manages our email service Value: never included in this recipe Check: send one message to a test inbox we control Result: record the outcome and where it was tested Next step: name the first unfinished check
Update the recipe after a configuration change, and remove instructions that no longer apply. A saved record should explain the present setup, not collect every abandoned attempt. The AI at work guides cover saving useful outcomes, and how fenbs works explains how connected assistants use the same record when they return.
Never lose the work you did in an AI session
After a useful AI session, save it in fenbs: the key observations, findings, research and context. Then carry on from exactly where you left off, on any device and in any other AI. The next AI you connect reads it at the start of the session, so you never have to explain the same problem again.
Create a free accountFree for up to 5 people and 50 open tasks · No credit card · Works with Claude, ChatGPT, Cursor and more
How to keep your setup recipe with fenbs
Keep the work so you can carry on from exactly where you left off, on any device and in any other AI. Save the instructions and checks that make the setup repeatable. Leave every password, token, connection string, and secret value out.
- Create a free account.
- Connect Replit to fenbs through Integrations, using its supported connection to an outside tool.
- Save the setting names, what each one is for, who can supply it, and how to check it. Include no values.
- Ask your assistant to save what passed and the next unfinished step after testing.
- When you return, ask your connected AI to read that recipe before making further changes.
Replit’s connection guide (opens in a new tab) explains connecting Agent to outside tools and notes that some actions require confirmation. fenbs keeps the work record; it is not a credential vault. A small app with a stable setup may need only a short local recipe, provided it also leaves the private values out.