Skip to main content
GoDizzy organizes your routing configuration around three environment types. Each type serves a distinct purpose in the lifecycle of a routing config, from personal experimentation through to live production traffic. The same agent URL structure works across all three — you switch environments in the dashboard, not in your agent code.

The three environment types

Development

Personal and private. Only you can see your development environment. Use it to build and iterate on routing rules without affecting teammates. Each team member gets their own development environment.

Staging

Shared with your team. One staging environment per organization. Use it for team review, integration testing, and QA before promoting configs to production.

Production

Live traffic. One production environment per organization. This is what your agent or client points at in the real world. Only promote configs here when they are validated in staging.
Your development environment is only visible to you. Teammates cannot see, edit, or access it — including other organization members. Staging and production environments are visible and editable by all organization members.
1

Build in your development environment

In the dashboard, navigate to Routes and select your personal development environment. Create a route collection with the subdomain and target endpoint you want to test. Add routing rules, configure mock responses, and experiment freely — nothing here affects your teammates.Your agent or local test client points at your development collection’s subdomain (for example, abc12345.godizzy.dev). Iterate until the config behaves the way you want.
2

Copy the collection to staging

When your config is ready for team review, copy it to the staging environment.
  1. Open your development route collection.
  2. Click Copy Collection.
  3. Select Staging as the target environment.
  4. Optionally rename the copied collection for clarity (for example, append -staging).
  5. Click Copy.
GoDizzy creates an independent duplicate of your collection — all rules, mock responses, and shaping configs — in the staging environment. Changes to the staging copy do not affect your development original, and vice versa.
3

Validate in staging

Point your agent or integration tests at the staging collection’s subdomain. Run your test suite against staging. Teammates can review the config, suggest changes, and test their own integrations against the same shared environment.If you need to make changes, edit the staging collection directly (or iterate in dev and copy again).
4

Copy the validated collection to production

Once staging is validated, copy the staging collection to production:
  1. Open the staging route collection.
  2. Click Copy Collection.
  3. Select Production as the target environment.
  4. Click Copy.
GoDizzy creates another independent copy in production. Your production collection is now live.
5

Point your agent at production

Update your agent’s tool URLs (or your GoDizzy collection subdomain in your agent config) to point at the production collection’s subdomain. GoDizzy routes live traffic through the production rules from this point forward.
Because GoDizzy gives each collection a stable subdomain, you can configure your agent once per environment and never change it again. To roll out a new routing config, copy a new collection to production — you do not need to update the agent.

When to use each environment

SituationUse this environment
Building a new mock rule for the first timeDevelopment
Trying a risky config change that might break thingsDevelopment
Sharing a config with a teammate for reviewStaging
Running integration tests before going liveStaging
Demo or QA with external stakeholdersStaging
Live agent traffic, production evalsProduction
Rollback a production rule to a prior versionProduction (use version history — no re-copy needed)

Copying a collection: what gets copied

When you copy a collection, GoDizzy duplicates:
  • The collection name and target endpoint
  • All routing rules, including the protected default rule
  • The current version of every mock response and proxy shaping config
Copying creates a snapshot of the collection at the moment you copy it. Subsequent changes to the source collection are not reflected in the copy. If you update your development collection after copying to staging, you need to copy again or edit the staging collection directly.
Each copied rule and mock response is a fully independent entity with its own version history going forward. Reverting in staging does not affect development, and reverting in production does not affect staging.

Managing multiple collections per environment

You can have more than one route collection in a single environment. This is useful if you manage several distinct APIs or agent tool groups under the same organization. Each collection gets its own subdomain and target endpoint, so they are fully isolated from each other. Your plan’s collection limit applies to production collections only. Development and staging collections do not count toward the limit.