Salesforce Hyperforce: The Complete 2026 Guide for Admins, Developers & Architects

If you've logged into a Salesforce org any time in the last twelve months, there's a good chance it's already running on Hyperforce — and if it isn't, it will be soon. By the end of 2026, Salesforce expects nearly every customer org to have completed the migration off legacy first-party data centers and onto its public-cloud-native infrastructure platform.

This is the largest infrastructure transition in Salesforce's history. It changes where your data lives, how compliance is enforced, what IP ranges your integrations call out from, and which sandbox types you can spin up. It's also the reason Agentforce and Data Cloud (now Data 360) work the way they do.

This guide covers everything you actually need to know as an admin, developer, or architect — no marketing fluff, just the operational reality of running on Hyperforce in 2026.

What Hyperforce Actually Is

Hyperforce is Salesforce's re-architected infrastructure platform that runs the entire Customer 360 stack on public cloud providers — AWS, Microsoft Azure, Google Cloud Platform, and Alibaba Cloud — instead of Salesforce's own bare-metal data centers.

It's tempting to think of this as "Salesforce just rented some EC2 instances," but that misses the point entirely. According to the Salesforce Hyperforce overview, the platform was rebuilt from the ground up using infrastructure-as-code, immutable infrastructure, and Kubernetes-style orchestration. The classic "instance" you used to see in your URL (NA45, EU12, etc.) is gone. Your org now lives in a region, not on a single physical pod.

Three things define Hyperforce:

1. Public cloud native. Every component — compute, storage, networking, identity — uses cloud-provider primitives (S3, EBS, IAM, VPCs) rather than Salesforce-built equivalents.
2. Region-based, not instance-based. Capacity scales horizontally. There's no "your pod is full" anymore.
3. Zero-trust by default. Every service-to-service call is mutually authenticated and encrypted, even inside the perimeter.

For most users, the day-to-day Salesforce experience is identical. The URL pattern changed (yourorg.my.salesforce.com is now the standard, MyDomain mandatory), and a few admin screens look different, but Apex still runs, Flow still flows, and reports still report. What changes is everything underneath.

The Architecture: Built on AWS, Azure, GCP, and Alibaba

Hyperforce is multi-cloud by design, but each region runs on exactly one cloud provider. You don't get to choose AWS versus Azure for the same region — Salesforce picks the provider per region based on availability, sovereignty rules, and partnership agreements.

The architecture is layered:

• Layer 1 — Cloud provider primitives. EC2/EKS, RDS, S3, ELB on AWS; equivalents on Azure, GCP, and Alibaba. This is where compute and storage actually live.
• Layer 2 — Hyperforce platform services. Service mesh, identity broker, secrets management, observability. Built by Salesforce, runs identically on all four providers.
• Layer 3 — Salesforce application services. Core CRM, Data Cloud, Marketing Cloud, Commerce Cloud, Slack, MuleSoft Anypoint Platform — all the products you actually license.
• Layer 4 — Customer org. Your data, your metadata, your configuration. Logically isolated, encrypted at rest with per-customer keys when Salesforce Shield is enabled.

The critical thing to understand: your org is not "in AWS" in a way that matters operationally. You don't get a VPC peering relationship with Salesforce. You don't see EC2 instances. The cloud provider is an implementation detail — you interact with Salesforce APIs the same way you always did. But that implementation detail matters enormously for compliance, residency, and which Hyperforce-specific features you can use.

Data Residency and Compliance

This is the section that gets executives off the fence. Pre-Hyperforce, "data residency" mostly meant "we promise the data sits in our Frankfurt data center." With Hyperforce, residency is enforceable at the infrastructure level and verifiable through cloud-provider audit trails.

What "data at rest in your country" really means

When you provision an org in Hyperforce EU (Germany), the following are guaranteed to remain in-region:

• Production data (objects, files, attachments)
• Backups and point-in-time recovery snapshots
• Index data and search caches
• Sandbox refreshes derived from the production org
• Audit logs and Field Audit Trail history

What is not guaranteed to be in-region without explicit configuration:

• Telemetry and operational metrics (often centralized to a single region)
• Some Einstein/AI inference traffic — controllable via the Einstein Trust Layer and Einstein region settings
• MuleSoft runtime data if you use a global control plane (use EU control plane to keep it in-region)

GDPR, HIPAA, and sector-specific compliance

Hyperforce is certified for the major frameworks: SOC 1/2/3, ISO 27001/27017/27018, PCI-DSS, FedRAMP Moderate (and High in select US regions), HIPAA, IRAP (Australia), C5 (Germany), and TISAX. The Salesforce Trust site publishes the current attestation matrix per region.

For GDPR, Hyperforce regions in the EU give you contractual and technical guarantees that personal data does not leave the EEA. For HIPAA, Salesforce will sign a BAA on Hyperforce for the relevant covered editions. For data sovereignty laws like India's DPDP Act, the UAE's PDPL, and Saudi Arabia's PDPL, Hyperforce regions in those countries are typically the only path to compliance.

Hyperforce Regions Worldwide

As of early 2026, Hyperforce is generally available in over 20 regions across five continents. Salesforce is actively bringing up new regions roughly every quarter, and you can check the current list on the Salesforce Trust availability page.

Here's a representative snapshot of the major regions and their underlying cloud provider:

A few things to note:

• Most regions run on AWS. Azure and GCP regions exist but are fewer. Alibaba is exclusive to mainland China and operated under a local partnership structure.
• Region pairing matters for DR. Hyperforce uses an active-passive DR model where each region has a paired secondary in the same legal jurisdiction (or a closely aligned one). USE pairs with USW, DE pairs with FR, and so on.
• You don't choose the cloud provider. When you provision a new org, you pick the region. The provider is fixed.

Hyperforce vs. Classic Infrastructure

For most teams, the gap between classic ("first-party") infrastructure and Hyperforce is bigger than they realize. The user experience is the same; the operational model is fundamentally different.

The "callout IP ranges" row is the one that breaks the most integrations during migration. Don't skip it.

What Admins Need to Know

If you're an admin, the migration is mostly transparent — but there are concrete items on your checklist.

MyDomain is mandatory

Hyperforce requires MyDomain to be deployed and enforced. If your org still uses the legacy na45.salesforce.com-style URL, you cannot migrate. The first step in any migration project is enabling MyDomain, redirecting users, and updating any hardcoded URLs in email templates, formulas, and integrations.

Setup screens you'll see change

A handful of Setup pages got rebuilt for Hyperforce:

• Company Information now shows "Instance" as a region code (e.g., USE) and explicitly lists the Hyperforce status.
• My Domain has new Hyperforce-specific URL options including enhanced domains (which are required, not optional).
• Trusted IP Ranges and Login IP Ranges behave the same, but the Salesforce-side IPs that your network team needs to allowlist for inbound connections are different — see the developer section below.
• Sandbox management is faster, and full copy sandboxes are dramatically quicker to refresh.

Salesforce Shield works differently (and better)

Salesforce Shield on Hyperforce gets meaningful upgrades:

• Shield Platform Encryption uses cloud-provider HSMs (AWS KMS, Azure Key Vault) under the hood, with stronger BYOK and Cache-Only Key support.
• Field Audit Trail retention is cheaper and faster to query because it sits on cloud object storage.
• Event Monitoring streams are higher-throughput and lower-latency.

If you previously hit Shield limits or found Field Audit Trail slow to query, retest on Hyperforce.

Sandbox types and refresh behavior

Sandbox provisioning and refresh times drop significantly. Full copy sandboxes that took 24-48 hours can complete in a few hours. The sandbox type names (Developer, Developer Pro, Partial Copy, Full) are unchanged, but Partial Copy sample sizes can be larger and refresh windows are more flexible.

What Developers Need to Know

Callout IP ranges — read this twice

Every Hyperforce region publishes its own outbound IP CIDR blocks. These are different from the classic instance IPs. If your integrations rely on IP allowlisting on the receiving side (your ERP firewall, a payment gateway, a partner API), you must update those allowlists before migration — or callouts will start failing the moment your org cuts over.

The authoritative list lives in the Salesforce Hyperforce migration documentation. Pull it via API and feed it into your firewall change-management process. The list updates as Salesforce expands NAT pools, so don't treat it as one-time work.

Named Credentials should be your default

If you're still using hardcoded endpoint URLs in Apex, Hyperforce migration is a forcing function to switch to Named Credentials and External Credentials. Named Credentials abstract the endpoint, the auth, and the per-region behavior. If a partner moves their API, you change one record instead of redeploying Apex.

Apex callouts and timeouts

Default callout timeouts (10 seconds, max 120) are unchanged, but cross-region latency profiles are different. If your org moves from a US classic pod to a Hyperforce EU region and you're calling a US-hosted API, expect higher round-trip latency. Test long-running callouts and HttpRequest patterns before migration. Consider Platform Events or the Bulk API for anything that previously skirted timeout limits.

Connect API, Pub/Sub API, and Streaming

The Pub/Sub API (gRPC-based) is Hyperforce-first. If you're building event-driven integrations in 2026, prefer Pub/Sub API over the legacy CometD streaming endpoints — it's faster, has better backpressure semantics, and is the recommended path forward.

Static resources, content, and CDN

Static files served from your org now go through a Hyperforce-managed CDN. If you've shipped Lightning Web Components that load assets via hardcoded na45.lightning.force.com URLs, fix those. Use $Resource references or relative URLs.

What Architects Need to Know

Multi-org topology

If you run a multi-org architecture (typical at large enterprises), Hyperforce changes the calculus on a few fronts:

• Region co-location matters more. Two orgs in the same Hyperforce region have meaningfully better cross-org performance for MuleSoft or middleware-mediated integrations than two orgs in different regions.
• Salesforce-to-Salesforce integrations (Connect, Salesforce Connect external objects, Cross-Cloud Connectors) get faster within a region.
• Org Splits and Org Merges are operationally simpler when both orgs are already on Hyperforce in the same region.

MuleSoft on Hyperforce

MuleSoft's Anypoint Platform runs on Hyperforce too. The Anypoint control plane and the runtime fabric can be deployed in regions matching your Salesforce orgs, which dramatically simplifies residency stories. If you have a single global MuleSoft tenant feeding multiple Salesforce orgs in different regions, evaluate whether to split into regional control planes for compliance.

Trust boundaries and zero trust

Hyperforce enforces a zero-trust model internally — every service-to-service call uses mutual TLS and short-lived workload identities. From an architect's perspective, this means:

• Inbound API traffic terminates at a Hyperforce edge with WAF and DDoS protection by default.
• Customer-managed encryption keys can be held in your own cloud KMS via Cache-Only Keys, giving you a true cryptographic kill-switch.
• Private Connect (the Hyperforce equivalent of VPC peering for Salesforce) is available in select regions on AWS, letting your Salesforce traffic travel from your VPC to your org without traversing the public internet.

If you have a CISO review every two years, refresh the architecture diagrams. The threat model on Hyperforce is materially different — and mostly better.

Data 360 and cross-region

Data Cloud (now Data 360) requires Hyperforce. If you're consolidating data across multiple Salesforce orgs into a single Data 360 instance, that Data 360 instance is in one region. Decide carefully which region — once Data 360 is provisioned in a region, moving it is a project, not a configuration change.

The Migration: Timeline, Checklist, What to Watch For

Salesforce assigns each org a Hyperforce migration window — typically a weekend, communicated 6-12 months in advance through Setup notifications, the Lifecycle Management Console, and your account team. You can request rescheduling within bounds but cannot indefinitely defer.

Pre-migration checklist (4-12 weeks out)

• Confirm MyDomain is deployed and enforced
• Inventory all integrations and identify which rely on inbound IP allowlists
• Pull the destination region's Hyperforce IP ranges and pre-stage firewall rules
• Audit hardcoded URLs in Apex, LWC, Visualforce, email templates, formula fields, custom metadata
• Review Named Credentials and External Credentials coverage
• Test Connected Apps and SAML SSO with the new MyDomain URL
• Validate any reverse-proxy or CASB that intercepts Salesforce traffic
• Run a Hyperforce-aware sandbox refresh and re-execute regression tests there
• Engage MuleSoft, Marketing Cloud, and Data 360 teams on their own migration timing

Migration weekend

The actual cutover is usually a few hours of read-only mode followed by a brief outage window. Salesforce handles the data move; your team is on standby for integration validation as soon as the org comes back up.

Post-migration (first two weeks)

• Confirm all inbound integrations reconnect successfully (this is where IP allowlist gaps surface)
• Verify scheduled Apex jobs and Flow scheduled paths fired on schedule
• Spot-check Event Monitoring and Field Audit Trail capture
• Reconfirm Shield encryption keys and rotate if your policy requires it post-migration
• Update any internal documentation that references the old instance code

What to watch for

The three failure modes that account for most migration incidents:

1. Forgotten IP allowlists on receiving partners — the org cuts over, callouts start firing from new IPs, partner firewalls reject them.
2. Hardcoded URLs in email templates and signatures — users start clicking dead links Monday morning.
3. SSO misconfiguration — IdPs that hardcoded the old instance URL in ACS or audience values reject the new endpoint.

None of these are technically hard. All of them are easy to miss without a methodical inventory.

Hyperforce and Agentforce 360

This is the strategic reason Salesforce pushed so hard on Hyperforce: Agentforce requires it.

Agentforce 360 — Salesforce's AI agent platform — depends on infrastructure capabilities that classic pods simply cannot provide:

• Elastic GPU/inference capacity. AI agents need bursty access to inference compute. Hyperforce gets that by leaning on the cloud providers' GPU pools.
• Vector search at scale. Agent grounding and retrieval require vector databases co-located with your CRM data. Data 360 (on Hyperforce) provides this.
• Low-latency tool calls. When an agent invokes a Flow, an Apex action, or a MuleSoft API, the round-trip needs to be tens of milliseconds, not hundreds. Hyperforce's modern networking stack delivers that.
• Trust Layer enforcement. The Einstein Trust Layer — which handles PII masking, prompt logging, and zero-data-retention contracts with LLM providers — runs as a Hyperforce-native service.

If you're planning Agentforce work in 2026 and your org is still on classic infrastructure, you have a sequencing problem. Hyperforce migration isn't optional for Agentforce — it's a prerequisite. Bake the Hyperforce window into your Agentforce program plan, not the other way around.

Conclusion: What to Do Now

If you take three things from this guide:

1. Find out your migration window. Check Setup, talk to your AE. If you're already on Hyperforce, confirm it. If you're not, get the date on every relevant team's calendar.
2. Treat the IP allowlist work as the highest-risk item. It's the one thing your team can't fully test until cutover, and it's where most outages happen. Pre-stage everything.
3. Stop building anything new against classic assumptions. Use Named Credentials, MyDomain URLs, Pub/Sub API, and modern packaging. Anything else is technical debt with a known expiration date.

Hyperforce is not a marketing relabel. It's a real re-platforming of the entire Salesforce stack onto modern public cloud infrastructure, and it unlocks the next decade of capabilities — Agentforce, Data 360, Private Connect, and whatever comes next. The orgs that finish their migration cleanly in 2026 will spend 2027 building on top of it. The ones that don't will spend 2027 still finishing the migration.

Get your org on the right side of that line.