Sandboxes

Sandboxes let you create disposable environments for testing, authoring, and validating changes before you apply them more broadly. Use the Sandboxes page to create templates, launch sandbox instances, monitor setup status, rebuild services, and remove environments you no longer need.

01When to use sandboxes

Use sandboxes when you want to work in an isolated environment without affecting other active work. Sandboxes are especially useful when you need to:

• Test changes from a linked GitHub repository before sharing them more broadly
• Create repeatable starting points with templates
• Open a running authoring environment for validation or review
• Run ad hoc tests against a sandbox environment instead of a live property URL
• Set a property-level default sandbox so one-click ad hoc tests start in the right environment
• Use an eligible sandbox template to support ad hoc testing in environments that can run a sandbox-backed planning phase before browser execution
• Troubleshoot setup issues without changing an existing environment
• Rebuild app services after repository or configuration changes
• Validate external integration flows that depend on third-party login or API behavior, including Google OAuth and Jira

02Core concepts

Sandboxes are organized around reusable templates and the sandbox instances created from them. Before you create or manage either one, make sure your property has the right GitHub connection and repository access.

Templates

A sandbox template is a reusable configuration for creating sandbox instances. Templates help you standardize the repository, branch, and other setup details so you can launch new environments more quickly.

Templates also include an Instance size setting. Use this setting during template creation to choose how much compute capacity new sandbox instances created from the template receive.

The selected instance size applies when Canary provisions a new sandbox from the template. If you change the template's instance size later, the change affects future provisions and rebuilds that re-provision from the template rather than hot-updating already running sandbox instances.

Use the Templates tab to browse existing templates, create new ones from connected GitHub repositories, and review template details before creating or updating sandbox instances.

Sandbox instances

A sandbox instance is a running or previously provisioned environment created from a template. Each instance has its own setup lifecycle, status, access mode, and management actions.

From the sandbox list, you can review each instance's current state, see whether it is public or private, open the running environment when available, rebuild app services, run agent tasks, or delete the sandbox and any running instance when you are done.

Sandbox instances also support broader service emulation for external integrations. Use this support to test flows that depend on third-party authentication and API responses in isolation, including Google OAuth sign-in flows and Jira-connected behavior.

You can also execute agent tasks directly on a sandbox instance. Use this when you want to hand coding work to an AI agent, keep the work tied to the sandbox environment, and review results from the same task flow.

Sandbox instances can also serve as ad hoc test targets. Set a sandbox as the property's default ad hoc target for faster one-click launches, or choose a different sandbox when you start an individual test.

Sandbox instances also appear as ephemeral environments on your property's environment pages. Use those entries to find temporary sandbox URLs alongside your permanent, local, and VPC-backed environments.

GitHub connection requirements

Sandbox template creation depends on your property's GitHub integration. You can only create templates from repositories that are available through the connected GitHub account or organization and linked to the property.

If GitHub is not connected, or if no repository is linked to the property, sandbox creation options are limited until you complete that setup.

03Create a sandbox

Create a sandbox by choosing the correct property context, selecting linked repositories, and starting from a template that matches the work you want to test.

Prerequisites

Before you create a sandbox, confirm that:

• Your property has access to Sandboxes
• GitHub is connected for the property
• At least one repository is linked and available for selection
• You know which branch or default repository branch you want to use
• You know whether the sandbox should be public or private

If you need to connect a repository first, complete that setup before returning to Sandboxes.

Choosing a property and linked repository

1. Open Sandboxes.
2. Verify that you are in the correct property.
3. Go to the Templates tab if you need to create a new starting point.
4. Select the linked repository you want to use for the primary app or service.
5. Add any other linked repositories that belong in the same sandbox environment.
6. Continue with template creation or launch a sandbox instance from an existing template.

The available repository choices come from your property's GitHub connection, so only linked repositories appear during setup.

Use multiple linked repositories when your release validation depends on changes across services, packages, or apps that ship together. This helps you create a more realistic release QA environment in one sandbox instead of validating each repository in isolation.

Default branch and naming behavior

When you select a repository, the sandbox flow uses that repository's default branch as the starting branch unless you choose a different supported branch during setup. This helps you create templates more quickly with sensible defaults.

For multi-repo templates, review the selected branch for each linked repository before you save. Keep branch names aligned with the release or QA scenario you want to validate so the sandbox reflects the full set of changes under test.

Use clear, unique names for templates and sandbox instances so you can identify the correct environment in the sandbox list. If a name is already in use, update it before continuing.

Choose sandbox access during launch

When you launch a sandbox instance, choose the access mode that matches how you want to use the environment.

Access mode	Description
Public	Exposes the sandbox to the public internet and shows an openable environment link when the instance is ready
Private	Keeps the sandbox off the public internet and shows private access details instead of a public link

Use Private when you need an isolated instance that is not reachable from the public internet. Use Public when you need a shareable browser-accessible environment.

After launch, the sandbox list and instance details continue to show whether the sandbox is public or private so you can confirm the access mode at a glance.

04Manage sandbox templates

Use the Templates tab to centralize template creation and maintenance. This view makes it easier to see what templates are available and act on them without leaving the main sandbox workflow.

Browse templates from the Templates tab

Open Sandboxes and select the Templates tab to review reusable starting points for new sandbox instances. Use this view to compare template names, repositories, and available actions before launching a new environment.

Templates now surface their current state more clearly so you can tell whether a template is still preparing, ready to use, or needs attention before you launch from it. Use the state shown in the list as your first check before you verify a template, push updates, or create a new sandbox instance.

Templates can also represent multi-repo environments. Use the template list and details to confirm which linked repositories are included before you launch a sandbox for release QA or broader environment validation.

Templates also appear when you launch an ad hoc test that targets a sandbox. Use the template name and related sandbox details in the test launch flow to confirm that you are choosing the correct environment before you start the run.

Eligible sandbox templates can also support downstream ad hoc testing workflows in supported environments. When sandbox-backed planning is available, Canary can target the selected sandbox during a pre-execution planning phase before browser execution begins.

Create templates from connected GitHub repositories

1. Open Sandboxes.
2. Click Templates.
3. Start a new template.
4. Select a connected GitHub repository from the list.
5. Add any additional linked repositories that should be part of the same sandbox environment.
6. Confirm the default branch for each repository or choose another available branch if needed.
7. Choose the Instance size that matches the capacity you want new sandbox instances from this template to use.
8. Enter a unique template name.
9. Save the template.

The creation flow is guided by your existing GitHub connection, which reduces setup errors and helps you start from repositories your property already trusts.

Use Instance size to control the compute capacity available to sandbox instances created from the template. Choose a larger size when your app needs more resources for builds, startup, or runtime behavior.

The selected size takes effect when Canary provisions a sandbox from the template. It does not resize a sandbox that is already running.

Use multi-repo templates when your application spans separate frontend, backend, worker, or shared library repositories. This keeps the sandbox closer to the environment you need for release validation and reduces manual setup across separate sandboxes.

View template details and configuration

Open a template to review its repository, branch, and current configuration details. Use this view to confirm that the template still points to the correct source and to check whether it is the right starting point for a new sandbox instance.

For multi-repo templates, review every linked repository and branch together before launch. Use this view to confirm that the full application environment matches the release candidate you want to validate.

Template details also help you verify what will be applied when you create a sandbox from that template. If the template is still preparing, wait for it to reach a ready state before you verify it or use it to create a new sandbox instance.

Templates now include an Instance size setting on the detail page. Update this setting when future sandbox provisions need more or less capacity than the template currently uses.

When you change Instance size from the template detail page, Canary uses the new size for future provisions from that template. The change does not hot-update sandbox instances that are already running.

Templates now include built-in service emulation settings and clearer configuration visibility. Use the template details page to review which emulated services are enabled, inspect default environment values, and identify fields that are treated as sensitive or auto-generated.

Supported ad hoc testing flows can also use eligible templates as the basis for sandbox-backed planning. Review template details before you launch the test so you know the planning phase can research the app, prepare data, and build a more structured plan in the selected sandbox environment.

Template details now include dedicated Actions and Artifacts tabs. Use Actions to review the actions available for a template, including descriptions, parameters, required inputs, and timeouts before you create a sandbox from it.

Use Artifacts to inspect template files in more detail. Expand files, review syntax-highlighted content, and copy files such as Docker Compose definitions, Dockerfiles, and scripts directly from the page.

Push template updates into running environments

When you update a template, the platform can push updated files and configuration into running authoring environments created from that template. Use this when you want active environments to pick up template changes without creating a new instance from scratch.

This is especially useful when you need running environments to reflect changes that affect external integration testing. After a template update, you can validate the latest Google OAuth and Jira-related flows inside the existing sandbox instead of rebuilding your setup from the beginning.

For multi-repo templates, use template updates to keep linked repositories in sync with the release state you are validating. Review the impacted repositories before you push changes so the running sandbox stays aligned with your QA plan.

Before you apply template updates, confirm that the running environment is the right target and that anyone using it is ready for the change.

Template-driven updates

When you push template updates into existing sandbox instances, expect the instance to re-enter setup while the updated files and configuration are applied. The sandbox can move back through visible setup states before it becomes ready again.

Use the state shown on the template and sandbox instance as your primary signal after an update. Wait for the template to finish preparing and for the sandbox to return to Ready before you reopen it, rerun validation, or share the environment with someone else.

If the template itself is not yet ready for verification, the update flow now shows clearer feedback instead of leaving you to infer what happened. Follow the prompt shown in the app, wait for the template to finish preparing, and then retry the verification or update action.

If you changed the template's Instance size, treat that change as a template update for future provisions. Running sandbox instances keep their current size until you provision a new sandbox from the template or otherwise reprovision the environment.

05Manage sandbox instances

Use the sandbox list to monitor active and past environments and take action directly from each entry.

Sandbox list status details

The sandbox list surfaces more operational detail so you can quickly understand each environment's state. Depending on the sandbox, you may see details such as:

Detail	Description
Status	Current lifecycle state, such as provisioning, deploying, ready, or failed
Readiness	Whether the sandbox is still preparing or is ready to open and use
Access	Whether the sandbox is public or private
Verification status	Whether the environment has passed its verification step
Configuration variables	The number of configuration variables associated with the sandbox
Repository	The linked repository used for the sandbox or template
Branch	The branch associated with the current setup
Open environment link	A direct way to open the running authoring environment when available for public sandboxes
Private label	A clear label that replaces the public link when an instance is private

Use these details to decide whether to wait, investigate, rebuild, open, or delete the sandbox.

For multi-repo environments, use the list and instance details to confirm that the sandbox came from the correct template before you start release validation. This is especially helpful when you maintain separate templates for single-repo debugging and multi-repo release QA.

Sandbox-backed environments also appear in the property environments table as ephemeral environments. Use that table to discover temporary sandbox URLs, check expiry details, and distinguish them from permanent, local, and VPC-backed environments.

Expired ephemeral environments are now hidden automatically after 24 hours. If an older sandbox-backed entry no longer appears in property environment selectors or lists, open Sandboxes to confirm whether the sandbox still exists or launch a new sandbox if you still need an environment target.

The property environment views now show these sandbox-backed entries more cleanly, making it easier to scan temporary environments and spot the current state without leaving the broader environment list.

Open running environments

When a public sandbox is ready, use the direct environment link in the list to open the running authoring environment. This is the fastest way to validate that the environment is available and inspect the current state after setup or updates.

If your workflow depends on external services, use the running environment to test emulated third-party behavior before moving changes into a shared environment. Sandboxes now support more of these flows, including Google OAuth and Jira scenarios.

Multi-repo sandboxes are especially useful for release validation when the user flow depends on multiple services working together. Open the environment after setup to validate the full application experience instead of checking each repository separately.

If no open link appears yet, check the sandbox readiness first and wait for it to reach Ready before trying again.

For public sandboxes, readiness validation now checks the public app URL before Canary marks the environment ready. Use the public link shown in the list or instance page as your primary confirmation that the sandbox is actually openable in the browser.

For private sandboxes, the list and detail views show private labeling and access information instead of a public link. Use those details to confirm that the sandbox is intentionally private before you continue debugging or validation work.

Rebuild app services after changes

Use Rebuild when you need the sandbox to pick up changes after repository updates, configuration changes, or template updates. Rebuilding app services is useful when the environment exists but needs to refresh its runtime state.

In a multi-repo sandbox, use Rebuild after you update one or more linked repositories and want to confirm that the combined environment still behaves correctly. This helps you rerun release QA in the same sandbox without creating a brand-new environment every time.

Start a rebuild from the sandbox's available actions, then monitor the status until the environment returns to a ready state.

Avoid repeating Rebuild or other control actions in rapid succession. Canary now throttles repeated sandbox mutation actions more safely, so back-to-back retries may be delayed or rejected while the current operation is still being processed.

If you do not see an immediate change after starting a rebuild, wait for the visible status to update before retrying the action.

Run sandbox actions from an instance page

Open a sandbox instance to access sandbox-specific actions directly from the instance page. Use these actions to run common setup, diagnostic, or maintenance tasks without leaving the app.

When an instance exposes actions, select the action you want to run, complete the guided input form, and confirm the run. The instance page also shows recent execution history so you can review what ran most recently and whether it completed successfully.

Use instance actions when you want a repeatable way to trigger sandbox tasks after provisioning, especially for setup and troubleshooting steps that other team members may also need to run.

Execute agent tasks on a sandbox instance

Open a sandbox instance when you want to send coding work directly to an AI agent in that sandbox environment. Use this flow when you want the task, the environment, and the results to stay connected in one place.

1. Open Sandboxes.
2. Select the sandbox instance you want to use.
3. Open the tab that matches what the sandbox supports:
   • Use Chat when the sandbox has a chat-capable agent.
   • Use Authoring when the sandbox has an authoring-capable agent.
4. Enter your prompt or instructions, or follow the guidance shown if that capability is unavailable.
5. Confirm the task and monitor its progress from the same task flow.

Sandbox pages now match the available agent type more closely. If a sandbox does not support chat or authoring, the tab stays visible but explains why that capability is unavailable instead of showing controls that will not work.

Use agent tasks on sandbox instances when you want to investigate failures, apply code changes, or test fixes without switching to a separate environment first.

Sandbox capabilities and tabs

Sandbox instance pages show tabs based on the capabilities available in that environment. Use the page guidance to understand what you can do in the current sandbox before you start work.

Tab or capability	What you see
Chat available	Start chat-based agent work directly from the sandbox page
Authoring available	Open authoring workflows for coding and file changes in the sandbox
Chat unavailable	See guidance that the sandbox does not support chat in its current configuration
Authoring unavailable	See guidance that the sandbox does not support authoring in its current configuration

Use these capability messages as your first check when a sandbox page does not show the controls you expected. If you need a different workflow, launch or select a sandbox that includes the agent type required for that task.

Sandbox access details on the instance page

Open a sandbox instance to review its current access details. Public sandboxes show the expected environment link, while private sandboxes show private-access labeling and connection details instead of a public URL.

The sandbox detail page now also includes in-product documentation links. Use these links when you want quick access to related reference material while you review the sandbox, run actions, or troubleshoot setup issues.

Use the instance page to verify the current access mode before you share the environment, troubleshoot a connectivity issue, or decide whether a missing link is expected. For private sandboxes, review the displayed private access information, including private IP details when available.

Connect from local CLI

Use the local CLI when you want richer agent workflows, direct debugging, or a local editor connection to the sandbox environment. The sandbox page now includes a dedicated Connect drawer that guides you through this setup.

Open a sandbox instance, click Connect, and follow the CLI instructions shown in the drawer. Use this flow when chat or authoring is unavailable in the current sandbox, or when you want to work locally against the sandbox environment.

The drawer centralizes connection steps so you do not need to leave the sandbox page to get started.

Manage repository connections

Sandbox templates depend on repository links at the property level. Use property repository connections to decide which repositories are available when you create or update a sandbox template.

For multi-repo release QA, link every repository that needs to be part of the same validation environment before you create the template. If one service or package is missing, the sandbox setup cannot reflect the full release candidate.

Use repository connections to support these workflows:

• Keep a single property ready for realistic multi-repo application environments
• Launch release QA sandboxes that include frontend, backend, worker, or shared library repositories together
• Reuse the same linked repositories across templates for different release branches or validation scenarios
• Reduce manual setup when you need to compare single-repo and multi-repo sandbox coverage

If a repository does not appear during template creation, confirm that GitHub is connected and that the repository is linked to the property. Then return to Sandboxes and restart the template flow.

To manage repository links, go to /docs/reference/properties and /docs/integrations/github.

Manage sandbox actions from the CLI

Use the Canary CLI when you want to manage template actions without opening the app. You can list, view, create, and delete actions for a sandbox template from the command line.

Use CLI action management when you want to keep template actions in sync as you iterate on your sandbox setup. This is especially useful when you are updating templates, scripts, or action inputs as part of a local authoring workflow.

Sandbox CLI operations now return clearer user-facing errors when input is invalid, an action is disabled, an instance cannot be found, or an operation times out. Use these messages to correct the command or confirm that the target sandbox and action are available before retrying.

Use the CLI to inspect and debug sandbox instances

Use the Canary CLI when you need to inspect sandbox instances from the command line or run commands inside a specific service.

Use sandbox listings to confirm instance status and access mode. Private sandboxes are identified in CLI output so you can distinguish them from public instances without opening the app.

When you need container-level debugging, run commands against a specific sandbox service with --service. Use this option to target the service you want to inspect instead of running against the default container context.

Delete sandboxes and running instances

Delete a sandbox when you no longer need the environment or want to remove a failed or outdated setup. This action is destructive and may also remove the running instance associated with that sandbox.

Before you delete a sandbox:

• Confirm that nobody still needs the running environment
• Verify that any important changes are stored in the linked repository or elsewhere
• Double-check that you selected the correct sandbox

06Setup states and troubleshooting

Sandbox setup moves through several visible states. Use those states to decide whether to wait, rebuild, or investigate a connection issue.

Note: New sandbox instances now run their initial build during provisioning. Expect a newly created sandbox to stay in Provisioning until that first build finishes.

Provisioning, deploying, ready, and failed states

Use the sandbox status to understand what the platform is doing:

State	What it means
Provisioning	The platform is creating the sandbox resources and running the initial build so the instance is more ready to use when setup completes
Deploying	The sandbox is applying code, configuration, setup scripts, or services after provisioning work finishes
Ready	The environment is available and can be opened, or private access details are available for a private sandbox
Failed	Setup did not complete successfully

Readiness is now surfaced more clearly across templates, sandbox instances, and property environment views. Check readiness before you verify a template, open a sandbox, or retry an update so you do not act on an environment that is still preparing.

For public sandboxes, readiness checks now validate the public app URL before the sandbox is marked ready. If the sandbox still shows Provisioning or Deploying, wait for that check to finish instead of assuming the environment is ready because earlier setup work completed.

If a sandbox remains in a transitional state longer than expected, refresh the page and review the repository, branch, template details, and access mode before trying again.

Configuration defaults, sensitive fields, and generated values

Sandbox configuration now gives you clearer control over what values apply by default and which fields need extra care.

Use template and instance configuration views to:

• Edit default environment values before launch
• Review sensitive fields without exposing their stored values unnecessarily
• Identify auto-generated configuration more easily so you know what the platform populated for you

Review these values before provisioning a new sandbox or rebuilding an existing one. This helps you catch missing defaults and confirm that generated values match the environment you expect.

Setup artifacts and provisioning visibility

Sandbox setup now supports a setup-script artifact type for setup steps such as dependency installation or build preparation. Use this artifact type when your sandbox needs pre-run setup that is separate from the main application startup.

Artifact uploads are also more flexible in the CLI. Use template-level artifacts for files that belong to the reusable template, and use custom file artifacts with explicit destination paths when you need more control over where files land in the sandbox.

Provisioning visibility is also clearer during setup. If a sandbox takes longer than expected, use the visible status updates to determine whether the environment is still preparing, applying setup work, or needs attention.

Long-running builds in the CLI

If a sandbox build runs longer than the gateway timeout, keep the CLI command running. The CLI now continues by polling diagnostics and reporting progress instead of failing immediately.

Use this behavior for larger projects that take longer to build or provision. If a build still does not complete, review the reported diagnostics and then decide whether to rebuild or adjust your template artifacts.

Troubleshoot sandbox action and CLI errors

Sandbox actions and sandbox CLI operations now return clearer, more consistent user-facing errors. Use the message text to identify the problem quickly and decide what to fix before retrying.

Error type	What to check
Invalid input	Review required fields, parameter values, and command arguments, then submit the action again
Disabled action	Confirm that the action is enabled for the template or instance you selected
Missing instance	Verify that the sandbox instance still exists and that you selected the correct property and sandbox
Timeout	Wait for the environment to finish its current work, then retry if the action is still needed
Throttled action	Wait for the current rebuild, delete, or other control action to finish before you retry repeated requests

If an action fails from the app, reopen the instance page and confirm that the sandbox is still in a usable state. If a CLI command fails, review the error text, correct the input or target, and then rerun the command.

If you trigger the same control action multiple times in a short period, expect Canary to throttle the extra requests. Use the sandbox status and recent action history as your guide instead of repeatedly clicking the same action.

Troubleshoot public and private access expectations

If you expect to open a sandbox in the browser, first confirm whether the instance was launched as Public or Private.

Use these checks to troubleshoot access issues:

• If the sandbox is Public, wait for the instance to reach Ready, then use the environment link from the list or instance page
• If the sandbox is Private, expect private labeling and access details instead of a public URL
• If a public link is missing, refresh the page and confirm that the sandbox did not launch in private mode
• If you are using the CLI, review the listed access mode before assuming the sandbox should be browser-accessible

Use the access mode as your first troubleshooting step when a sandbox appears ready but does not show the link or access path you expected.

Verification flow and template readiness

Sandbox verification is now simpler and provides clearer feedback when a template is not yet ready.

Use this flow when you verify a sandbox or template-driven update:

1. Start the verification action from the sandbox or template flow.
2. Watch the visible status and feedback in the app.
3. If the template is still preparing, wait for it to finish instead of retrying immediately.
4. Retry verification after the app shows that the template is ready.
5. Continue only after the sandbox returns to Ready or the verification step succeeds.

Use the readiness state shown in the app as your primary signal. If verification does not start because the template is not ready, wait for preparation to complete rather than rebuilding the sandbox right away.

Diagnostics and health

Use sandbox diagnostics to understand whether the sandbox is ready for work or needs attention. Diagnostics now report agent health and app health more accurately, so use them as your primary source when a sandbox seems available but something is still failing.

Review diagnostics from the sandbox detail page before you rebuild or rerun setup. Check whether the agent is healthy, whether the app is healthy, and whether either status points to the next troubleshooting step.

For public sandboxes, app health now reflects checks against the public app URL. Use this signal when you need to confirm that the browser-accessible environment is actually responding before you share the link or start validation.

Use these health signals to guide your next action:

Health signal	What it tells you	What to do next
Agent healthy	The sandbox agent is available for agent tasks and managed operations	Continue with agent tasks, actions, or deeper app checks
Agent unhealthy	The sandbox agent is not ready or cannot respond reliably	Wait for setup to finish, refresh the page, or rebuild if the state does not recover
App healthy	The sandbox app is running and responding as expected at its expected access URL	Open the environment or continue validation
App unhealthy	The sandbox app is not fully ready or is failing health checks at its expected access URL	Review recent changes, confirm the sandbox access mode, rerun setup steps if needed, or rebuild app services

If agent health and app health do not match, use the failing signal to narrow the issue. For example, if the agent is healthy but the app is unhealthy, focus on application startup, configuration, public access readiness, or recent template changes rather than agent availability.

Environment lifecycle in property environment lists

Sandbox-backed environments appear in property environment lists as ephemeral environments, but those entries are temporary.

Canary now hides expired ephemeral environments automatically after 24 hours. Use this cleanup behavior to keep selectors and environment tables focused on active targets instead of older sandbox-backed entries.

If you do not see an older ephemeral environment in a property selector or list, use these checks:

• Open Sandboxes and confirm that the sandbox instance still exists
• Check whether the environment was ephemeral and is now more than 24 hours old
• Launch a new sandbox if you still need a selectable environment target
• Use current sandbox entries in property environment views for ad hoc testing and other environment-based flows

Use this behavior as expected lifecycle cleanup, not as a signal that your property configuration is broken.

Permissions and visible infrastructure details

Sandbox pages now show infrastructure details more selectively based on your access level. Use the visible labels and connection guidance on the page instead of expecting full infrastructure metadata in every sandbox.

Regular users no longer see sensitive infrastructure details that are not required for everyday sandbox work. If you need to open, test, connect, or troubleshoot a sandbox, use the access mode, readiness state, Connect drawer, and available instance actions shown on the page.

If you are looking for infrastructure-specific values and they are not visible, treat that as expected behavior for restricted access rather than as a setup issue.

What to do if GitHub is not connected

If GitHub is not connected for the property, connect it before creating or updating sandbox templates. Without that connection, the platform cannot show eligible repositories for template creation.

After you connect GitHub, return to Sandboxes and re-open the Templates tab to continue.

What to do if no repository is linked

If GitHub is connected but no repository is linked to the property, link a repository that you want to use for sandbox setup. Until a repository is linked, template creation cannot proceed.

For multi-repo setups, repeat this step for every repository you want to include in the same sandbox environment.

After you link the repository, return to Sandboxes, confirm that the repository appears in the selection list, and restart the template creation flow.

07Best practices

• Create templates for repeatable test setups that multiple people may need
• Use clear naming conventions that identify the property, repository, and purpose
• Start from the repository's default branch unless you intentionally need another branch
• Choose an Instance size that matches your app's build and runtime needs, especially for larger or multi-service environments
• Resize the template from the template detail page when future sandbox provisions need different capacity
• Remember that Instance size changes apply to future provisions and do not hot-update already running sandboxes
• Choose Private for internal-only debugging and Public when you need a browser-accessible environment
• Check the sandbox's available Chat and Authoring capabilities before you start agent work
• Use the Connect drawer when you want to work through the local CLI or when in-app capabilities are unavailable
• Review template Actions before creating a sandbox so you understand required inputs and expected timeouts
• Keep reusable files at the template level and use explicit artifact paths when you need custom file placement
• Review status details and access mode before rebuilding or deleting a sandbox
• Push template updates carefully when an authoring environment is already running
• Use service emulation in sandboxes to validate external integration flows before broader testing
• Use multi-repo templates for release QA when changes span multiple linked repositories
• Link all required repositories before you create a template for a full application environment
• Use --service in the CLI when you need to debug a specific sandbox service
• Delete unused sandboxes to keep the list focused on active work

08Related

• /docs/reference/properties
• /docs/reference/tests
• /docs/reference/releases
• /docs/reference/workflows
• /docs/reference/tasks
• /docs/reference/environments
• /docs/integrations/github

Sandbox-backed ad hoc testing is also covered in /docs/reference/tests. Use that guide when you want details about test launch behavior, supported execution flows, and how sandbox targeting affects a run.