Keeping It Safe

Live is not the same as safe

Going live put your tool on the internet. Keeping it safe is the gate before it touches anything real. Four plain things stand between a tool that is merely live and one you can trust with a member's data.

The loop→Going live→Keeping it safe
The one idea behind safety
The instant your tool holds a real person's data, a name, a number, a payment, you are responsible for it. Safety is just the short list of ways you keep that promise.

None of this is hard, and Claude already knows every step. Four habits, and your job is to hold the line on them.

The gate

Four things, before real data

Walk these four before you point your tool at live member data. Tap each one for what it means and the exact move to make.

The gate01Who can see it
A login
Public but unlinked is fine for a quick demo. The moment your tool holds member data, it needs a login, so only people you allow can open it. An address that anyone can guess is not a lock.
The move

"Put a Google sign-in in front of this, and only allow my team's email addresses."

The gate02Never leak the keys
Keys in settings
Your tool talks to other services using secret keys. Those keys live in settings, never typed into the code and never pushed to a public place. A key in the code is a key anyone who sees the code can use.
The move

If you ever spot a key sitting in the code, stop: "move that key into settings and out of the code."

The gate03Do not touch live data carelessly
Pause and back up
Some actions cannot be undone, like changing the real database every member depends on. Claude pauses at those steps, and so should you: read what it is about to do, keep a backup, then say go. Slow is safe at the steps you cannot reverse.
The move

"Before anything that cannot be undone, stop and show me first." Put that line in your standing rules.

The gate04The padlock
HTTPS
The padlock in the address bar means the data is scrambled on its way between the member and your tool, so no one in between can read it. It is the difference between a sealed envelope and a postcard.
The move

Nothing to do: it turns on by itself when you go live. Just check the padlock is there before you trust it with real data.

Four habits. Claude keeps them by default, and you keep it honest.

The big one

Where a key should and should not live

This is the one that bites people. A secret key sitting in your code is like writing your PIN on the front of your card. Here is the same key, done wrong and done right.

×In the code
# saved in your code, pushed to the repo key = "sk_live_8e2c4a7b9f"

Anyone who can see the code can see the key, and use it. Once it has been pushed, treat it as leaked.

✓In settings
# kept in settings, hidden, never in the code SECRET_KEY = •••••••• # the code just asks for it by name key = settings.SECRET_KEY

The code never holds the key, it only asks for it by name. The secret stays in settings, where it belongs.

We did not print a real key anywhere on this page, on purpose. That is the rule, modelled.

Who gets in

A login, in plain words

Sign in with Google is the simplest safe door, and you have walked through it a hundred times already.

1

One button

The person clicks Sign in with Google. No new password to invent, and none to forget.

2

Google vouches for them

Google checks who they are and tells your tool yes, this is them. Your tool never sees their password.

3

You hold the list

You decide which email addresses are allowed in. Everyone else is turned away at the door.

Set up the login, step by step

a
Ask Claude to add it. Claude writes the sign-in for you and sets it to let in only the email addresses you name.
b
Make the Google side, one time. Claude walks you through creating a sign-in app in Google's console. You copy two values it gives you: a Client ID and a Client Secret.
console.cloud.google.com OAuth client created Copy these two values. You need them once. CLIENT ID 84031975320-k2hq…apps.googleusercontent.com CLIENT SECRET GOCSPX-•••••••••••• Treat the secret like a password. It goes straight into settings, nowhere else.
What you'll see · Google's console, the two values to copy
c
Paste them into settings, not the code. Exactly like the keys rule above: those two values go in your settings, where Claude shows you, and never into the code.
coolify · your tool · settings Environment variables Hidden from the code, hidden from the repo, available to your tool. GOOGLE_CLIENT_ID •••••••••••••••• GOOGLE_CLIENT_SECRET •••••••••••••••• Dots, not values. If you can read a secret on screen, so can a screenshot.
What you'll see · the two values in settings, as dots
d
Test the door. Open your tool. You get the Google sign-in screen, you sign in, you are through. Anyone not on your list is turned away.
https://app.yourstudio.com Your Tool Sign in to continue G Sign in with Google Only approved email addresses get past this screen.
What you'll see · the door, before anything else loads
Say to Claude
"Add a Google sign-in to this and only let my team's email addresses in. Walk me through the Google setup."

Done once. From now on, only the people you choose can open it.

🔒
Yours now

Build the loop. Ship it. Lock it down.

That is the whole journey. You learned the loop that builds anything, you took it live, and you locked it down before it touched real data. The tool is yours, the address is yours, and so is the method. Go build the next one.

↻ Back to the method