Skip to main content
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: 
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: 
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: 
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

EntityPer-environment?Notes
AgentsYesSeparate code and endpoint URL per environment. Agent metadata (name, description) is shared.
Connector instancesYesSame connector slug can exist in both environments with different configs and resources.
TriggersYesEach trigger targets one environment. Duplicate them if you need the same behavior in both.
PromptsYesDraft versions are staging. Published versions are production.
ExecutionsYesTagged at runtime. Filter by environment in the dashboard.
Sessions / ThreadsYesFiltered by environment everywhere they’re listed.
MemoryYesStaging uses its own staging: namespace.
TracesYesTagged with environment so you can filter observability data.
CredentialsNoShared across both environments. Create once, use anywhere.
Knowledge BaseNoVector stores are shared. The same KB serves staging and production agents.
LLM ProvidersNoShared.
Data SourcesNoShared.

​
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

CLI Agents

Deploy and promote agents from the CLI

Observability

Inspect traces and executions per environment

Connectors

Configure per-environment integrations

Prompts

Manage prompt drafts and versions