Making changes directly within a live HubSpot portal is a high-risk activity. A minor mistake in a workflow, a broken module in a theme, or a misconfigured property can lead to significant business disruption. These errors can manifest as broken user experiences, corrupted CRM data, failed marketing campaigns, and ultimately, lost revenue. For any business that relies on HubSpot for critical operations, editing the production environment directly is an unacceptable gamble.
HubSpot Sandboxes are the solution to this problem. Available for all Enterprise-level Hubs, a sandbox is an isolated copy of your production portal's configuration and assets. It provides a safe, contained environment where your developers, marketers, and operations teams can build, test, and innovate without any risk to your live business operations. You can use sandboxes to develop new website features, test complex automation sequences, validate integrations, and even train new team members.
This guide provides a comprehensive overview of using HubSpot Sandboxes for safe and efficient development. We will cover the step-by-step process for creating a sandbox, explain how to sync assets to your production account, and detail best practices for managing your testing environments. We will also explore common use cases, clarify the important limitations of sandboxes, and differentiate between Standard and Developer sandboxes to ensure you use the right tool for the job.
What is a HubSpot Sandbox and Who Needs One?
A HubSpot Sandbox is best understood as a structural clone of your main HubSpot account, often called the 'production' account. When you create a sandbox, HubSpot copies most of your portal's settings, tools, and assets. This includes object definitions, properties, user roles, pipelines, themes, templates, and inactive workflows. It creates a functionally identical but entirely separate environment for development and testing. It is critical to understand that a sandbox is not a full data backup; it does not copy your records like contacts, companies, deals, tickets, or content assets like pages and blog posts.
This functionality is exclusive to customers on an Enterprise-level HubSpot subscription. If your organization uses Marketing Hub, Sales Hub, Service Hub, CMS Hub, or Operations Hub Enterprise, you have access to sandboxes. They are essential for any business with complex technical requirements or a team-based development process. If you have multiple developers working on your website, a marketing ops team building intricate automation, or a need to test critical integrations, a sandbox is a non-negotiable part of your toolkit.
The cost of not using a sandbox can be substantial. Imagine launching a new marketing campaign only to find the lead capture form is broken due to a recent theme update that wasn't tested. Consider a change to a deal automation workflow that inadvertently moves hundreds of active deals to the wrong stage, creating chaos for your sales team. These are not hypothetical scenarios; they are costly realities that a proper testing process prevents. Using a sandbox is a core principle of professional portal management and part of our standard HubSpot support and maintenance protocol.
How to Set Up Your First HubSpot Sandbox
Creating a HubSpot Sandbox is a straightforward process for account administrators. First, navigate to the settings gear icon in the top right of your HubSpot portal. In the left sidebar menu, go to Account Setup > Sandboxes. Here, you will see a list of your existing sandboxes and an option to create a new one. Click the 'Create sandbox' button to begin the provisioning process.
You will be prompted to name your sandbox. It is a best practice to use a clear, descriptive naming convention, such as 'Q3-Theme-Update' or 'New-Service-Pipeline-Test', to avoid confusion. Once you confirm the creation, HubSpot begins copying your production account's assets. This process can take anywhere from a few minutes to an hour, depending on the complexity of your portal. HubSpot will not copy records (contacts, deals) or content (pages, emails, blog posts), ensuring a clean environment for testing asset functionality.
User access is managed independently from your production account. When a sandbox is created, it inherits the current user list and their permissions. However, you can then add or remove users and modify their permissions within the sandbox without affecting the production account. This is useful for giving developers elevated permissions in the sandbox or for providing temporary access to contractors. You can access a sandbox directly via its unique URL or through the account dropdown menu in the top right of your HubSpot navigation.
Syncing Assets: From Sandbox to Production
The primary function of a sandbox is to build and test assets before moving them to the live environment. HubSpot facilitates this through the 'Sync to production' feature. This tool allows you to selectively push approved assets—such as a new custom module, a tested workflow, or a updated deal pipeline—from the sandbox directly into your production portal. This one-way sync is the bridge between your development and live environments.
To initiate a sync, navigate to the specific asset within your sandbox account. For example, if you have updated a set of custom properties, you would go to Settings > Properties. When you select the properties you wish to sync, an option for 'Sync to production' will become available. The interface provides a clear comparison, showing what is being added, updated, or what conflicts exist. You must carefully review this 'diff' view to confirm the changes are exactly as you expect before proceeding.
Following best practices for syncing is crucial for maintaining a stable production account. Always sync small, logical batches of work rather than a massive collection of unrelated changes. This makes it easier to track deployments and roll back if necessary. At HubStack, we implement a peer review process where a second developer must approve the sync list before it is pushed. Having a designated gatekeeper for the final 'sync' action prevents accidental or unapproved changes from impacting your business. This level of governance is key for any serious HubSpot theme customization project.
Common Use Cases for HubSpot Sandboxes
One of the most common use cases for a sandbox is website and theme development. Your development team can build new page templates, create complex custom modules, or even undertake a complete HubSpot website design and development project in total isolation. They can experiment with new frameworks and functionality without a single visitor to your live website being affected. Once the new theme or feature is complete and tested, it can be safely synced to production.
Marketing and operations teams derive immense value from testing automation in a sandbox. Building complex, multi-branch workflows for lead nurturing, data enrichment, or internal notifications carries significant risk. A sandbox allows you to create these workflows and test them with a handful of manually created test contacts. You can validate every trigger, delay, and action, ensuring the logic is flawless before activating it in production, where it might affect thousands of real contacts.
Testing integrations is another critical use case. Whether you are connecting a new third-party application via the API or configuring a data sync with another business system, doing so in a sandbox is essential. It prevents potential data corruption, sync errors, and API rate limit issues in your live environment. This is especially important when setting up foundational systems, which is a core part of our HubSpot CRM setup and automation service.
| HubSpot Hub | Primary Sandbox Use Case | Example Asset to Test |
|---|---|---|
| CMS Hub Enterprise | Theme development and page template testing | New global modules, website themes, HubDB tables |
| Marketing Hub Enterprise | Complex lead nurturing workflow testing | Workflows, custom properties, lead scoring rules |
| Sales Hub Enterprise | Custom deal pipeline and automation setup | Deal pipelines, forecasting settings, quote templates |
| Service Hub Enterprise | Help desk and ticket automation configuration | Ticket pipelines, knowledge base templates, feedback surveys |
| Operations Hub Enterprise | Data sync and custom property mapping tests | Custom code actions in workflows, data quality rules |
Limitations and What Sandboxes Are NOT
It is vital to understand that HubSpot Sandboxes are not a backup or data restoration solution. They do not copy your CRM records (contacts, companies, deals) or your marketing content (emails, pages, blog posts). If you accidentally delete a list of contacts from your production portal, you cannot restore them from a sandbox. The sandbox's purpose is to test the structure and assets of your portal, not to store a snapshot of your data.
Sandboxes are also not suitable for performance testing. You cannot use a sandbox to reliably measure website speed, Core Web Vitals, or how a database will perform under heavy load. The underlying infrastructure of a sandbox environment is different from a production portal and does not have real-world traffic patterns. Proper performance measurement requires dedicated tools and a production environment audit, often as part of a HubSpot technical SEO engagement.
Finally, there are limitations on the types of assets and tools available in a sandbox. Certain account-wide settings, specific beta features, and some content types like marketing emails cannot be created in or synced from a sandbox. For example, you can sync a workflow but not the specific email content used within it. HubSpot's list of syncable assets is constantly evolving, so it's always wise to consult their official documentation before beginning a large project.
Best Practices for Sandbox Management
Effective sandbox management requires clear processes and documentation. Institute a strict naming convention for new sandboxes that includes the date, project name, and owner's initials (e.g., '20260916_NewTheme_JD'). Maintain a central document or spreadsheet that lists all active sandboxes, their purpose, key users, and their expected retirement date. This prevents sandbox sprawl, where old, unused environments create confusion and clutter.
Over time, a sandbox can become significantly out of sync with production as other teams make changes to the live portal. For long-running projects, it is a good practice to periodically refresh your sandbox. This involves deleting the old one and creating a fresh copy of the production environment to ensure you are building on the most current foundation. Once a project is complete and all assets are synced, the associated sandbox should be deleted to keep your account tidy.
Appointing a 'gatekeeper' is arguably the most important best practice. This individual or small team is given the sole responsibility for executing the 'Sync to production' action. All changes must be submitted to them for a final review and deployment. This creates a crucial control point, preventing developers from accidentally pushing unfinished work or marketers from deploying untested workflows. This role ensures that every change to the live portal is deliberate, reviewed, and approved.
Standard vs. Developer Sandboxes
Recently, HubSpot introduced a second type of sandbox: the Developer Sandbox. This is distinct from the Standard Sandbox that most Enterprise users are familiar with. Developer Sandboxes are purpose-built for creating, testing, and demonstrating applications and integrations that will be listed on the HubSpot App Marketplace. Their feature set is tailored specifically to the needs of app developers.
The key difference lies in the tooling. Developer Sandboxes include features that are not present in Standard Sandboxes, such as the ability to create test commerce objects for Shopify integrations and tools for provisioning test accounts for an app. They are focused entirely on API development, CRM extensions, and preparing a public-facing application. Standard Sandboxes, by contrast, are designed for internal teams to test their own portal's assets like themes, workflows, and properties. Check our pricing page to see how we can assist with both internal development and app creation.
Choosing the right sandbox is simple. If you are a HubSpot customer looking to test changes for your own website, your marketing automation, or your sales process, you need a Standard Sandbox. This is the correct environment for nearly all internal development and testing work. If you are a software company or developer building an application to connect with HubSpot and list on the App Marketplace, you must use a Developer Sandbox.