Rylvo

Control Environments & Releases

Change anything.
Ship only what you mean to.

Every workspace has Test and Production. You build in Test. Production changes only when you release, and every release can be rolled back.

Two environments

Two copies of everything. One switch.

One switch on every dashboard page. Configuration, conversations, traces and keys all follow it, so test chats never show up in the numbers you report.

Test Production
ConfigurationEdit anythingRead-only — changes arrive in a release
ConversationsYour test chatsWhat customers actually said
Traces & analyticsTest traffic onlyProduction traffic only
API keysReach TestReach Production
ConnectorsBlocked unless verified for TestLive

A release

From a change in Test to customers, on purpose.

  1. 01 / 04

    Change it in Test.

    Edit prompts, guardrails, flows, knowledge and tools, by hand or with the Architect. Try each change in the Test chat on real models. Customers see none of it.
  2. 02 / 04

    See exactly what will change.

    Review & release lists every change against what Production runs today, grouped by bot, with agent teams kept together. Hold back anything that isn’t ready.
  3. 03 / 04

    Pass the rules you set.

    Turn on either rule, or both: every bot in the release must pass its tests, and a second admin must approve it.
  4. 04 / 04

    Activate, or roll back.

    Production switches to the release in one step. A release never changes once frozen, so going back to any earlier one is one click.

What a release carries

A complete copy of what Production runs.

A release isn’t a list of edits. It is everything Production should run, frozen. So a held-back change keeps its live version, and a rollback lands exactly where you were.

  1. 01Bots

    Each bot with its collection fields, state settings and code steps.

    bots
  2. 02Prompts

    The exact prompt versions the bots use.

    prompts
  3. 03Flows & teams

    Guided flows, and agent teams with their routing.

    flows
  4. 04Skills & guardrails

    With the versions you tested.

    guardrails
  5. 05Connectors & MCP

    Connector definitions, MCP servers and their discovered tools. Never their secrets.

    connectors
  6. 06Knowledge

    Sources, blueprints and connections. Indexed text is never copied.

    kbSources
  7. 07Automations

    Scheduled tasks, notification channels and report setups.

    scheduledTasks

Held back means kept

Hold back a change and Production keeps exactly what it has: the live version stays, a new item isn’t introduced, a deletion isn’t applied.

Test can’t reach out

Connectors stay blocked in Test until an admin verifies them for Test. A test chat can’t email a real customer or charge a card.

Who can release

Your whole team can open Test. Only admins and owners can release or roll back, and every release records who made it.

The same split over the API

Each API key belongs to the environment it was made in. Your CI uses a Test key. Your site uses a Production key.

Questions

Asked often.

Is Production ever edited directly?
No. Production is read-only for everyone, the Architect included. It changes only when you activate a release or roll back to an earlier one, so every change to what customers see is deliberate and recorded with who made it.
What is in a release?
A frozen, complete copy of what Production should run: bots with their collection and state settings, prompts, flows, agent teams, skills, guardrails, connectors, knowledge sources, MCP servers and automations. Secret values, conversations and indexed knowledge are never part of it. Once frozen, a release never changes, which is what makes rolling back safe.
Can I ship some changes and keep others in Test?
Yes. Hold back any change and Production keeps exactly what it has for it: a changed item stays at its live version, a new one is not introduced, and a deletion is not applied. Agent teams are grouped, so you can release a whole team together.
How do I roll back a bad release?
Open History and pick any release that was live before. Production points at it again straight away. Nothing is rebuilt or redeployed.
Can I require tests or a second person before a release goes live?
Yes. An admin can hold every release until each bot in it passes its tests on a run against that exact release, and can require two-person approval, where a second admin approves and the person who made the release cannot. Custom pass criteria for the test gate are part of Enterprise.
How do environments work over the API?
Use an API key made in that environment: a Test key reaches Test, a Production key reaches Production, and no header switches it. The same bot answers from that environment's configuration and writes to that environment's data. When Test calls your own systems, Rylvo marks the request with a signed X-Rylvo-Environment: test header, so you can tell it apart.

Break things in Test.
Never in front of customers.