Heroku
Heroku is the cloud application platform that Salesforce acquired in 2010, now offered as part of the Salesforce platform family.
Definition
Heroku is the cloud application platform that Salesforce acquired in 2010, now offered as part of the Salesforce platform family. It is a managed Platform as a Service that runs applications written in Ruby, Node.js, Python, Java, Go, PHP, Scala, and Clojure on Linux containers called dynos, without asking the developer to manage servers, operating systems, or patching.
In the Salesforce world, Heroku is where code goes when it needs a runtime outside Apex governor limits. A customer-facing web app, a high-volume batch job, a machine learning pipeline, or a microservice that powers an Agentforce action can all live on Heroku and still exchange data with Salesforce. Heroku is licensed and billed separately from your Salesforce org, with its own pricing (dyno usage plus add-on subscriptions) and its own admin console at dashboard.heroku.com.
How Heroku fits the Salesforce platform
The dyno, slug, and buildpack model
Heroku runs your code inside dynos, which the Trailhead Heroku Enterprise Basics module describes as managed runtime containers with a Linux operating system underneath. You do not build a server image. You push source code with Git or the Heroku CLI, and a buildpack detects the language, installs dependencies, and compiles the result into a slug. The slug is the deployable artifact that dynos execute. Scaling is two dials. You add more dynos to handle more traffic, or you move to a larger dyno size for more memory and CPU. A dyno formation is just the size and count of dynos running an app, such as three web dynos and two worker dynos. Web dynos answer HTTP requests through the Heroku router, while worker dynos run background jobs that have no web endpoint. Because the platform handles routing, TLS, log aggregation, and rolling restarts, a small team can run a production service without a dedicated operations group. That operational simplicity is the main reason Salesforce shops reach for Heroku instead of raw cloud infrastructure when they need custom code at scale.
Polyglot runtime beyond Apex
Apex is powerful inside the org, but it runs under governor limits and only speaks one language. Heroku removes both constraints. It is polyglot by design, so a team can pick Node.js for a real-time API, Python for a data science model, or Java for a service that reuses existing libraries. There is no per-transaction CPU ceiling, no SOQL row cap, and no 6 MB heap limit to design around. Long-running and compute-heavy work that would never survive in Apex becomes routine here. Think of nightly processing for millions of records, image or video handling, or a third-party API integration that needs to stay connected for minutes at a time. The trade is that Heroku code does not run inside your Salesforce security model automatically. You connect the two with a deliberate integration layer rather than assuming shared sessions. Teams often split the work, keeping business logic and the system of record in Salesforce while pushing scale-out compute to Heroku, then wiring the two together with one of the integration products described below.
Heroku Connect and Heroku Postgres
Every Heroku app can attach Heroku Postgres, a managed Postgres database with automated backups, point-in-time recovery, and read replicas. For Salesforce customers, Heroku Connect is the feature that makes the pairing valuable. Salesforce Help, in the Sync Data Between Salesforce and Heroku documentation, explains that Heroku Connect replicates data between your Salesforce org and a Heroku Postgres database. You map a Salesforce object to a Postgres table, choose the fields, and pick a direction. Read-only mode pulls Salesforce data into Postgres so a high-traffic app can query it locally without burning API calls on every page load. Bidirectional mode also writes changes back, so a row inserted in Postgres becomes a record in Salesforce. This pattern keeps Salesforce as the system of record while giving a public application a fast, SQL-native copy of the data it needs. One caution from the same docs is that data security settings from Salesforce do not automatically carry over to the Heroku store, so you control access to the Postgres tables yourself.
Heroku AppLink, the newer integration path
Heroku Connect syncs data. Heroku AppLink, formerly called Heroku Integration, exposes Heroku apps as callable services inside Salesforce. With AppLink, a developer publishes a Heroku API, and Salesforce admins can invoke it from Flow, Apex, External Services, Data Cloud, and Agentforce. The add-on can auto-generate external service actions and Agentforce agent actions from the app API, and it enforces Salesforce user permissions when the Heroku code reads or writes org data. That permission enforcement is the meaningful upgrade over older bring-your-own-auth integrations. It means a Heroku service can act on behalf of a specific user and respect their object and field access. AppLink is the path Salesforce points to when you want Heroku to power an Agentforce action or a Flow step rather than just hold a synced copy of data. For new builds that need request and response style calls into custom compute, AppLink is usually the right starting point, while Heroku Connect remains the choice when you mainly need a replicated database the app can query directly.
Private Spaces and compliance
The default Heroku environment, the Common Runtime, places dynos in a shared multitenant network. That is fine for many public apps. Regulated workloads usually need network isolation, and Heroku Private Spaces provide it. A Private Space is a dedicated, network-isolated runtime pinned to a region, which helps satisfy data residency rules and supports compliance programs such as HIPAA and PCI when configured correctly. Heroku now has two Private Space generations. Cedar is the established generation, and Fir is the newer one with its own dedicated networking, routing, and control plane. One practical detail from Heroku documentation is that trusted connections from Salesforce into Heroku currently target Cedar-generation spaces, so check the generation when you plan a Salesforce to Heroku link. Private Spaces cost more than the Common Runtime and add setup steps, but they make enterprise cases work that the shared runtime cannot serve. If your app touches protected health information or cardholder data, plan for a Private Space and the matching agreement from the start rather than retrofitting later.
Salesforce Functions retired, Heroku remains
Salesforce Functions was a serverless product, also known as Salesforce Elastic Services, that let you run code outside Apex on elastic infrastructure. Salesforce retired it on January 31, 2025, as recorded in the Salesforce Functions release notes on developer.salesforce.com. The retirement guidance pointed customers to alternatives including Apex, Flow, External Services, and Heroku, and Heroku is the natural home for the heavier workloads that drove teams to Functions in the first place. The same technology that powered Functions now lives in the broader Heroku platform, and Heroku AppLink covers the Salesforce-invokes-custom-code pattern that Functions used to handle. The practical takeaway is simple. If you still run Salesforce Functions, you need a migration plan, and redeploying that logic as a Heroku app behind AppLink is one of the supported routes. For anyone choosing where new off-platform code should live today, Heroku is the current, supported answer rather than the deprecated Functions runtime.
Add-ons and the wider ecosystem
Heroku is more than dynos and Postgres. Add-ons let you attach extra capability without managing the software underneath, as the Heroku Enterprise Basics Trailhead module puts it. A few provisioning commands give an app a Redis cache for sessions and queues, Apache Kafka for event streaming, a managed search index, or a monitoring and error-tracking service. Each add-on bills as its own monthly subscription and attaches as a config variable the app reads at startup, which keeps credentials out of source code. For Salesforce-connected builds, the common stack is Heroku Postgres plus Heroku Connect or AppLink, often with Redis for background job queues. Heroku Enterprise adds team-level controls, with licensed dyno and add-on usage pooled across apps and a usage view that only team admins can see, so finance can predict annual cost. The breadth of the marketplace is part of why Heroku stays attractive. A team can assemble a production architecture from supported components in an afternoon, then keep its attention on application code rather than on glue infrastructure.
How to set up Heroku Connect sync
Heroku Connect is the most common Heroku feature a Salesforce admin or developer configures. These steps set up a basic sync between a Salesforce object and a Heroku Postgres table. Do this in a Heroku app that already has Heroku Postgres attached.
- Provision Heroku Connect
From the Heroku Dashboard, open your app, go to Resources, and add the Heroku Connect add-on. Confirm Heroku Postgres is attached, since Connect needs a database to sync into.
- Authorize the Salesforce org
Open Heroku Connect, choose the database schema, then authenticate to your Salesforce org with a user that has API access and permission on the objects you plan to sync. Use a dedicated integration user, not a personal login.
- Create a mapping
Pick a Salesforce object such as Account, map it to a Postgres table, select the fields to include, and choose the sync direction. Start with read-only to validate the data flow before enabling writes.
- Validate, then enable bidirectional
Confirm rows appear in Postgres and counts match. Once read sync is healthy, switch the mapping to bidirectional so inserts and updates in Postgres write back to Salesforce.
Read-only copies Salesforce into Postgres. Bidirectional also writes Postgres changes back to the org. Choose per mapping based on who owns the data.
How often Connect checks Salesforce for changes. Faster polling lowers latency but consumes more Salesforce API calls against your daily limit.
An option that uses the Salesforce streaming and bulk APIs to move data faster for high-volume mappings. Enable it when a busy object lags behind.
The specific Salesforce fields exposed as Postgres columns. Map only what the app needs to keep the table lean and reduce API load.
- Heroku Connect consumes your Salesforce API call quota. A frequently updated object can exhaust the daily limit even when the data volume is small, so size polling and mappings around API calls, not row counts.
- Salesforce security settings do not carry over to Heroku Postgres. Anyone with access to the database can read every synced row, so lock down database credentials and access.
- Heroku and Salesforce are billed separately. Dyno usage, Heroku Postgres tiers, and each add-on are their own line items outside your Salesforce contract.
Prefer this walkthrough as its own page? How to Heroku in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Heroku.
Hands-on resources to go deeper on Heroku.
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. What is Heroku within the broader Salesforce platform ecosystem?
Q2. How does Heroku Connect bridge a Heroku application to Salesforce data?
Q3. When Salesforce Functions was retired in 2024, which product did the note point Heroku-style workloads toward?
Discussion
Loading discussion…