Skip to content

Secret handler

Tasks and endpoints regularly need a credential that has no business being in Git: an API key for a third-party service, a token for a partner feed, a password for a database of your own. PEACH keeps one secret store per codops for exactly this, and every key in it arrives in your code as an environment variable.

You edit that store yourself, from the Secrets page of your ops dashboard at https://<codops>.peach.ebu.io. No ticket, no pipeline variable, no redeploy of the platform.

Reading a secret in your code

There is nothing to import and nothing to configure. Every key in your codops' store is present in the environment of your Ray head and worker pods, so a task or an endpoint just reads it:

import os

api_key = os.environ["WEATHER_API_KEY"]

Prefer os.environ["KEY"] over os.environ.get("KEY") for a credential the code genuinely cannot run without: failing loudly at start-up is easier to diagnose than a None that becomes a 401 several layers down.

The same values are available in PEACH Lab and to scheduled tasks, so a notebook and the deployed job read the credential the same way.

Adding or changing one

Open Secrets on your codops' dashboard. The page lists every key with its value masked until you tick Show values, and records who last changed the store and when. Add a key, edit a value, save.

Reading and writing both require admin rights on your codops — an ordinary authenticated user does not see the page at all.

A saved secret is not a live secret

Saving writes to the store and the cluster picks the new values up on its own, but pods that are already running keep the values they started with. A new value only reaches your code on the next deploy.

The page offers Save and redeploy, which saves, waits until the cluster genuinely has the new values, and only then redeploys the tag you are running. Use it whenever the change needs to take effect now. Saving alone is fine for a credential you are adding ahead of the code that will use it.

Naming keys

Keys become environment variables verbatim, so give them names that are valid and unambiguous as such: upper snake case, no spaces or dashes, prefixed with the service they belong to — OPENAI_API_KEY, PARTNER_FEED_TOKEN, WEATHER_API_KEY.

Dev and prod each have their own store, reached from their own dashboard, so a key can hold a sandbox credential in dev and the real one in prod without the code branching on environment.

Some keys are the platform's, not yours

A few entries in the store are read by the platform itself rather than by your code — the basic-auth password fronting your APIs, your Redis password, and similar. They look like ordinary rows on the page. Renaming or deleting one does not fail at save time; it breaks the thing that depended on it at the next reconcile.

If you did not put a key there and do not recognise it, leave it alone and ask the PEACH team.

What belongs here

Credentials your code needs at run time. That is the whole of it.

It is not configuration — thresholds, feature flags, model names and endpoint parameters belong in your repository's PEACH configuration, where they are reviewable, versioned and roll back with a tag. A value in the secret store is invisible in code review and changes under a running system, which is exactly what you want for a password and exactly what you do not want for a tuning parameter.

Nor is it a place for personal data, or for a shared credential that several codops need — the store is per-codops by design, and copying one secret into several stores turns a rotation into a hunt.

Where to go next

  • The ops dashboard — the rest of what the same page gives you: deploys, endpoint health, traces and logs.
  • Python environments — the other half of "what my code has available at run time".
  • Redis & Redis Insight — reached with a platform-managed credential you do not need to handle yourself.