Every ServiceNow developer have few common nightmares: someone else's changes quietly overwriting there's, or a proof of concept breaking something that matters. @jivanjotkaur , Product Manager for Developer Sandboxes, walked through how ServiceNow Developer Sandboxes solve that by giving every developer an isolated development instance to build, test, experiment and best part you can respawn it instantly. 

 

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F06YYWoar5lw%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D06YYWoar5lw&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F06YYWoar5lw%2Fhqdefault.jpg&type=text%2Fhtml&schema=youtube

 

What's new for Developer Sandboxes

 

Setup used to mean filing a ticket with ServiceNow support and telling them which instance and how many packs you needed. Brazil release moves that into your own hands with a dedicated Developer Sandboxes tab inside the App Engine Management dashboard. From there you see every instance that has sandboxes configured, how many packs you've bought, and which instance each one is assigned to.

 

A pack is the smallest unit you can install, and it can't be split. Right now the cap is three packs per instance, with that ceiling expected to rise as the product matures. Starting with Brazil, every customer also gets a free trial pack automatically, so you can put sandboxes through their paces on one of your instances before buying anything.

 

Assigning and allocating sandboxes

 

Assigning packs happens from the controller instance. You can choose a target instance from the dropdown (only instances mapped to this controller show up), and the system checks that the instance is "ready", meaning the dev sandbox plugin is already installed there. Choose how many packs to assign, confirm you understand the assignment is permanent (undoing it means a support ticket), and save. The backend then handles all the node setup and installation.

 

Once an instance has packs assigned, it gets its own sandbox management dashboard showing total sandboxes available, how many are already running, and how many you can still spin up. Two roles are defined here:

• Sandbox manager: typically a team lead or instance manager, can allocate sandboxes to themselves or to other people.
• Sandbox user: can access whatever sandbox has been allocated to them.

Allocating the sandbox is a simple process. You pick an available sandbox, assign it to a user, give it an alias so it's easy to identify the associate, and allocate. Before Brazil, spinning up a sandbox took anywhere from 15 minutes to an hour depending on how much data was on the instance. Brazil keeps a warm pool of sandboxes running in the background instead, so allocation is instant, and that pool refreshes against the base instance once every 24 hours so nothing drifts too far out of date.

 

Working inside a sandbox

 

You open a sandbox with a link or a copied URL, and it uses the same authentication as your base instance, so local logins or SSO carry over with nothing extra to configure. The URL is really the only visual cue that you're on a sandbox instead of the base instance, since everything else looks identical, so it's worth a habit of checking before you start making changes.

 

Build Agent now ships inside sandboxes out of the box, provided it's entitled and installed on your base instance. Every sandbox stays isolated from every other one, so your changes stay yours!

 

Getting your changes back out

 

Before Brazil, getting an update set out of a sandbox meant exporting it manually and importing it to another instance. Creating or allocating a sandbox, now automatically sets up remote update sources on both the sandbox and the base instance, each one labeled with the sandbox's name so it's easy to find later.

 

Complete an update set in the sandbox, and it lands on the base instance's matching remote source. From there, retrieving completed update sets pulls in only what's been completed since the sandbox was created, so nothing comes through twice. Conflict resolution works exactly the way it always has: preview, resolve, commit. It works the other direction too, pull changes from the base instance into your sandbox through that same remote source whenever you want to build on the latest code. If you're using Git, connect each sandbox to its own branch and push or pull between sandboxes, or between a sandbox and the base, through your usual repository.

 

Automating sandbox lifecycle with APIs

 

ServiceNow Brazil release also ships REST APIs for managing sandboxes programmatically:

 

• Check the status of a running creation or retirement operation.
• List every sandbox running on an instance.
• Create a new sandbox.
• Get details on a running sandbox.
• Retire a sandbox.

 

In the demo, creating a sandbox took just a name and the owner's user ID, and a follow-up list call confirmed it had spun up. That opens the door for CI/CD pipelines, MCP servers, Claude Code, or the Fluent SDK and CLI to manage a sandbox's whole lifecycle from wherever you already work, instead of manually driving it.

 

Best practice: keep them short-lived

 

The longer a sandbox stays up, the more likely it drifts out of sync with the base instance. The team's recommendation is to spin one up per story or defect, work in it for a day or two, and retire it once you're done or the sprint closes, then start fresh next time around.

 

What people asked during the demo 

 

How much data does a sandbox actually get? Sandboxes live inside the base instance's own database rather than a separate copy, so you're not duplicating data by creating one. Most tables stay shared with the base instance; what's isolated per sandbox is mainly the metadata.

 

Does Otto (Now Assist) work inside a sandbox? Yes, and it runs independently there, drawing on its own Assist consumption the same way it would on any instance.

 

What happens to sandboxes if the instance gets cloned? Dev Sandboxes are meant for sub-production instances only. Cloning over an instance that has sandboxes enabled, destroys any sandboxes that exist on it.

 

Is a sandbox locked to its owner? No. Owner is just a label for tracking and doesn't control permissions. Every sandbox takes a snapshot of the base instance's users and roles at the moment it's created.

 

Can the Sandbox APIs be wired into an MCP server? Yes, that's one of the intended uses.