Separate your environments with gateways

The first question most teams have after connecting Salyro is how many gateways they need. For environments the answer is straightforward: one per environment, decided before any traffic runs.

This guide sets that up and then says precisely what it gets you — because the separation is only worth the extra configuration if you know which problems it removes.

Why the split happens here

Salyro's hierarchy is an account and its gateways, and nothing in between. There is no organization, no team and no project layer to separate environments with, and none is planned for this version.

That is not a gap being worked around. The gateway is already the isolation boundary — it owns its provider credentials, its API keys, its logs and its usage figures, and shares none of them — so a second grouping above it would add a name without adding a boundary.

Setting it up

1. Create one gateway per environment

   Name them for the environments themselves — production, staging, development. The names appear beside every cost figure and every log entry you will read later, so they are worth choosing once and leaving alone.

2. Connect provider credentials to each gateway

   A credential belongs to one gateway, so each environment needs its own — even when every one of them comes from the same provider account. Where your provider supports issuing several keys, give each environment its own: revoking a development key at the provider then has no effect on production.

3. Issue one Salyro API key per gateway

   The key is displayed once, when it is issued, and cannot be recovered afterwards. Put it straight into that environment's configuration.

4. Point each environment at its own key

   Each deployment carries exactly one key, from exactly one gateway. The moment a single key is shared between two environments, everything below stops being true.

What the separation buys

Four things, all of which follow from the gateway owning its resources:

• Costs stay clean. Usage accumulates per gateway, so a production figure contains production traffic and nothing else. A load test in staging does not land on it.
• Rate limits stay separate. Limits are attached to a key, and a key belongs to one gateway, so a development process in a retry loop cannot consume production's allowance.
• Credentials stay out of reach. A development key reaches development's provider credentials. It cannot reach production's, because the two gateways share nothing.
• Logs stay legible. Requests and conversations are recorded against the gateway that served them, so debugging a staging problem does not mean filtering production traffic out first.

What it does not buy

Being explicit about the limits is what keeps the setup honest.

• No budgets and no spend caps. Separating environments makes development spend visible; it does not cap it. Budgets and quotas are not enforced in this version, so nothing stops a runaway development process on cost grounds. The rate limit on its key is the control that does apply.
• No routing behaviour. Gateways do not fail over to one another and do not balance load. Each one passes requests through to the provider named in the request.
• No retroactive split. Traffic recorded under one gateway stays recorded under it. Creating a second gateway later separates what happens next, not what already happened.

Where to go from here

Rotating the provider credentials you just connected is the next operational task worth rehearsing before you need it — see Rotate a provider credential without downtime.