# Environments and Sandbox ## What this is Hookshot™ supports linking two workspaces together as a production and sandbox pair. The sandbox is a dedicated workspace where you can build and test Protege configurations before promoting them to production. ## When to use it Use environments when you want to: * Test Protege configurations in an isolated workspace before deploying to production * Make changes to behavior prompts, tool access, or schedules without affecting live workflows * Promote tested configurations from sandbox to production with a single action ## What you need first * A production workspace that is already bootstrapped * Contact Protege AI support () to set up a sandbox workspace linked to your production workspace ## How environments work ### Production and sandbox pairing An environment link pairs exactly one production workspace with one sandbox workspace. Each workspace can only belong to one pair. | Property | Production | Sandbox | | ---------------- | ------------------------------------- | ------------------------------------------------------------------- | | Purpose | Live workflows and real data | Testing and staging configurations | | Proteges | Running and serving events | Copies promoted from production, or new configurations being tested | | Credentials | Live connections to external services | Can use separate or shared connections | | People and teams | Managed directly | Inherited from production (read-only) | ### Switching between environments When your workspace is part of an environment pair, the sidebar workspace picker shows both workspaces. The sandbox entry is labeled with **Sandbox** so you can distinguish it from production at a glance. Select the sandbox workspace to work on test configurations. Select the production workspace to manage live workflows. ## Protege promotion ### How promotion works Promotion copies a Protege's configuration from the sandbox to the linked production workspace. The following fields are promoted: * Name and description * Behavior prompt (system prompt) * Model selection * Tool access grants * Engine configuration * Schedule definitions ### What is not promoted The following are kept separate and are **not** overwritten during promotion: * Integration credentials and connections * Webhook secrets and provider resource IDs * Run history and feed history * Trigger event history This means promoting a sandbox Protege to production preserves the production Protege's live connections and run data. ### Drift detection If a production Protege is edited directly outside of promotion, it is marked as **drifted**. The next promotion will warn about the drift and overwrite the changed configuration fields. This helps you understand when manual changes to production may be lost. ## Sandbox workspace restrictions Because the sandbox inherits administration from its linked production workspace, the following restrictions apply: * **People**: You cannot invite new people to the sandbox. Membership is inherited from the production workspace's owners and admins. * **Teams**: You cannot create, rename, or delete teams in the sandbox. The default team and its membership mirror the production workspace. * **SE access**: SE access must be provisioned separately in each environment. Granting SE access in the production workspace does not grant it in the sandbox, and vice versa. See [Teams and People](/workspace-settings/teams-and-people.md) for more on sandbox restrictions for team and people management, and [Solutions Engineering Access](/workspace-settings/solutions-engineering-access.md) for SE access across environments. ## How to verify * The workspace picker shows both production and sandbox, with the sandbox clearly labeled * Promoting a sandbox Protege updates the production Protege's configuration without affecting its credentials or history * Changes made directly to a production Protege are flagged as drift on the next promotion ## Common failures * Editing a production Protege directly instead of making changes in the sandbox and promoting * Assuming SE access in one environment grants access to the other * Expecting promotion to copy credentials or connection state from sandbox to production * Forgetting that sandbox team and people changes are not allowed — they must be made in the production workspace ## Next step * [Solutions Engineering Access](/workspace-settings/solutions-engineering-access.md) * [Teams and People](/workspace-settings/teams-and-people.md) * [Workspace Settings](/workspace-settings.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://gitbook.tryprotege.com/workspace-settings/environments-and-sandbox.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.