Instance
An instance in Salesforce is the single unit of infrastructure that runs a Salesforce organization.
Definition
An instance in Salesforce is the single unit of infrastructure that runs a Salesforce organization. It is a cluster of application servers paired with a shared database, and every org is assigned to exactly one instance. That instance can be first-party infrastructure operated by Salesforce in its own data centers, or Hyperforce infrastructure hosted on Salesforce-managed AWS. Many customer orgs share one instance, with logical separation handled by the multitenant application layer.
The instance determines where your data physically lives, when your org receives each seasonal release, and which maintenance windows apply to you. Salesforce gives every instance a short identifier, such as AP0 for a first-party instance in Japan or GBR1 for a Hyperforce instance in the United Kingdom. You can look up your own instance in Setup under Company Information, and you can track its health on the public Salesforce Trust status site.
How instances shape where your org runs and when it changes
What an instance actually is
An instance is the slice of Salesforce infrastructure that hosts a defined set of customer orgs. Picture a cluster of application servers in front of a shared database, all sitting in one data center region. Your org runs on top of that shared stack, and so do many other customers. The platform keeps each org's data and metadata isolated through the multitenant model, so sharing hardware never means sharing records. Salesforce documentation states that each org belongs to a single instance, which is either first-party infrastructure that Salesforce owns and operates, or Hyperforce infrastructure hosted on Salesforce-managed AWS. The instance is the level at which Salesforce reports uptime, schedules releases, and runs maintenance. It is not something an admin creates or sizes. Salesforce assigns it at provisioning time based on the org's location and the infrastructure available there. Knowing your instance matters for support cases, integration design, and compliance reviews, because it tells you where your data lives and which published status and release calendars apply to your org.
Reading the instance name
Salesforce gives every instance a short identifier made of two or three letters followed by a number. The letters hint at the geography, and the number distinguishes instances in the same area. First-party instances tend to use a two-letter style, like AP0 for an instance in Japan. Hyperforce instances usually use three letters, often based on the country code, like GBR1 for the United Kingdom or USA2S for a United States instance. You can find this value in Setup. Enter Company Information in Quick Find, open the page, and read the Instance field in the Organization Detail section. The same identifier is available to code through the InstanceName field on the Organization object, so a SOQL query against Organization returns it for logging or conditional logic. Two other lookups work without Setup access. On Windows you can run nslookup against your My Domain host, and on macOS or Linux you can run dig. The status site also shows your instance once you search by domain. Each method returns the same identifier.
First-party pods versus Hyperforce
For most of Salesforce history, instances were physical pods that Salesforce built and ran in its own data centers. Hyperforce changes the foundation. It is Salesforce infrastructure built for the public cloud and described as composed of code rather than hardware, which lets Salesforce stand up capacity in new countries far faster than racking servers. Hyperforce runs on AWS, and each Hyperforce region is deployed across at least three separate locations called availability zones for resilience. Salesforce still keeps some first-party infrastructure running to balance load, so both kinds of instance coexist today. The practical differences show up in a few places. Express Connect, which reached Salesforce-operated data centers, is not available on Hyperforce, so customers needing private links use AWS Direct Connect instead. Data residency improves, because Hyperforce can place an org in a specific country to meet rules like GDPR. The instance identifier style also shifts toward the three-letter country format, which is a quick visual cue that an org sits on Hyperforce rather than a legacy pod.
The Salesforce Trust status site
Salesforce Trust is the public website that reports availability, performance, security, and compliance for every instance. Most admins reach it at status.salesforce.com. To find your own instance, type your My Domain into the search box at the top and press Enter. If your org lives at mycompany.my.salesforce.com, you search for mycompany, and the matching instance appears. The site uses a color code so status reads at a glance. Green means the instance is fully functional, blue is informational, purple is maintenance in progress, yellow is a degradation with partial functionality, and red is a disruption. Beyond live status, each instance page carries a maintenance tab with upcoming windows and the major release schedule for that instance. You can subscribe to email alerts for your instance, which is the cleanest way to learn about incidents and planned downtime without polling the page. For incidents that run past a short threshold, Salesforce advises opening a support case. Bookmarking your instance page filtered to your org turns this into a fast first stop during any suspected outage.
Releases and maintenance run per instance
Salesforce ships three major releases each year, named Spring, Summer, and Winter. Those releases do not reach every org on the same day. Salesforce rolls them out instance by instance over several weeks, and each instance has its own slot in the calendar. Sandbox instances generally take the new release on an early preview weekend, while production instances follow on later weekends. This staggering is why your sandbox can run a new version weeks ahead of the matching production org, which is exactly the gap you want for testing. The release schedule is published in advance and is visible on each instance page on the status site, so you can plan regression testing around your real dates rather than a generic launch announcement. Routine maintenance is also instance scoped. Hyperforce migrations themselves run during a planned maintenance window, with Salesforce giving advance notice and roughly three hours of downtime per the published guidance. Because all of this is tied to the instance, the first question during release or maintenance planning is always which instance the org is on.
Why integrations must not hardcode the instance
An org's instance can change. Salesforce migrates orgs to Hyperforce, and historically moved orgs between pods for load balancing, and either event can change the underlying host. Older integrations that hardcoded an instance hostname, like a literal na1.salesforce.com URL, break the moment the org moves. The durable fix is to address the org by its My Domain, which stays stable across instance changes and is the recommended endpoint pattern. When code genuinely needs the current instance, it should resolve it at runtime rather than assume a fixed value. The InstanceName field on the Organization object provides that value through SOQL, and the login response and session also expose the current instance URL for the org. Salesforce keeps legacy instance hostnames working as redirects for a period after a move, which buys time, but a redirect is a warning sign rather than a fix. Reviewing connected apps, middleware endpoints, and stored callback URLs for hardcoded instance hosts is a standard pre-migration task, and doing it early prevents a quiet failure on cutover weekend.
Sandboxes and instance assignment
Sandboxes are full or partial copies of a production org, and they also live on an instance. On legacy first-party infrastructure, sandboxes ran on dedicated sandbox instances that were separate from production pods, which is why a sandbox sometimes sat in a different location from its parent org. That separation occasionally affected refresh timing and connectivity testing. Hyperforce simplifies the picture, since a sandbox and its production org generally live in the same region. The instance still matters for sandboxes in one important way, which is the release calendar. Sandbox instances are usually the first to receive a new seasonal release during preview, giving teams a window to validate customizations before the change reaches production. When you check the status site for a sandbox, you search by the sandbox My Domain and read its own instance page, which can show a different release date and a different maintenance schedule than production. Treating the sandbox instance as its own entity, with its own dates and its own status, avoids surprises when a preview release lands earlier than expected.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Instance.
- Organization Object Reference (InstanceName field)Salesforce
- Use the Salesforce Trust SiteSalesforce
Hands-on resources to go deeper on Instance.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In the legacy hosting model, what did an instance identifier like NA12 or EU3 name?
Q2. Where does an admin check live uptime and maintenance windows for their Salesforce instance?
Q3. What modern architecture is gradually replacing the named-instance pod model?
Discussion
Loading discussion…