> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Environments
> Deploy safely with staging and production environments
Runflow gives every tenant two environments: **staging** and **production**. You edit, deploy, and test in staging, then publish to production when you're ready. This keeps real users insulated from work-in-progress changes.
## How It Works
* **Staging** is where all edits happen: agent deploys, draft prompts, connector changes, and new triggers.
* **Production** is read-only in the dashboard. It only changes when you explicitly publish something from staging.
* Each environment has its own endpoint URL, executions, sessions, traces, and memory namespace — they never mix.
There's nothing to set up. Every agent, connector, prompt, and trigger you
create is already environment-aware.
## CLI Workflow
### Deploy to Staging
`rf agents deploy` always targets **staging**:
```bash theme={null}
cd my-agent/
rf agents deploy
```
This pushes your local changes and makes the new version live at the staging endpoint. Production is not affected.
### Promote to Production
When staging looks good, promote it to production:
```bash theme={null}
rf agents promote
```
You'll get an interactive confirmation. After it runs, the production endpoint serves the same code that was in staging.
`rf agents promote` only promotes the **agent code**. Prompts, connectors, and
triggers are published separately from the dashboard — see the Platform
section below.
### Local Testing with `rf test`
`rf test` runs your agent locally **in staging mode**:
```bash theme={null}
cd my-agent/
rf test
```
That means, while testing locally:
* Prompts resolve to their **draft** (staging) versions
* Connectors resolve to their **staging** instances and resources
* Memory is written under a `staging:` namespace
* Traces are tagged as staging
Because `rf test` is hardwired to staging, your local iterations never touch
production state. You can run freely without worrying about polluting real
user data.
## Platform (Dashboard) Workflow
### Environment Switcher
The dashboard header shows the current environment with a colored badge: **amber for Staging**, **emerald for Production**. Click it to switch.
* In **Staging**, every screen is editable.
* In **Production**, every screen is read-only. A banner on each screen explains how to switch back to staging to make changes.
### Publishing Changes to Production
When you're ready to promote changes, open the **Releases** screen. It lists everything that's different between staging and production:
* **Agents** with unpromoted staging code (with commit history and file diffs)
* **Prompts** with draft versions (side-by-side diff of the prompt text)
* **Connectors** with added, removed, or modified resources
You can publish items one at a time or publish everything in one action.
Review the diffs carefully before publishing — production changes take effect
immediately for all users.
## What Is Separated by Environment
| Entity | Per-environment? | Notes |
| ----------------------- | :--------------: | --------------------------------------------------------------------------------------------- |
| **Agents** | Yes | Separate code and endpoint URL per environment. Agent metadata (name, description) is shared. |
| **Connector instances** | Yes | Same connector slug can exist in both environments with different configs and resources. |
| **Triggers** | Yes | Each trigger targets one environment. Duplicate them if you need the same behavior in both. |
| **Prompts** | Yes | Draft versions are staging. Published versions are production. |
| **Executions** | Yes | Tagged at runtime. Filter by environment in the dashboard. |
| **Sessions / Threads** | Yes | Filtered by environment everywhere they're listed. |
| **Memory** | Yes | Staging uses its own `staging:` namespace. |
| **Traces** | Yes | Tagged with environment so you can filter observability data. |
| **Credentials** | No | Shared across both environments. Create once, use anywhere. |
| **Knowledge Base** | No | Vector stores are shared. The same KB serves staging and production agents. |
| **LLM Providers** | No | Shared. |
| **Data Sources** | No | Shared. |
## Best Practices
* **Iterate in staging first.** Use `rf test` for the local loop, then `rf agents deploy` to validate on the staging endpoint before promoting.
* **Publish related changes together.** If an agent deploy depends on a new prompt version, review them both on the Releases screen and publish them in the same batch.
* **Handle shared credentials carefully.** Because credentials are shared across environments, rotating or changing one affects production immediately. Plan credential changes during low-traffic windows.
* **Don't rely on production memory for testing.** Since memory is namespaced per environment, staging agents start with a clean slate.
## FAQ
### Why didn't my prompt change show up in production?
Prompt changes are published separately from agent deploys. Open the Releases screen — your prompt is likely a draft waiting to be published.
### Do triggers fire in both environments?
No. Each trigger is bound to one environment. Create a separate trigger per environment if you want the same behavior on both.
### Can a staging run talk to the same external APIs as production?
Yes. Credentials, knowledge bases, and data sources are shared, so staging agents hit the same external services and KBs as production. Only agent state (memory, sessions, executions, traces) is isolated.
### What environment does `rf test` use?
Staging, always. This is intentional — it keeps local testing from leaking into real user data.
## Next Steps
Deploy and promote agents from the CLI
Inspect traces and executions per environment
Configure per-environment integrations
Manage prompt drafts and versions