Heroku CLI v11 is now available. This release represents the most significant architectural overhaul in years, completing our migration to ECMAScript Modules (ESM) and oclif v4. This modernization brings faster performance, a new semantic color system, and aligns the CLI with modern JavaScript standards.

While v11 introduces breaking changes to legacy namespaces, the benefits are substantial: better performance, improved maintainability, and enhanced usability that simplifies how you manage Heroku resources from the command line.

Modern architecture built for performance and usability

Faster execution via ECMAScript Modules (ESM)

The transition to a full ESM-first architecture is the core of v11. By converting every command, library, and test from CommonJS to ESM, we’ve unlocked significant performance gains:

• Superior tree-shaking: Reduced bundle sizes lead to a leaner installation and faster updates.
• Faster command execution: Optimized module loading streamlines the internal execution path.
• Modern ecosystem alignment: The CLI now mirrors the standards of modern JavaScript, simplifying long-term maintenance.

Streamlined performance with Open CLI Framework (oclif) v4

We’ve jumped two major versions to oclif v4, bringing the CLI in line with the latest standards of the Open CLI Framework. This transition delivers:

• Faster command loading: Improved manifest caching ensures the CLI doesn’t have to parse every command for every interaction, making the experience significantly faster.
• Seamless interoperability: Version 11 ensures smooth compatibility between CommonJS and ESM plugins, allowing for a more flexible developer experience.
• Modular code organization: The upgrade to oclif v4 enables granular imports, leading to a leaner and more maintainable codebase.

To support these changes, we’ve also simplified our build system—migrating from Yarn to npm and removing the monorepo structure in favor of a single, more maintainable package.

Enhanced visual experience

Usability in v11 extends to how you interact with and interpret terminal data. The CLI’s visual output is now more intuitive, customizable, and accessible:

• Consistent semantic colors: Common Heroku resources, success, warning, and error messages now follow a unified color palette, making it easier to identify critical information at a glance.
• Modern theme support: With Version 11, the Heroku CLI is now themeable, allowing for a more modern and readable visual experience. You can also manually opt for a basic ANSI color scheme by setting the HEROKU_THEME=simple env var.
• Global accessibility: Version 11 supports disabling colors entirely by setting the NO_COLOR=true env var for users with visual impairments or those who prefer plain-text logging.

Node.js 22 support

The Heroku CLI v11 ships with Node.js 22 while maintaining Node.js 20 compatibility, providing several key benefits:

• Modern runtime access: Users can now leverage the latest JavaScript features and performance improvements provided by the Node.js 22 runtime.
• Latest standard alignment: The update ensures the CLI remains current with the evolving JavaScript ecosystem.
• Performance-first foundation: Supporting the latest LTS version of Node.js is essential for delivering the performance gains of our new ESM-first architecture.

New commands for modern Heroku workflows

We have also focused on the day-to-day developer experience. These updates refine how you interact with your Heroku resources and make it easier to discover the tools you need:

• Unified data maintenance: The heroku data:maintenance:* commands are now built into the core CLI. Note that legacy heroku pg:maintenance and heroku redis:maintenance commands have been deprecated.
• Fast command discovery: Can’t remember a command name? heroku search helps you find it fast.
• Global prompt support: The --prompt flag is now available globally and appears in help text for all commands that support it.
• Streamlined REPL invocation: Access to REPL is now accessible via heroku repl and included in our CLI documentation and help text. Try it out!

Transitioning to Heroku CLI v11

To support this new architecture, v11 includes a few updates to how certain commands and outputs behave. While these represent a shift from legacy versions, they are designed to make your workflow cleaner and more consistent:

• Output formatting: CLI output format has changed in v11, with the most visible changes in table formatting.
• AI plugin: To keep the core installation lean and fast, the heroku-cli-plugin-ai is now an optional installation rather than being bundled by default.
• Unified maintenance commands: We’ve simplified data management by moving maintenance tasks into the core data:maintenance:* namespace. This replaces the legacy pg:maintenance and redis:maintenance commands with a single, intuitive workflow.

A modernized CLI for a modern ecosystem

Heroku CLI v11 is a complete technical modernization designed to grow with the JavaScript ecosystem, and represents a major investment in the CLI’s future. By modernizing our architecture with ESM and oclif v4, we’ve built a faster, more maintainable foundation that will enable us to ship features more quickly while improving the developer experience.
Upgrade today or visit the installation guide. For a full list of updates, check out the CLI changelog. As always, we welcome your feedback as we continue to improve the developer experience.

The post Modernizing the Command Line: Heroku CLI v11 appeared first on Heroku.

Modern applications, especially those leveraging AI and data-heavy libraries, need more room to breathe. To support these evolving stacks and reduce developer friction, we’ve increased the default maximum compressed slug size from 500MB to 1GB.

Understanding app slugs and deployment

App slugs are the container build artifacts produced by Heroku Buildpacks and run in dynos. Allowing larger slugs makes it easier to deploy apps with large library or package dependencies on Heroku. Many AI and machine learning libraries fit this pattern and we’re looking forward to seeing what new types of apps will be possible with the higher limit.

How this can affect your dyno boot times

While the new 1GB limit provides more headroom, there is a direct correlation between slug size and dyno boot times. Larger slugs are slower to download and extract and starting large apps takes longer, which can slow down common tasks like scaling and heroku run commands. We still recommend that you try to keep slugs small and nimble to ensure optimal performance.

Increased build compile timeouts for complex apps

We’re also increasing the build compile timeouts as part of this change. Build timeout is another limitation commonly hit for complex Heroku apps with many dependencies. Heroku already has a lot of flexibility to allow occasional long-running builds when build caches are cleared, and today’s update increases these timeout limits across the board.

Removing deployment friction for developers

Slug size limits and build timeouts weren’t just minor inconveniences, they were recurring points of friction that disrupted developer flow. By easing these constraints, we’re ensuring that your deployment pipeline stays out of your way, allowing you to focus on building complex applications.

The post Bigger Slugs and Greater Build Timeout Flexibility appeared first on Heroku.

Most developers never see the 11 pack releases we shipped in the last 14 months as pack CLI maintainers. That’s actually a good sign—it means the infrastructure just works. When a critical vulnerability emerges requiring an immediate upgrade, the fix is shipped within days.

Here’s what most developers don’t see: that same security patch now protects every buildpack user across Heroku, Google Cloud, Openshift, VMware Tanzu, and thousands of internal platforms.

The daily work of platform maintenance

As maintainers of pack CLI, the entry point to Cloud Native Buildpacks (CNBs), our work lives in that invisible layer between developers and infrastructure. The routine looks like this: daily Slack monitoring, triaging GitHub issues, reviewing community pull requests, and participating in weekly Cloud Native Community Foundation (CNCF) working group meetings.

In the last 14 months, we’ve shipped 27 releases across CNB projects (11 for pack, 16 for buildpacks/github-actions), reviewed 65+ community PRs, and implemented two major features: Execution Environments and System Buildpacks. That’s roughly one release every 5-6 weeks, each bringing bug fixes, security patches, or new capabilities.

The work includes unglamorous but critical tasks: migrating Windows CI from Equinix LCOW to GitHub-hosted runners, upgrading from docker/docker to moby/moby client, and shipping FreeBSD binaries for broader platform support. When multi-arch builds needed the --append-image-name-suffix flag or when the Platform API 0.14 lifecycle restorer had issues, those fixes went out to everyone.

There are no flashy demos; instead this is invisible infrastructure work that proves its worth when an emergency security patch ships or a build completes in 30 seconds instead of failing after 5 minutes.

How upstream open source creates downstream value

Here’s where it gets interesting: Heroku has funded our maintainer work, but the benefits ripple across the entire cloud-native ecosystem. This bidirectional value is what makes open source infrastructure so powerful.

Take System Buildpacks, a feature we recently implemented:

• For Heroku, it means they can curate platform defaults while giving users flexibility with third-party buildpacks.
• For Google Cloud Run, it solves its buildpack composition problem.
• For internal platform teams, it eliminates the manual Procfile buildpack overhead that’s been a pain point for years.

That one newly implemented feature created universal benefit.

Or consider Execution Environments, another major feature we shipped this year. This enables Heroku to support test environments for CI products while also helping any platform operator who needs consistent build configurations across development, CI, and production. The code lives upstream in the CNCF project, battle-tested by multiple companies, and maintained collaboratively.

The CNCF governance model ensures no single company can control the direction. Companies like Heroku, Google, and VMware collaborate on infrastructure so they can compete on developer experience. When we fix a multi-arch publishing bug or add FreeBSD support, everyone benefits immediately.

Real innovation happens in production

The features we’re shipping aren’t theoretical, they solve real problems in production:

• Build Observability (RFC 0131): Platform operators need metrics and tracing to optimize costs and troubleshoot failures. Coming in Q3 2026, this will provide comprehensive visibility into build performance across the ecosystem.
• OCI Image Annotations (RFC 0130): Enterprise compliance requires metadata tracking. We’re making it zero-config so platforms can meet SOC2, FedRAMP, and other regulatory requirements without manual overhead.
• Removing Kaniko dependency: Supply chain security isn’t just buzzwords, it’s actively removing unmaintained dependencies from critical infrastructure to reduce risk.

Each feature starts with a production requirement, gets refined through community discussion, and ships as a standard that everyone can rely on.

Why this model works

At KubeCon EU 2025, the biggest question during our presentation “Buildpacks: Pragmatic Solutions to Quick and Secure Image Builds” wasn’t about technical implementation—it was about sustainability. How do we keep critical open source infrastructure maintained?

Companies like Heroku invest in dedicated maintainer teams, and get battle-tested technology that serves their needs while contributing to the commons. The ecosystem gets features driven by real production requirements, not academic speculation, and developers get reliable infrastructure that just works.

That’s the true impact of open source maintainership: 65+ PRs reviewed, 27 releases shipped, 2 major features delivered, and the countless invisible fixes that keep platforms running smoothly.

Join the conversation at KubeCon EU 2026

The evolution of Cloud Native Buildpacks continues, and there is no better place to see where we’re headed next than at KubeCon EU 2026.

If you want to dive deeper into the future of the project, don’t miss the upcoming session:

Buildpacks: Towards 1.0, AI, and Other Things
Thursday March 26, 2026 14:30 – 15:00 CET
Aidan Delaney, Bloomberg

This talk covers the road to 1.0, focusing on the stability and technical components (Lifecycle, Platform, and Builder) necessary for a production-ready foundation. Aidan will also showcase how the ecosystem is integrating AI and Machine Learning to simplify the deployment of AI-driven applications.

Visit the Buildpacks Project booth

The community will be out in full force! Stop by the CNB booth, P-3B in the Project Pavilion (map), to meet the maintainers, ask questions, and learn more about the “invisible” infrastructure powering your code. We’d love to see you there!

The post Behind the Scenes: How Maintaining Cloud Native Buildpacks Powers Platforms Like Heroku appeared first on Heroku.

Modern applications on Heroku don’t just consist of code. They are living ecosystems comprised of dynos, databases, third-party APIs, and complex user interactions. As these systems scale, so do the logs and metrics. To efficiently extract the signals from the noise you need to understand system health in the context of external factors, like resource limits . While Heroku removes the pain of managing servers, observability is critical for monitoring service interactions and performance optimization.

Maintaining peak performance and operational health demands sophisticated logging and monitoring capabilities. However, a common friction point remains: the “swivel-chair” workflow. The necessity of frequent toggling between application source code, deployment activity logs, and disparate monitoring dashboards creates significant cognitive load. When you are diagnosing a critical production error, every second spent correlating a timestamp from a log file to a spike on a separate metrics dashboard is a second lost.

To resolve this fragmentation, SolarWinds Papertrail powered by SolarWinds and Heroku have expanded the SolarWinds Papertrail add-on. By delivering logs and metrics into a single, unified solution, we are helping developers streamline troubleshooting and dedicate more time to writing high-quality code.

The high cost of context switching: Where traditional monitoring fails

Before we dive into the solution, it is worth dissecting the problem. In a traditional Heroku setup, a developer might rely on heroku logs –-tail for real-time events, a separate add-on for performance graphs, and perhaps a third tool for uptime alerting.

This fragmentation results in several operational inefficiencies:

• Correlation blindness: If your application throws a 500 error, was it caused by a memory leak, a database lock, or a bad deployment? Finding the answer requires manually matching the timestamp of the error log with the timestamp of the CPU spike on a different screen.
• Alert fatigue: When metrics and logs are siloed, alerts lack context. A “High CPU” alert is useless without the accompanying log lines that tell you what process was consuming that CPU.
• Tool sprawl: Managing multiple subscriptions, API keys, and dashboards increases administrative overhead and costs.

The cognitive load required to diagnose a production error is often higher than the complexity of the fix itself. This is where the unified SolarWinds Papertrail add-on changes the game.

The solution: One interface for logs and metrics

To simplify and consolidate your application’s observability stack, SolarWinds Papertrail has been extended to replace the functionality previously delivered by separate add-ons. The enhanced SolarWinds Papertrail add-on combines real-time log management, metrics dashboards, and alerting into a single, unified offering.

This consolidation provides a single pane of glass for all aspects of your application’s health. By bringing these capabilities under one roof, we eliminate the high cost of context switching.

Core components of the unified architecture

SolarWinds Papertail’s unified architecture isn’t just about moving data; it’s about transforming raw logs and metrics into actionable insights. By layering different types of operational data, we tell a complete story and eliminate the traditional barriers to speed.

Eliminate data lag with real-time unified ingestion

SolarWinds Papertrail’s signature feature has always been frustration-free log management. It allows you to tail and search logs as they happen. Real-time means real-time. There is no waiting for batches to process or indexes to update.

• Live tail: Watch events stream live, identical to the CLI experience but with powerful filtering and highlighting.
• Contextual search: Access your logs via a web browser, command-line interface (CLI), or API with the same effortless search format.

Gain instant visibility through native Heroku metrics

Instead of requiring a separate agent or complex configuration, SolarWinds Papertrail leverages Heroku’s native capabilities. It automatically ingests high-volume log data and structures it into actionable metrics.

• Dyno performance: Visualize CPU load, memory usage, and load averages per dyno.
• Application health: Track throughput, response times, and error rates.
• Data services: Monitor critical database performance including active and waiting connections, database size, cache hit rates, and IOPS to prevent connection saturation and storage bottlenecks.

When you view these metrics alongside your logs, the shape of your traffic becomes visible. A sudden dip in log volume might indicate a silent failure where requests aren’t reaching the server, while a massive spike could signal a DDoS attack or a runaway loop.

Cut through the noise with context-aware alerting

Alert fatigue is a real threat to operational excellence. If everything is an emergency, nothing is. The expanded SolarWinds Papertrail toolset moves beyond basic error counting to intelligent alerting.

You can now set granular, custom thresholds using minimum, maximum, average, or summary values on any metric. This allows you to filter out transient noise and focus on statistically significant deviations.

When a true issue is detected, the system integrates seamlessly with the tools you already use, pushing actionable notifications to Slack, PagerDuty, Microsoft Teams, and more.

Scale your team’s expertise with institutional memory

One of the most underrated challenges in growing development teams is the loss of troubleshooting context during handoffs or scaling. SolarWinds Papertrail addresses this by treating every saved search and custom alert as institutional memory.

Because all Heroku collaborators can contribute to a shared library of diagnostic tools, the platform accumulates your team’s collective expertise. A complex search query written to diagnose a specific race condition today doesn’t vanish into a terminal history; it becomes a reusable diagnostic tool for a junior developer tomorrow.

The 2:00 AM test: From fragmented logs to near-instant resolution

To understand the practical impact, let’s look at a common scenario. The incident: It is 2:00 AM. Your PagerDuty triggers an alert: “API Response Time High.”

The old way

You wake up, log into your metrics dashboard, and see a spike in response time starting at 1:55 AM. You then open your logging provider and try to search for logs from that timeframe. You are scrolling, trying to mentally overlay the graphs with the text. You see some database errors but aren’t sure if they are the cause or the symptom.

The SolarWinds Papertrail way

You click the link in the PagerDuty alert. It takes you directly to the SolarWinds Papertrail dashboard, focused on the 1:55 AM timeframe.

1. Top view: You see the “Response Time” graph spiking.
2. Bottom view: Directly underneath, you see the log stream for that exact moment.
3. Diagnosis: You notice a specific background worker (Dyno worker.1) outputting “Out of Memory” errors (R14) right as the latency spiked.
4. Resolution: You identify that a specific batch job was consuming too much RAM. You restart the dyno and push a fix to optimize the job.

Total time? Minutes, not hours. The correlation was instant because the data was unified.

Migration: Simplifying the stack

Other SolarWinds add-ons, Librato and AppOptics were deprecated at the end of January 2026. For teams previously relying on separate add-ons like Librato or AppOptics, the path forward is now significantly streamlined. Managing distinct subscriptions and dashboards for logs versus metrics is a relic of the past now that we’ve brought metrics into SolarWinds Papertrail.

Accelerate development and minimize headaches with SolarWinds Papertrail

Modern development isn’t just about shipping code. It’s about owning the lifecycle of that code in production. The SolarWinds Papertrail add-on for Heroku offers a path away from fragmented, frustration-filled troubleshooting toward a streamlined, full-stack view of your application’s health.

By consolidating logs, metrics, and alerting into a single, frustration-free interface, you regain the focus required to build what’s next.

Ready to streamline your workflow? Find SolarWinds Papertrail in the Heroku Elements Marketplace today.

The post From Fragmented Logs to Full-Stack Visibility with SolarWinds Papertrail appeared first on Heroku.

The web browser and certificate authority industry is shortening the maximum allowed lifetime of TLS certificates. These changes will improve security on the Web, but you may have to change certificate maintenance practices for apps you run on Heroku.

The good news is that if you’re using Heroku Automated Certificate Management, no changes are required: Heroku already refreshes and updates certificates on your apps according to the new policies.

If you maintain and upload certificates for your Heroku applications yourself, here is what the changes will mean for you.

Industry shift towards shorter certificate lifetimes

The CA/Browser Forum is phasing in shorter maximum lifetimes for all publicly trusted SSL/TLS certificates. While the final goal is a 47-day limit by 2029, the first major milestone is approaching quickly.

Starting March 15, 2026, the maximum validity period for publicly trusted SSL/TLS certificates will be reduced to 200 days.

Why this is happening

Shorter certificate lifespans improve security by:

• Reduced exposure: Shrinks the window of exposure if a private key is compromised
• Modern standards: Ensures certificates rotate frequently to adopt the latest cryptographic standards
• Automation: Encourages a shift toward automated certificate management

Recommended actions for manual certificate users

If you use custom SSL certificates on Heroku (certificates you obtain and upload yourself), you will need to:

• Plan for more frequent renewals: After March 15, 2026, you’ll need to renew certificates at least every 200 days (approximately every 6.5 months) rather than annually.
• Update your renewal processes: Ensure your team or certificate management tools can handle the increased renewal frequency.
• Check your current certificates: Review the expiration dates of your existing certificates.Note: Certificates issued before March 15, 2026 with longer validity periods will remain valid until they expire, but renewals after that date must comply with the new 200-day maximum.

Automating certificate renewals with Heroku ACM

Consider switching to Heroku Automated Certificate Management (ACM). ACM automatically provisions and renews certificates for your custom domains at no additional cost, eliminating the need for manual certificate management.

To enable ACM for your app:

heroku certs:auto:enable -a your-app-name

Learn more: Heroku ACM Documentation

Have questions about certificate management?

If you have questions about these changes or need assistance with your certificate strategy, please contact Heroku Support or visit our documentation:

• SSL Certificates on Heroku
• Automated Certificate Management

We’re committed to helping you navigate these industry changes smoothly.

The post Preparing for Shorter SSL/TLS Certificate Lifetimes appeared first on Heroku.

Heroku is introducing significant updates to Managed Inference and Agents. These changes focus on reducing developer friction, expanding model catalogue, and streamlining deployment workflows.

More flexibility with the new standard plan

Until now, Heroku’s model-based plans required developers to provision a specific add-on for a specific model. This created significant operational overhead. If you wanted to experiment with a different model or implement a fallback strategy, you had to provision a new add-on and manage multiple config variables.

We have added a new standard plan for Heroku Managed Inference and Agents.

With this update, a single add-on and a single API key grant access to our entire catalog of supported models. You no longer need to reprovision resources to switch from a smaller model to a high-reasoning model. Instead, you simply update the model name in your code. This unified approach improves developer experience and allows for more robust application architectures. Try the standard mode using the following CLI command:

$ heroku addons:create heroku-inference:standard -a $APPNAME

New frontier models and an expanded open-weight catalog

Claude 4.6 models

Heroku now supports the Claude 4.6 family, the most capable models in the Claude family, designed for high-complexity workloads.

• Claude Opus 4.6: Designed for advanced software development, complex agentic workflows, and long-horizon planning.
• Claude Sonnet 4.6: High-performing model that is ideal as a daily driver and sophisticated financial analysis.

Open-weight models

We have also expanded our catalog with five new open-weight models to provide more cost-effective options for diverse use cases.

• DeepSeek v3.2: Advanced model built for high-efficiency agentic reasoning and long-context understanding.
• Kimi K2.5: Optimized for massive context processing, advanced mathematical reasoning, and complex agent swarms.
• MiniMax M2.1: Specialized for practical engineering and multi-language full-stack application building.
• ZAI GLM 4.7: Industry-leading model for reliable tool-calling and vibe coding visually aesthetic front-ends.
• ZAI GLM 4.7 Flash: A lightweight model optimized for speed, cost-efficiency, and agentic workflows where responsiveness is critical.

Embed models

We are enhancing our support for vector-based search and retrieval with a new Cohere Embed V4 model. The latest generation of Cohere’s embedding technology is built for higher accuracy and complex document analysis.

• Cohere Embed V4: Specifically designed to understand conceptual relationships rather than just keyword matching.

Model deprecation notice

As we transition to these next-generation models, we are beginning the deprecation process for older versions, including Claude 3.5, Claude 3.7, and Claude 4. Users are encouraged to migrate to Claude 4.5 and 4.6 to ensure continued support and optimal performance.

Build better with Heroku AI

The shift to a standard plan and the addition of new frontier models like Claude Opus 4.6 represent Heroku’s commitment to providing access to a wide model catalogue. By improving developer experience and expanding model choice, we are making it easier than ever to build, scale, and optimize AI-powered applications.

To get started, visit the Heroku Dev Center or provision the new standard plan for Heroku Managed Inference and Agents today.

The post Whats New in Heroku AI: New Models and a Flexible Standard Plan appeared first on Heroku.

Large language models are good at writing code. Data from Anthropic shows that allowing Claude to execute scripts, rather than relying on sequential tool calls, reduces token consumption by an average of 37%, with some use cases seeing reductions as high as 98%.

Untrusted code needs a secure and isolated place to execute. We solved this with code execution sandboxes (powered by one-off dynos), launched alongside Heroku Managed Inference and Agents in May 2025.

You can leverage these sandboxes in two ways:

• Built-in tools, within our Managed Inference and Agents API
• MCP tool, by deploying our open-source Model Context Protocol (MCP) servers to connect the sandbox to any client, including Agentforce, Claude Desktop, or Cursor

How agents improve with code execution tools

Every tool definition and intermediate output is forced through the model’s context window. This is highly inefficient. For example, if you analyze a 10MB log file, the entire file consumes your context even if you only need a brief summary of the errors.

The better pattern, which Anthropic calls programmatic tool calling, lets the model write code that orchestrates everything.

If you’re using Salesforce and want to ask Agentforce to find at-risk deals in your Q1 pipeline, the agent writes a script that queries thousands of opportunities, cross-references activity history, filters for deals with no recent engagement, and returns just the 12 that need attention. The tool execution and reasoning and analysis can happen in the Heroku sandbox and only the summary hits the model’s context.

Isolation via one-off dynos

To execute untrusted code safely, we use one-off dynos. This is the same infrastructure that has been used for administrative or maintenance tasks on Heroku for over a decade. Because these dynos are spun up on demand and terminate after use, they provide a naturally isolated, cost-effective, and secure environment, which means the blast radius of LLM generated code is limited to an ephemeral container.

How to use the built-in tools

If you’re using the Managed Inference and Agents API, include code_exec_python (or code_exec_ruby, code_exec_node, code_exec_go) in your tool list:

curl "$INFERENCE\_URL/v1/agents/heroku" \\
  -H "Content-Type: application/json" \\
  -H "Authorization: Bearer $INFERENCE\_KEY" \\
  -d '{
    "model": "claude-4-sonnet",
    "messages": [
      {
        "role": "user",
        "content": "Calculate the standard deviation of [23, 45, 67, 12, 89, 34, 56, 78, 90, 11]"
      }
    ],
    "tools": [
      {
        "type": "heroku_tool",
        "name": "code_exec_python"
      }
    ]
  }'

The agent writes Python, we execute it in a dyno, and stream back the result:

{  
  "choices": [  
    {  
      "message": {  
        "role": "assistant",  
        "content": "The standard deviation is 30.19. Here's what I calculated:\n\nMean: 50.5\nVariance: 911.39\nStd Dev: 30.19\n\nThe data has fairly high spread - values range from 11 to 90."  
      }  
    }  
  ]  
}

You can pass runtime_params with max_calls to limit how many times the tool runs during a single agent loop.

Deploying your own code execution MCP server

For Agentforce, Claude Desktop, Cursor, or custom frameworks, deploy the MCP server directly:

git clone https://github.com/heroku/mcp-code-exec-python
cd mcp-code-exec-python
heroku create my-sandbox
heroku config:set API_KEY=$(openssl rand -hex 32)
git push heroku main

The server implements the Model Context Protocol. Point your client at it and you get the same sandboxed execution. We have implementations for Python, Ruby, Node, and Go. Each repo has a deploy button if you prefer one-click setup.

Start building more powerful, efficient AI agents by trying out our code execution sandboxes today.

The post Code Execution Sandbox for Agents on Heroku appeared first on Heroku.

If you’ve ever debugged a production incident, you know the drill: IDE on one screen, Splunk on another, Sentry open in a third tab, frantically copying error messages between windows while your PagerDuty keeps buzzing.

You ask “What errors spiked in the last hour?” but instead of an answer, you have to context-switch, recall complex query syntax, and mentally correlate log timestamps with your code. By the time you find the relevant log, you’ve lost your flow. Meanwhile the incident clock keeps ticking away.

The workflow below fixes that broken loop. We’ll show you how to use the Model Context Protocol (MCP) and Heroku Managed Inference and Agents to pipe those observability queries directly into your IDE, turning manual hunting into instant answers.

Connecting telemetry to code for AI-powered observability

The system connects AI coding assistants to observability platforms through the Model Context Protocol (MCP), with Managed Inference and Agents handling the transport layer.

Building the MCP servers

Unified tool interface

We expose each observability platform through MCP’s consistent tool interface. Here’s how we define a Splunk search tool:

searchTool := mcp.NewTool("search_splunk",
    mcp.WithDescription("Execute a Splunk search query and return the results."),
    mcp.WithString("search_query", mcp.Description("The search query to execute")),
    mcp.WithString("earliest_time", mcp.Description("Start time for the search")),
    mcp.WithString("latest_time", mcp.Description("End time for the search")),
    mcp.WithNumber("max_results", mcp.Description("Maximum number of results")),
)

The AI assistant sees this as a callable tool with typed parameters. When a user asks about errors, the assistant decides which tool to call and constructs the appropriate arguments.

Handling tool calls

Tool handlers translate MCP requests into platform-specific API calls:

s.AddTool(searchTool, func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
    searchQuery, _ := request.RequireString("search_query")
    earliestTime := request.GetString("earliest_time", "-24h")
    latestTime := request.GetString("latest_time", "now")
    maxResults := request.GetInt("max_results", 100)

    results, err := client.Search(ctx, searchQuery, earliestTime, latestTime, maxResults)
    if err != nil {
        return mcp.NewToolResultText(fmt.Sprintf("Error: %v", err)), nil
    }

    resultData, _ := json.Marshal(results)
    return mcp.NewToolResultText(string(resultData)), nil
})

Multi-platform support

The same pattern works across observability platforms. For Honeycomb, we expose dataset queries with filters and breakdowns:

queryTool := mcp.NewTool("query_honeycomb",
    mcp.WithDescription("Execute a Honeycomb query with filters and breakdowns"),
    mcp.WithString("dataset", mcp.Description("The dataset to query")),
    mcp.WithString("calculation", mcp.Description("COUNT, AVG, P99, etc.")),
    mcp.WithString("filter_column", mcp.Description("Column to filter on")),
    mcp.WithString("filter_value", mcp.Description("Value to filter for")),
)

For Sentry, in addition to Sentry tools, we enabled direct event lookup from URLs—paste a Sentry link and get the full JSON:

eventTool := mcp.NewTool("get_sentry_event",
    mcp.WithDescription("Get event by URL or ID - paste Sentry event URL to fetch full JSON"),
    mcp.WithString("event_url_or_id", mcp.Description("Sentry event URL or event ID")),
)

Deploying with Heroku Managed Inference and Agents

Heroku Managed Inference and Agents provides an MCP gateway that handles the SSE transport layer, letting you deploy MCP servers as simple STDIO processes.

Create app, attach Add-on, configure, and deploy:

heroku create your-observability-mcp
heroku addons:create heroku-inference:claude-4-5-haiku -a your-observability-mcp
# Set credentials for your observability platform
heroku config:set YOUR_PLATFORM_CREDENTIALS -a your-observability-mcp
# Deploy
git push heroku main

Get the inference token:

heroku config:get INFERENCE_KEY -a your-observability-mcp

Team members add this to their Cursor or Claude configuration:

{
  "mcpServers": {
    "splunk": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://us.inference.heroku.com/mcp/sse",
               "--header", "Authorization:Bearer YOUR_INFERENCE_TOKEN"]
    }
  }
}

Contextualizing error spikes

In a traditional dashboard, you see a red bar. With MCP, you get an answer. We asked the agent, “What error types are most common in production today?” and it returned the ranked list below.

While the distribution might look standard, the AI can help you interpret the security implications. For example, the AI can correlate a rise in AuthenticationFailed errors with specific geographic regions to confirm a brute-force attempt or credential attack, or identify that RateLimitExceeded errors are coming from a single subnet. This context transforms a generic “error count” into actionable security intelligence.

Why AI-native observability changes the game

Connecting your observability stack to your IDE via MCP does more than just save you a few clicks; it keeps you in the flow during an incident. By letting Heroku Managed Inference and Agents handle the proprietary query syntax, any engineer can interrogate production data as easily as a platform specialist. Why this works better:

• Automate complex security audits: We processed 175,000+ events in minutes to clear a suspicious account flag, turning hours of manual log analysis into a single natural language question.
• Bypass the syntax barrier: Engineers ask questions in natural language instead of wrestling with complex SPL or Honeycomb queries. No one needs to remember platform-specific syntax at 2 AM.
• Deploy “Day One” observability: New hires can query production state immediately without mastering your specific observability stack or acronyms. The AI translates intent into execution.
• Debug directly in context: Stop toggling between IDE and browser. By pulling telemetry into your local environment, you keep your mental model intact and fix issues where the code lives..
• Instant root cause analysis: Simply paste a URL to get an immediate root cause analysis with suggested fixes, skipping the manual correlation step entirely.

Extend your AI assistant with any API

Moving from siloed observability tools to an AI-integrated debugging workflow requires bridging the gap between platforms and your IDE. We built this using Heroku Managed Inference and Agents and the Model Context Protocol, and the same pattern works for any API you want to bring into your AI assistant.

Whether it’s observability, internal tools, or customer data — if you can call an API, you can expose it as an MCP tool. Heroku Managed Inference and Agents handles the transport, authentication, and hosting. You focus on the integration.

What will you build? Get started with Heroku Managed Inference and Agents

The post Building AI-Powered Observability with Heroku Managed Inference and Agents appeared first on Heroku.

Today, we are thrilled to announce the General Availability (GA) of the Heroku GitHub Enterprise Server Integration.

For our Enterprise customers, the bridge between code and production must be more than just convenient. It must be resilient, secure, and governed at scale. While our legacy OAuth integration served us well, the modern security landscape demands a shift away from personal credentials toward managed service identities.

Why switch to the GitHub Apps integration?

This new integration is built on GitHub Apps, moving beyond the limitations of personal OAuth tokens to provide a more robust connection for mission-critical pipelines.

• Decoupled authentication: Historically, if the developer who set up a pipeline left the organization, the deployment would break. With this integration, the GitHub App acts as its own identity. Your CI/CD pipelines remain stable regardless of personnel changes.
• Granular security: GitHub Apps offer superior permission control compared to broad OAuth scopes. You can allowlist specific repositories and define exactly what Heroku can see and do.
• Zero service accounts: You no longer need to manage and pay for a separate “bot user” to act as a service account. The GitHub App acts on its own behalf, reducing overhead and security surface area.

Strategic benefits for DevOps teams

By moving to this integration, you unlock the full power of Heroku Flow for your private GitHub Enterprise Server instances:

1. Enhanced CI/CD automation: Seamlessly link your GitHub Enterprise repositories to Heroku Pipelines to orchestrate the flow of code from staging to production. Ensure that your GitHub Actions pass successfully before any code is automatically deployed, maintaining a high bar for production stability.
2. Review apps for every PR: Give your stakeholders and QA teams instant, isolated environments to test feature branches, fully integrated within your GitHub Enterprise Server firewall.
3. Repeatable “golden paths”: When combined with Terraform, you can now programmatically provision Heroku Apps that are automatically linked to your Enterprise repos via a secure, organization-level handshake.
4. Enterprise governance: Admins gain a “single pane of glass” view in the Heroku Enterprise Account settings to see all authorized organizations and manage repo access across the entire fleet of applications.

Getting started

The integration is available today for all Heroku Enterprise customers. Because this is an organization-level change, we recommend a phased rollout:

• Step 1: Enable for testing. Reach out to Heroku Support to enable the feature for a specific test team.
• Step 2: Connect. Navigate to your Enterprise Account Settings tab to link your GitHub Enterprise Server URL.
• Step 3: Reconfigure. Update your existing pipelines to use the new connection.

For a step-by-step walkthrough, including prerequisites and limitation details, visit our official Dev Center documentation.

The post Heroku and GitHub Enterprise Server: Stronger Security, Seamless Delivery appeared first on Heroku.

Today, Heroku is transitioning to a sustaining engineering model focused on stability, security, reliability, and support. Heroku remains an actively supported, production-ready platform, with an emphasis on maintaining quality and operational excellence rather than introducing new features. We know changes like this can raise questions, and we want to be clear about what this means for customers.

There is no change for customers using Heroku today. Customers who pay via credit card in the Heroku dashboard—both existing and new—can continue to use Heroku with no changes to pricing, billing, service, or day-to-day usage. Core platform functionality, including applications, pipelines, teams, and add-ons, is unaffected, and customers can continue to rely on Heroku for their production, business-critical workloads.

Enterprise Account contracts will no longer be offered to new customers. Existing Enterprise subscriptions and support contracts will continue to be fully honored and may renew as usual.

Why this change

We’re focusing our product and engineering investments on areas where we can deliver the greatest long-term customer value, including helping organizations build and deploy enterprise-grade AI in a secure and trusted way.

The post An Update on Heroku appeared first on Heroku.

If you’ve built a RAG (Retrieval Augmented Generation) system, you’ve probably hit this wall: your vector search returns 20 documents that are semantically similar to the query, but half of them don’t actually answer it.

A user asks “how do I handle authentication errors?” and gets back documentation about authentication, errors, and error handling in embedding space, but only one or two are actually useful.

This is the gap between demo and production. Most tutorials stop at vector search. This reference architecture shows what comes next. This AI Search reference app shows you how to build a production grade enterprise AI search using Heroku Managed Inference and Agents.

Why two-stage retrieval

Vector embeddings are coordinates in high dimensional space. Documents close together share semantic meaning. Semantic proximity is a false proxy for accuracy; a document can be ‘close’ in vector space but fail to provide a factual answer. You need a second stage where a reranking model scores each one against the actual query. It asks: “Does this document answer this question?” rather than “Is this document about similar things?”

The difference in result quality is significant. This reference implementation shows how to wire it up and how to make it optional when latency matters more than precision.

Architecture overview

The system consists of two primary pipelines:

1. Indexing pipeline: URL → Crawl → Chunk → Embed → pgvector
2. Query pipeline: Question → Embed → Vector Search → Rerank → Claude → Answer

Heroku services

Streamlining the stack: Unified provider setup

const heroku = createHerokuAI({  
  chatApiKey: process.env.HEROKU_INFERENCE_TEAL_KEY,  
  embeddingsApiKey: process.env.HEROKU_INFERENCE_GRAY_KEY,  
  rerankingApiKey: process.env.HEROKU_INFERENCE_BLUE_KEY,  
});

Indexing: Getting documents in

Crawling real-world sites

Documentation sites are messy. Naive scraping often extracts more navigation links than actual content. The crawler uses a simple heuristic to detect junk:

function isLikelyJunkContent(content: string, htmlLength: number): boolean {  
  // If HTML is huge but text is tiny, it's likely boilerplate  
  if (htmlLength > 100000 && content.length < htmlLength * 0.05) return true; const navPatterns = ['sign in', 'login', 'menu', 'pricing']; // If the start of the doc is stuffed with nav links return navPatterns.filter(p => content.slice(0, 500).includes(p)).length >= 4;  
}

Chunking at natural boundaries

Documents are split into 1000 character chunks with 200 characters of overlap. To avoid losing meaning, we prioritize splitting at paragraph or sentence breaks.

Batch storage with pgvector

The unnest function allows inserting hundreds of chunks in a single SQL query:

  INSERT INTO chunks (pipeline_id, url, title, content, embedding)  
  SELECT   
    ${pipelineId}::uuid,   
    unnest(${urls}::text[]),  
    unnest(${titles}::text[]),   
    unnest(${contents}::text[]),  
    unnest(${embeddings}::vector[])

Retrieval: The two-stage pattern

Stage 1: Vector search

Retrieve the top 20 chunks by cosine similarity. This is fast and scales well in Postgres.

  SELECT content, 1 - (embedding <=> ${vector}::vector) as similarity
  FROM chunks
  ORDER BY embedding <=> ${vector}::vector
  LIMIT 20

Stage 2: Semantic reranking

Pass those 20 candidates to a reranking model. Rerankers use a cross encoder architecture, processing the query and document together to score relevance accurately.

const reranked = await rerankModel.doRerank({  
  query,  
  documents: { type: "text", values: chunks.map(c => c.content) },  
  topN: 5  
});

Streaming: Responsive UX

RAG involves multiple steps (Embed → Search → Rerank → Generate). To prevent a “blank screen,” use Server Sent Events (SSE) to stream progress:

send("step", { step: "embedding" });
send("step", { step: "searching" });
send("step", { step: "reranking" });
send("sources", { sources }); // Show sources while LLM generates

for await (const chunk of streamRAGResponse(message, context)) {
  send("text", { content: chunk });
}

Conclusion: Deploy the reference app

Moving from a demo to a production grade RAG system requires bridging the gap between similarity and relevance. This architecture provides a battle tested foundation using Heroku Managed Inference and Agents and pgvector to ensure your search results actually answer user questions. Deploy the reference chatbot today to see how two-stage retrieval transforms your documentation search.

The post Building AI Search on Heroku appeared first on Heroku.

Today, we are announcing the general availability of reranking models on Heroku Managed Inference and Agents, featuring support for Cohere Rerank 3.5 and Amazon Rerank 1.0.

Semantic reranking models score documents based on their relevance to a specific query. Unlike keyword search or vector similarity, rerank models understand nuanced semantic relationships to identify the most relevant documents for a given question. Reranking acts as your RAG pipeline’s high-fidelity filter, decreasing noise and token costs by identifying which documents best answer the specific query.

Implement two-stage retrieval with the Heroku Rerank API

The Heroku Managed Inference API is designed to be compatible with the Cohere format. Integrate reranking into your existing RAG (retrieval augmented generation) stack by sending a request to the /v1/rerank endpoint.

To get started, provision a model via the Heroku CLI:

heroku ai:models:create -a your-app-name cohere-rerank-3-5 --as RERANK

Once the model is provisioned, you can set your environment variables and implement reranking with a simple request. In this example, we verify which technical documents best answer a query about database optimization:

const response = await fetch(`${process.env.RERANK_URL}/v1/rerank`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.RERANK_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    model: process.env.RERANK_MODEL_ID,
    query: 'How do I optimize database connection pooling?',
    documents: [
      'Connection pooling reduces overhead by reusing existing database connections.',
      'You can monitor application performance using built-in metrics and logging tools.',
      'Set max pool size based on your dyno count to prevent connection exhaustion.',
      'Regular database backups are essential for disaster recovery planning.'
    ],
    top_n: 2
  })
});

const { results } = await response.json();
console.log(results);
/*
[
  { index: 0, relevance_score: 0.5948578715324402 },
  { index: 2, relevance_score: 0.42105236649513245 }
]
*/

Analyzing reranker relevance scores

The rerank endpoint returns a comprehensive result object that allows you to map scores back to your original data. Each item in the results array contains an index, which represents the original position of the document in the input array, and a relevance_score, which is a normalized float where higher values indicate better alignment with the query. This structure allows teams to set strict quality thresholds, only passing information to the AI agent if the reranker confirms it is highly relevant.

Top-N context filtering for accuracy and reduced cost

The top_n parameter allows you to limit the number of results returned. This is particularly useful for retrieving only the most relevant documents to keep your context window clean and reduce inference costs. If not specified, the API will return scores for all provided documents.

Regional availability and limits

To support global performance and data residency requirements, these models are available in both US and EU regions. Performance is managed through specific rate limits and transparent pricing models:

• Cohere Rerank 3.5 supports up to 250 requests per minute at $2.00 per 1,000 queries.
• Amazon Rerank 1.0 supports up to 200 requests per minute at $1.00 per 1,000 queries.

Next steps

By bringing managed reranking to Heroku, we are giving developers the tools to build enterprise-grade search and retrieval without the overhead of managing infrastructure. Visit the Heroku Managed Inference Documentation for full technical specifications and implementation guides.

The post Optimize Search Precision with Reranking on Heroku AI appeared first on Heroku.

This month marks significant expansion for Heroku Managed Inference and Agents, directly accelerating our AI PaaS framework. We’re announcing a substantial addition to our model catalog, providing access to leading proprietary AI models such as Claude Opus 4.5, Nova 2, and open-weight models such as Kimi K2 thinking, MiniMax M2, and Qwen3. These resources are fully managed, secure, and accessible via a single CLI command. We have also refreshed aistudio.heroku.com, please navigate to aistudio.heroku.com from your Managed Inference and Agents add-on to access the models you have provisioned.

Whether you are building complex reasoning agents or high-performance consumer applications, here’s what’s new in our platform. All of the open-weight models you access on Heroku are running on secure compute on AWS servers. Neither Heroku nor the model provider has access to your data and it is not used in training.

Expanding Heroku’s AI catalog with new state of the art models

Claude 4.5 models

We now support the full Claude 4.5 family in both US and EU regions, replacing the prior Claude 3 models which are scheduled for depreciation in January of 2026.

• Claude Opus 4.5: Designed for deep reasoning, complex task orchestration, and long-horizon planning. Recommended for demanding agentic workflows.
• Claude Sonnet 4.5: Balanced model for enterprise workloads, coding, and analysis.
• Claude Haiku 4.5: Low-latency model for high-volume tasks and classification.

Open-weight models

We have added several open-weights models to Heroku Managed Inference and Agents.

• Kimi K2 Thinking: Specialized for chain-of-thought processing, writing, and reasoning tasks.
• MiniMax M2: optimized for creative generation, roleplay, and coding agents.
• Qwen3 (235B & Coder 480B): Large models delivering exceptional performance as coding agents.

Nova models

• Amazon Nova 2 Lite: The Nova 2 family is now available, replacing the previous generation. These models provide updated multimodal capabilities and improved price-performance ratios.

Anthropic’s Messages API (Heroku preview)

Heroku now offers preview support for the Messages API format for all Anthropic models on Heroku. The API format is an alternative to the standard chatCompletions API and aligns with the Claude SDKs, enabling direct integration with Claude Code and the Claude Agents SDK.

Technical implementation and authentication

Authentication detail for the v1/messages endpoint, the authentication structure mirrors Anthropic’s standard practice. Set the value of your Heroku add-on’s INFERENCE_KEY as the value for the x-api-key HTTP header in your request.

Quickstart with Anthropic Python SDK

import os
from anthropic import Anthropic
 
inference_url = os.getenv("INFERENCE_URL")
inference_key = os.getenv("INFERENCE_KEY")
inference_model = os.getenv("INFERENCE_MODEL")


client = Anthropic(
    api_key=inference_key,
    base_url=inference_url
)


message = client.messages.create(
    model=inference_model,
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Hello, what should I build today?"}
    ]
)

Key Constraints for Developers

• Beta Features: We do not currently support the anthropic-beta header.
• Claude Code: To ensure compatibility, set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1.
• Scope: The Messages API is exclusively available for Anthropic models.

Performance boost: automatic prompt caching

Heroku now caches system prompts and tool definitions to reduce latency on repeated requests. Prompt caching is enabled by default with no code changes required. Only system prompts and tool definitions are cached; user messages and conversation history are excluded and automatically expire to ensure privacy and security. You can disable caching for any request by adding a single HTTP header: X-Heroku-Prompt-Caching: false.

Lifecycle updates

Deprecations

• Claude 3 Family: The Claude 3 models (Sonnet 3.5, Sonnet 3.7, Haiku 3, and Haiku 3.5) will be deprecated as of Jan 30th, 2026. Workloads should migrate to the Claude 4.5 family.
• Nova 1st Gen: will be deprecated as of Feb 28th, 2026 in favor of Nova 2.
• Model Fallback: We are working on a default model fallback mechanism where if your model is deprecated, you’ll automatically switch over to a similar more recent model in the same family of models.

Heroku AI PaaS: Accelerating AI Development

This release brings state-of-the-art reasoning and efficient open-weight models to the Heroku platform. With the addition of prompt caching you can now optimize latency with minimal configuration. We recommend validating your applications with the Claude 4.5 and Nova 2 families ahead of the upcoming deprecation cycle. We would love to hear your feedback and feature requests, please reach out to [email protected].

The post Heroku AI: Accelerating AI Development With New Models, Performance Improvements, and Messages API appeared first on Heroku.

Modern Continuous Integration/Continuous Deployment (CI/CD) pipelines demand machine-to-machine authorization, but traditional web-based flow requires manual steps and often rely on static credentials; a major security risk. Heroku AppLink now uses JWT Authorization to solve both: enabling automated setup and eliminating long-lived secrets.

In today’s evolving threat landscape, security attacks increasingly exploit systems that rely on long-lived access tokens or static credentials. If these credentials are compromised—for instance, if they are stolen from a configuration file or environment variable—attackers can reuse them for persistent, unauthorized access to sensitive data and systems. This vulnerability creates a major security risk that has recently impacted third-party applications across the industry.

Heroku AppLink is designed to deliver a modern, robust security posture by directly tackling this crucial vulnerability. With AppLink, you can secure your microservice integrations by moving away from storing and managing long-lived secrets. The architecture is simple and powerful: AppLink provides your microservice with on-demand tokens on demand. This significantly reduces the window of opportunity for an attacker because there is effectively nothing for them to steal or replay to gain long-term access. By switching to dynamic, on-demand credentials, you ensure your Salesforce data is protected in a microservice environment.

The shift: Why CI/CD demands JWT-based authorization

Historically, setting up the required authorization—establishing a trusted identity for your Heroku code to interact with Salesforce—relied solely on a web-based OAuth flow. While secure, this method required manual steps and posed a significant challenge for modern, automated deployment pipelines.

To enable true machine-to-machine communication, we’ve extended AppLink with JWT authorization, eliminating the manual steps required by traditional OAuth flows. This expands on the security model already in place, providing a secure, managed boundary between Salesforce and Heroku. Responding directly to feedback from our valued customers and partners who increasingly sought to automate their CI/CD pipelines, we have significantly enhanced AppLink to simplify this critical setup.

What is AppLink, and How JWT Authorization Works

Heroku AppLink is a secure managed boundary and service that fundamentally simplifies how you connect your Heroku microservices with your Salesforce org. It is specifically designed to deliver more robust security by moving away from storing and managing long-lived secrets. The architecture provides your microservice with on-demand tokens on demand, reducing the window of opportunity for an attacker to steal credentials or execute a replay attack. For more examples check out this article by Andy Fawcett, Heroku Alumni and veteran Salesforce MVP.

AppLink provides two distinct modes for secure authentication to accommodate various integration scenarios, from user-driven applications to automated background processes.

Web-based OAuth flow

This method is the standard for user-driven applications (like a Salesforce AppExchange app) where an end-user is present to log in and grant explicit, delegated access. While secure, this flow requires manual browser interaction and is not suitable for headless, automated deployment pipelines that require true machine-to-machine authentication.

JWT-based authorization (JSON web token)

This new option directly addresses the need for automation, and is highly recommended for server-to-server communication where a secure integration is essential. It allows you to seamlessly integrate the AppLink authorization setup into your CI/CD pipeline. The utilization of JWT authorization provides a robust and highly secure mechanism for authentication and authorization. JWTs are self-contained, digitally signed tokens, which allow your Heroku app to securely assert its identity and permissions when interacting with Salesforce APIs without needing to transmit credentials repeatedly. This approach is highly recommended for server-to-server communication where a seamless and secure integration is paramount.

Headless invocation of Salesforce agent

A headless invocation of Salesforce Agent is an available option for scenarios where the Heroku application needs to perform actions on behalf of a user or leverage the contextual capabilities of the Salesforce platform without a traditional user interface flow. This method enables the Heroku service to programmatically access and interact with Salesforce Org functionalities, such as leveraging Agentforce and pre-configured topics, thereby enhancing your Heroku application with advanced Agentforce capabilities.

Secure microservices and CI/CD automation with AppLink

For developers and the IT leaders supporting them, the enhancement of AppLink with JWT authorization delivers two non-negotiable requirements for the connected enterprise.

• Consistent automation for Continuous Delivery: You can now eliminate manual steps and ensure a consistent, repeatable deployment process within your CI/CD pipeline.
• Defense against credentials theft: By leveraging JWTs and on-demand tokens, your application gains a more secure mechanism for communication.

To get started with AppLink’s new JWT authorization features and learn how to implement them in your microservices, check out the AppLink Documentation and the JWT Authorization Setup Guide.

The post Heroku AppLink: Now Using JWT-Based Authorization for Salesforce appeared first on Heroku.

We’re excited to announce a significant enhancement to how Heroku Enterprise customers connect their deployment pipelines to GitHub Enterprise Server (GHES) and GitHub Enterprise Cloud (GHEC). The new Heroku GitHub Enterprise Integration is now available in a closed pilot, offering a more secure, robust, and permanent connection between your code repositories and your Heroku apps.

This integration removes the final barrier preventing large enterprise customers from accessing our core continuous delivery features. By enabling a secure, permanent, app-based service identity, this integration now fully supports the use of Heroku Pipelines for automated, safe deployments and instantly accessible Review Apps for every feature branch. This ensures that developers at the world’s largest companies can finally utilize Heroku’s best-in-class workflow—deploying code consistently, automatically, and confidently from their preferred industry-standard version control system, all without being blocked by complex enterprise security or personnel turnover issues.

Scaling delivery: moving beyond personal credentials

Historically, connecting Heroku to GitHub Enterprise Server (GHES) and GitHub Enterprise Cloud (GHEC) relied on individual user credentials, typically in the form of Personal OAuth Tokens. While functional, this method presents critical friction for large organizations:

• Security mandates: Personal tokens often have broad permissions and conflict with stringent enterprise policies that demand a least privilege access model.
• Operational risk: If the specific user who set up the deployment pipeline leaves the organization or has their access revoked, the entire CI/CD process breaks down. This risk introduces fragility into mission-critical workflows.
• Maintenance burden: IT teams are forced to create and maintain separate “service accounts” or bot users purely to manage the connection, adding unnecessary complexity.

Heroku GitHub Enterprise Integration: dedicated service identity via GitHub App

This new integration is the recommended, next-generation method for connecting your Heroku Enterprise account to your organization’s GitHub environment (whether GitHub Enterprise Server or GitHub Enterprise Cloud).

Instead of relying on an individual user’s credentials (the traditional personal OAuth tokens) this feature uses a dedicated GitHub App. The GitHub App acts as a service identity, allowing Heroku to interact with your repositories on its own behalf.

This shift in authentication provides crucial advantages for enterprise security and stability by decoupling your deployment process from any single user account.

Key benefits of Heroku GitHub Enterprise Integration

This new architecture addresses critical enterprise needs, providing major improvements over the previous Heroku GitHub Deploys method:

Enhanced security and granular control

Unlike personal OAuth tokens, which grant access based on a user’s role, the integration leverages the inherent security model of GitHub Apps:

• Decoupled authentication: The GitHub App acts as a resilient, dedicated service identity, allowing Heroku to interact with your repositories on its own behalf. This decouples your deployment process from any single user account.
• Least privilege: You gain granular control over the permissions granted to Heroku, ensuring the integration can only access the specific repositories and perform the necessary deployment actions.

Deployment stability and team resilience

Increased operational stability for enterprise-grade application development.

• No pipeline breakage: Because the GitHub App owns the connection, your continuous integration and delivery (CI/CD) pipelines will not break if the original configuring user leaves your organization or has their access revoked. This ensures business continuity regardless of personnel changes.
• Zero service accounts: This integration automatically serves the function of a service account , eliminating the need to create and maintain a separate bot user for connectivity.

Unlocking the Full Power of Heroku Continuous Delivery

By establishing this robust, resilient service identity, the integration ensures that core continuous delivery features function reliably for both GitHub Enterprise Cloud (GHEC) and GitHub Enterprise Server (GHES) organizations:

• Full Heroku pipelines functionality: Core features like automated deploys and environment promotions now function seamlessly and reliably. You can consistently deploy code automatically and confidently from your preferred version control system.
• Instantly accessible Review Apps: Every feature branch now instantly receives an accessible Review App. This enables instant, isolated testing for QA and product managers, accelerating your time-to-market.
• Consistent support for all enterprise environments: The integration fully supports both on-premises GHES and the cloud-based GHEC.

This means developers at the world’s largest companies can finally utilize Heroku’s best-in-class workflow.

Take the next step: Try the new GitHub integration

The new Heroku GitHub Enterprise Integration is now available in a closed pilot, however, we would be happy to add your organization before GA. Contact [email protected] to request the pilot.

Organizations that use GitHub Enterprise Server (GHES) or GitHub Enterprise Cloud (GHEC) and are looking to achieve superior security, operational stability, and full access to Heroku’s Continuous Delivery features are the best matches for participation in this pilot.

The post Heroku GitHub Enterprise Integration: Unlocking Full Continuous Delivery for Enterprise Customers appeared first on Heroku.

For modern enterprises building cloud-native applications, success hinges on achieving maximum development velocity at every scale. Infrastructure as a Service (IaaS) providers like AWS provide hundreds of services with the unmatched reliability and scale needed for enterprise infrastructure, but they can require significant effort and expertise for organizations to be effective and efficient. To achieve true agility, development teams turn to a Platform as a Service (PaaS) like Heroku to streamline the path to production and beyond.

Sophisticated enterprises focus their expertise on building unique business value versus undifferentiated heavy lifting. Their unique apps and services that satisfy customers, improve business productivity, and gain a competitive edge. These businesses want to empower their teams with powerful tools to build great apps but not add to their developers’ cognitive load – maximizing time spent on building and optimizing apps and the customer experience. Together Heroku and AWS provide the best of both worlds – robust and powerful infrastructure services, curated together in a simplified experience that is integrated, automated, and optimized for developers and applications. The goal is speed of innovation with enterprise reliability and trust.

Speed, focus, and accelerated innovation: How Salesforce cut approval time by 90%

At Salesforce, our DET team has a saying “An IT dollar is a very expensive dollar” and that guides them in how engineers spend their time on employee-facing technology initiatives. They use Heroku to simplify how they build, deploy, and maintain five major applications that serve over 76,000 employees. These apps are created as a secure, shared service that can be called by both human users via Slack and AI agents via Agentforce. The integration between systems is secured by Heroku AppLink and ensures agents and humans only access authorized data and that tokens are managed securely.

• Strategic focus on code: Heroku is a fully managed PaaS, which means it handles the operational burden of the underlying infrastructure, including OS patching, security updates, and routine maintenance. For the Salesforce team, the choice was not about avoiding AWS, but about leveraging it effectively. It was about focusing on code rather than configuration for high-value, business enablement applications. This frees developers to concentrate solely on the application’s business logic, leading to improved productivity and reducing DevOps toil.
• Rapid deployment: Heroku’s developer-centric experience allows for rapid deployment directly from Git repositories with a simple git push heroku main. This streamlined process accelerates the time-to-value for new applications, compressing a multi-week deployment process into minutes and enabling fast iteration and continuous delivery.
• Instant provisioning of managed services: The PaaS approach allows teams to instantly provision services like Apache Kafka on Heroku, Heroku Key-Value Store, and Heroku Postgres. This eliminates the need for a large, specialized DevOps team to manually set up, configure, and maintain these complex data systems on the IaaS layer.

The transformative results of rapid application innovation can be felt across Salesforce. The Slack Approvals app, which functions similarly to the Deal Desk example, cut expense approval time from two days to just two hours, saving a cumulative 3,310 years in waiting time. Furthermore, the Task Hub app, which manages tasks like license confirmations, helped the licensing team recover $2 million in unused software licenses. This proves that when the developer experience is improved and DevOps friction is reduced with Heroku, massive enterprise ROI is achieved.

Enterprise-grade security and compliance on Heroku

Heroku provides the application-level security and compliance layer that simplifies life for developers in regulated industries.

• Extending the Salesforce Trust Boundary: Heroku AppLink is the key to maintaining security and trust in the connected enterprise, facilitating secure integration with Salesforce clouds and Agentforce.
• Advanced isolation for regulated data: For the sensitive data and highly regulated industries (like healthcare or financial services), Heroku offers dedicated, network-isolated environments :
  • Heroku Private Spaces provide a dedicated runtime environment within a specified region, enabling secure, low-latency communication with corporate systems and protecting sensitive data and transactions.
  • Heroku Shield Private Spaces offer an enhanced layer of security and trust controls necessary to meet compliance standards like HIPAA and PCI-DSS. This set of services includes high-compliance instances of Heroku Postgres, Heroku Connect, and Private Dynos with features like encryption at rest for ephemeral data and strict TLS enforcement. This greatly simplifies the complexities of regulatory compliance for development teams.
  • Amazon Virtual Private Cloud (VPC) is recommended for maximum control over complex infrastructure, where appropriate for business or performance reasons.
• Granular access control: Heroku Enterprise features enable detailed management of user access and permissions through Heroku Teams. This allows organizations to grant fine-grained permissions to team members on a per-app basis, supporting the principle of least privilege.

Polyglot advantage: flexibility and an integration ecosystem for developers

For hands-on developers and architects, the true freedom of the Heroku platform lies in its flexibility and expansive integration ecosystem.

• Polyglot support and language choice: Heroku is a polyglot platform, offering first-class support for a wide range of popular open-source languages, including Node.js, Ruby, Java, .NET, Python, Go, PHP, Scala, and Clojure. This allows development teams to choose the absolute best language or framework for each microservice, maximizing both productivity and application performance.
• Heroku Elements Marketplace: The Heroku Elements ecosystem is a key productivity multiplier. It provides developers with:
  • Heroku Add-ons: A vast marketplace of over 200 fully managed, third-party cloud services (for logging, caching, monitoring, security, and more) that can be integrated with a single click or command. The Add-on is instantly provisioned, and the configuration is attached to the application via an environment variable. This allows teams to leverage best-in-class, fully supported services from ecosystem partners without performing complex manual integration work.
  • Heroku Buildpacks: These allow developers to easily extend the platform to support specific languages or frameworks, or even combine multiple languages within a single project for distinct front-end and back-end components.

AI-assisted development and modern observability

The Heroku AI PaaS architecture is future-proofed for the age of AI and designed to complement and accelerate existing AWS investments. While traditional Twelve-Factor development methods laid the foundation for initial success, today, AI-assisted tools are making the deployment of these cloud-native architectures significantly faster.

• AI-assisted creation: With Heroku Vibes, engineering and business teams can generate the full-stack code for an application like the Deal Desk simply by describing it in natural language. Once deployed, Agentforce Vibes inside Salesforce can automatically generate the necessary Flow to consume the new Heroku service.
• Observability and managed scale: For high-volume, standard enterprise workloads like API services for AI agents, Heroku provides effortless, managed scaling (Dynos). As these agents scale and begin hitting your Heroku services thousands of times an hour, the next-generation Heroku environment, Fir, provides native support for OpenTelemetry. This open-standard integration is critical for architects to monitor performance and gain deep visibility into the traces, metrics, and logs of these high-volume, modern workloads. For highly specialized, custom AI model training that requires raw GPU access, the AWS IaaS layer remains the ideal choice for its full customizability.

Data scalability and enterprise integration

Heroku helps teams realize additional value when apps are securely integrated with existing systems and supported by resilient data services.

• Advanced data scalability: To support demanding data workloads, Heroku ensures that data storage scales as effortlessly as the services consuming it. This is why Heroku is piloting Heroku Postgres Advanced, ensuring the database scales as efficiently as the AI agents consuming its data.
• Fast, reliable Salesforce integration: Heroku facilitates enterprise data integration through Heroku Connect, for two-way synchronization between your Heroku Postgres database and the core Salesforce org. Accelerated Polling can listen to Salesforce Change Data Capture (CDC) to accelerate the polling frequency for your key objects. This capability is essential for connecting custom Heroku services that handle high transaction volumes with the central source of truth in the Salesforce Platform.

The definitive architecture for the AI-powered enterprise

Heroku AI PaaS adds power and flexibility to your application architecture strategy with a streamlined developer and operator experience leveraging the reliability and scale of AWS infrastructure and deep integration to the Salesforce portfolio – the ultimate accelerator for agentic enterprise innovation.

The combination achieves three critical, unified goals for IT leaders, architects, and developers:

• Accelerated agility: It provides developers with the polyglot freedom and fully managed services (PaaS) to focus solely on business logic for rapid deployment, scalability, and easy maintenance. And reserves configuration workloads on the IaaS layer for the business’s most nuanced services and applications.
• Secure extension for Salesforce orgs: It ensures that every custom application and AI service, regardless of complexity, operates within the extended Salesforce Trust Boundary, backed by features like Heroku AppLink and Heroku Shield. This is the non-negotiable layer of security and compliance required for the connected enterprise.
• AI future-proofing: It offers the native OpenTelemetry support (via Heroku Fir) and the scalability (via Heroku Postgres Advanced) necessary to reliably manage high-volume, performance-sensitive workloads generated by the next generation of custom AI agents.

Whether the goal is optimizing complex human workflows or building the custom services that power sophisticated AI agents, enterprise success requires a strategic division of labor. Leaning in to Heroku’s developer velocity gets you AWS’s infrastructure scale based on business requirements and desired outcomes affords IT leaders agility at scale.

Special Offer: Buy Heroku through AWS

U.S. AWS Enterprise Discount Program (EDP) customers, you can buy Dynos, Heroku Private Spaces, Heroku Postgres, Heroku Key-Value Store, Apache Kafka on Heroku, and Heroku Connect through AWS Marketplace Private Offers.

Get in touch with a Heroku sales representative and let them know you’re interested in buying Heroku through AWS.

The post PaaS + IaaS: Heroku and AWS for Cloud-Native Enterprise Agility appeared first on Heroku.

Heroku is launching automatic prompt caching starting December 18, 2025. Prompt caching delivers a notable, zero-effort performance increase for Heroku Managed Inference and Agents. Enabled by default, this feature is designed to deliver significantly faster responses for common workloads. We have taken a pragmatic approach and currently only enabled this to cache system prompts and tool definition, and not user messages or conversation history. You can disable caching for any request by setting X-Heroku-Prompt-Caching: false.

What is prompt caching and how does it speed up AI inference?

Prompt caching is an optimization that speeds up inference by securely caching and reusing the processed components of your requests for system prompts and tool definitions.
For applications involving agents, a large portion of the request remains static. Instead of reprocessing this content on every call, Heroku can now reuse the processed result from a secure cache. Currently, to simplify billing, we do not charge for cache writes or pass on the difference for cache hits as we evaluate the system.

How prompt caching works on Heroku

When your application sends an AI request, Heroku intelligently adds cache checkpoints to system prompts or tool definitions before securely passing them to the model.

1. First Request: A request with a new, substantial prompt (meeting a token minimum) is processed normally, and its results are securely cached.
2. Similar Requests: Subsequent requests with the same initial prompt or tools reuse the cached components, skipping most of the computation for a faster response.
3. Automatic Expiration: The cache automatically expires after five minutes of inactivity.

This mechanism applies to all supported models, but caching only occurs when content meets the minimum token threshold, focusing performance gains where they add the most value.

Supported models and caching details

Caching behavior is model-specific, as different models have different thresholds and capabilities (such as caching tool definitions).

Model	Vendor	System Prompts	Tools	Minimum Tokens Required
Claude Sonnet 4.5	Anthropic			1,024
Claude Haiku 4.5	Anthropic			4,096
Claude Sonnet 4	Anthropic			1,024
Claude Sonnet 3.7	Anthropic			1,024
Claude Haiku 3.5	Anthropic			2,048
Nova Pro	Amazon			1,000
Nova Lite	Amazon			1,000

Enterprise-grade security and privacy

Privacy and Security is fundamental to Heroku Managed Inference and Agents. Our prompt caching feature is built on proven security infrastructure, protecting your data with enterprise-grade measures like cryptographic hashing and automatic expiration. The cache exists only in secure memory, not persistent storage, ensuring robust protection. Caching is only enabled for cache system prompts and tool definition and not user messages or conversation history.

How to disable prompt caching on sensitive workflows (opt-out)

While prompt caching offers significant benefits, you retain full control. You can disable caching for any request by adding a single HTTP header:

X-Heroku-Prompt-Caching: false

This is useful for highly sensitive workflows or for performance testing. You have the flexibility to use this feature as you see fit.

Build faster agents

Prompt caching is another step in making Heroku Managed Inference and Agents easy, secure, and efficient for building AI applications. It provides a zero-effort performance boost, transparently accelerating your applications without changing your logic.

We’re excited to see this speed improvement enhance the workflows, document processing, and code-generation tools you’re building on Heroku.

The post Faster Agents with Automatic Prompt Caching appeared first on Heroku.

We are thrilled to announce that the Heroku Terraform Provider is now fully optimized for Fir. This significant milestone allows developers to manage our next-generation platform using Infrastructure as Code (IaC).

Fir is built on a modern foundation of cloud-native, open-source standards (Kubernetes) while maintaining the legendary Heroku developer experience. By combining the declarative power of Terraform with the advanced capabilities of Fir, you can now manage your applications with unprecedented control, consistency, and scalability.

Did you know?

Heroku’s Terraform Provider is extremely popular. First released eleven years ago, to date it has:

• 9.6 million total downloads
• 1.7M downloads this year
• 130,000+ downloads this month
• 50,000+ downloads this week

Needless to say, Terraform is an essential tool for us here at Heroku and our ability to build, test, and release our platform features efficiently.

IaC for the future: Why Terraform is essential for the Fir Generation

The move to Fir is a generational leap forward, addressing the increasing demand for flexibility, openness, and scalability from enterprise organizations. Using Terraform alongside this new architecture is crucial for realizing its full potential:

• Industry Standard IaC: With a market share estimated to be over 70% in the Infrastructure as Code (IaC) space, Terraform is the language of modern cloud infrastructure. The Heroku provider allows you to define every resource, from apps to spaces, using a simple, version-controlled configuration.
• Kubernetes Benefits, Heroku Simplicity: Fir is built on Kubernetes (K8s) under the hood, abstracting away the complexity of K8s while giving you its benefits: enhanced scaling limits, better resource allocation, and a foundation for future features. Terraform ensures that even as the platform leverages Kubernetes, your provisioning remains simple—defining the Heroku resources without needing to touch a single line of YAML.
• Unified Tooling: If you manage infrastructure across multiple cloud providers (like AWS, GCP, or Azure) using Terraform, you can now seamlessly integrate your Heroku Fir environments into that single, unified IaC strategy.

Fir highlights: Cloud-native features managed by Terraform IaC

Fir elevates the Heroku experience by embracing key cloud-native technologies. Using Terraform helps you provision and manage the resources that power these new features:

Terraform resource management: Automate your Fir application workflow

The Heroku Terraform Provider allows you to manage the crucial resources that define your application lifecycle on Fir:

• heroku_app and heroku_space: Provision your applications within the new, enhanced Fir Private Spaces.
• heroku_addon: Automatically provision and configure all necessary databases, caching, and logging add-ons in tandem with your app.
• heroku_pipeline: Define your promotion pathways as code, setting the stage for controlled, automated deployments.
• heroku_config_var: Manage critical environment variables securely and consistently across all your Fir environments.

You can learn more about the full set of options available and see examples on the Heroku Dev Center.

If you have ideas or suggestions to continue enhancing our Terraform Provider, do not hesitate to let us know by reaching out to [email protected].

Get started today!

This is a major step in Heroku’s platform evolution. We encourage all users to explore how Terraform can simplify the management of your new Fir-based applications.
You can find the updated documentation and examples on the Terraform Registry page for the Heroku Provider. Embrace the future of Heroku development with the combined power of Terraform and Fir!

The post Unleash the Power of IaC on Heroku’s Next Generation: Terraform for Fir is Here! appeared first on Heroku.

Summary – What Happened?

Heroku Service Impact

Beginning on October 20th, 2025 07:06 UTC, multiple Heroku services were initially impacted by a database service disruption with our cloud infrastructure provider in the Virginia region. This affected the monitoring, provisioning, networking and availability of cloud infrastructure services that power the Heroku platform.

This outage was a complex, multi-phased event primarily triggered by multiple upstream outages within the cloud infrastructure provider Virginia region, and compounded by Heroku’s single-region control plane architecture and automation failures. The service disruptions can be divided into two distinct phases based on root causes, timeline, and impacts.

Phase 1. Upstream Cloud Infrastructure Provider Database Outage (10/20/2025 06:53 UTC – 09:30 UTC)

During phase 1, Heroku’s cloud infrastructure provider’s database service disruption and subsequent throttling resulted in downstream impacts on Heroku services and some customers, including:

• Postgres, Key-Value Store, and hosted Apache Kafka provisioning delays
• Disruption of Heroku’s App Metrics, Autoscaling, and Threshold Alerting due to the inability to read or write metrics to the metrics backend database
• Degradation of Platform API and control plane operations resulting in failed dyno and app management requests triggered through the CLI and Dashboard
• Common Runtime and Private Space dyno provisioning failures and high latency, impacting Builds, deployments, Release Phase, One-off Dynos, and Continuous Integration

Heroku’s Platform API circuit breaker was triggered to block calls to the Runtime control plane, resulting in failed requests to the dyno and app management endpoints. At 09:30 UTC, the cloud provider announced that initial database recovery was complete. This restored CLI and Dashboard operations, as well as Builds.

Phase 2. Upstream Cloud Infrastructure Provider Networking Outage, Heroku Control Plane Failure, and Final Incident Cleanup (10/20/2025 11:27 UTC – 10/21/2025 03:33 UTC)

Phase 2 began at 11:27 UTC when Heroku identified dyno autoscaling issues on Private Spaces caused by the cloud infrastructure provider’s ongoing database issues. Additionally, Heroku began detecting networking degradation. At 13:21 UTC, the cloud infrastructure provider announced a second major service degradation, this time impacting network routing, including customers’ applications with custom domains. These upstream provider issues, combined with Heroku automation and control plane architectural issues, resulted in multiple downstream impacts to Heroku services and customers. During this phase, some customers may have observed the following:

• The inability to access applications, in particular those using custom domains, resulting in H99 platform errors and 5xx status code errors for client applications
• False positive or delayed Postgres, Key-Value Store, and Kafka database health alerts
  • Before autoremediation was manually disabled, a small subset of customer databases began autofailover and replacement.
• Disruption of App Metrics, Dyno Autoscaling, and Threshold Alerting
• Intermittent failures, and later disruption of dyno and app management operations due to the deteriorating health of the Platform API’s Key Value Store
• Build, deployment, CLI and Dashboard failures
• Release Phase, Continuous Integration, and App Setup failures
• Delay in webhook and event delivery
• Disruption or delays in Connect synchronizations in the Virginia region
• AppLink request delays and disruptions

At 19:11 UTC the provider database degraded failover was manually remediated, the Heroku Platform API recovered, and CLI and Dashboard initiated dyno and app management operations and metrics-driven functionality (App Metrics, Dyno Autoscaling, and Threshold Alerting) began recovering.

Following the Heroku Platform API recovery, a long-tail cleanup effort was undertaken to fully restore Heroku services and mitigate customer impact, including the following activities:

• All queued webhooks were processed and distributed to customer endpoints once network connectivity was restored.
• The technology team assessed and manually corrected partial failover and replacement operations auto-triggered by the loss in network connectivity.
• Control plane instances were cycled to remediate any residual issues from internal database failovers and replacements, restoring dyno provisioning, scaling and cycling operations.
• Re-enabling of Data service auto-remediation

After impact remediation and monitoring was complete for all Heroku services, the incident was resolved on October 21st, 2025 at 03:33 UTC.

Heroku Incident Communications

Some customers expressed concern with the Heroku-specific update cadence and level of detail.

Detailed Timeline of Impacts, Investigation, and Root Cause

Phase 1. Upstream Cloud Infrastructure Provider Database Outage (10/20/2025 06:53 UTC – 09:30 UTC)

October 20th, 2025 06:53 UTC. Heroku engineering was first alerted to failures in writing application and language metrics to Heroku’s cloud infrastructure provider hosted database. This impacted Heroku’s metrics-driven features, including Application Metrics, Dyno Autoscaling, and Threshold Alerting features. At the same time, Heroku Runtime alerts signaled degradation of Heroku’s Platform API and control plane due to the upstream cloud platform provider’s database failure. API requests for dyno management operations, like scaling, stopping and restarting, began to fail or display very high latency.

October 20th, 2025 07:11 UTC. Heroku’s cloud infrastructure provider notified Heroku and their other customers of increased error rates when interacting with specific platform APIs.

October 20th, 2025 07:00 UTC. Heroku’s Postgres, KVS and Apache Kafka Data services experienced significant provisioning latency in the Virginia region. Some customers observed provisioning request delays of up to 4 hours in duration.

October 20th, 2025 07:26 UTC. Dyno provisioning failures due to upstream cloud infrastructure provider database issues resulted in increased latency for Release Phase, Heroku CI, and postdeploy scripts. Some customers observed deployment failures or slow deployments due to slow-running post-deploy scripts.

October 20th, 2025 07:40 UTC. The Heroku Platform API circuit breakers triggered to block requests to the Runtime control plane. Heroku Platform API started returning error messages for the dyno API endpoints and other app endpoints. During this time, some customer requests to obtain dyno information, or stop, start and scale dynos failed and returned a 500 or 503 status code.

October 20th, 2025 07:42 UTC. The first incident-related support ticket was logged from a customer who reported missing metrics in the App Metrics dashboard.

October 20th, 2025 09:00 UTC. Heroku’s Postgres, KVS and Apache Kafka Data services provisioning latency in the Virginia region returned to normal.

October 20th, 2025 09:15 UTC. High request retries were observed for Heroku Runtime. Heroku’s cloud provider outage affected dyno provisioning in Private Spaces apps. New Private Space dynos, including one-off dynos, could not be created. Existing dynos could not be scaled or cycled.

October 20th, 2025 09:30 UTC. Heroku’s cloud infrastructure provider updated their status indicating signs of recovery. Platform API operations were recovered, with CLI and Dashboard operations, as well as Builds, functionality restored. Mitigated services were being closely monitored for signs of stable recovery.

Phase 2. Upstream Cloud Infrastructure Provider Networking Outage, Heroku Control Plane Failure, and Final Incident Cleanup (10/20/2025 11:27 UTC – 10/21/2025 03:33 UTC)

October 20th, 2025 11:27 UTC. Heroku detected autoscaling failures due to the ongoing service disruption of Heroku’s cloud provider database, resulting in the inability for Heroku’s internal metrics aggregating service to query metrics that trigger autoscaling.

October 20th, 2025 12:15 UTC. Alerts for Heroku webhooks signaled increasing queue depth as
Heroku’s platform provider’s networking also degraded. Some customers began to experience disruptions or delays in webhook delivery to customer endpoints, resulting in downstream process delays.

October 20th, 2025 13:21 UTC. Heroku’s cloud infrastructure provider announced a second major service degradation, this time impacting network routing. Some customers with Virginia region apps, particularly those with custom domains, began observing H99 platform errors and 5xx responses on client applications.

October 20th, 2025 13:38 UTC. Heroku’s cloud provider network routing degradation triggered Heroku Connect synchronization performance alerts. Some customers began observing synchronization delays between Salesforce organizations and Heroku Postgres in the Virginia region.

October 20th, 2025 14:55 UTC. Heroku’s Platform API Key Value Store experienced a partial failover, resulting in the inability of Heroku’s Data control plane to accurately determine service health due to Heroku’s cloud provider’s network connectivity issues. Auto-remediation was triggered, resulting in a partial failover. Customers began observing intermittent failures in dyno and app management operations.

October 20th, 2025 15:05 UTC. Heroku’s Data team paused auto-remediation of databases due to the inability to accurately assess the health of existing Data services as a result of the cloud platform vendor’s network disruption. Customers received false-positive database health notifications due to the loss of network connectivity. Prior to the auto-remediation pause, a small subset of customer databases began autoremediation, but for most database customers no action was taken.

October 20th, 2025 16:20 UTC. Alerts were triggered for Heroku’s Credentials Service due to the degraded Heroku Platform API and Credentials Service. AppLink requests failed, and this event signaled a major degradation of the Heroku Platform API.

October 20th, 2025 16:30 UTC. Heroku Platform API degraded due to the partially failed-over Key Value Store. This caused failures of Heroku Builds, Dashboard, and CLI operations.

October 20th, 2025 17:05 UTC. Due to Heroku’s Platform API degradation, Release Phase, Continuous Integration, and deployments failed or stalled.

October 20th, 2025 18:16 UTC. Heroku’s Platform API experienced a near disruption, resulting in failure of most CLI and Dashboard initiated dyno and app management operations. Some customers reported unexpected Dashboard errors.

October 20th, 2025 19:11 UTC. Heroku’s Data team manually corrected the Heroku Platform API’s Key Value Store that was stalled in a partial failover state.

October 20th, 2025 19:18 UTC. The Heroku Platform API began to recover. CLI and Dashboard executed dyno and app management operations began to successfully complete.

October 20th, 2025 19:21 UTC. The Heroku metrics backend that drives App Metrics, Autoscaling, and Threshold Alerting was recovered, enabling the services to resume operations. Metrics gaps remained for the outage period in App Metrics.

October 20th, 2025 20:00 UTC. Heroku Webhooks was fully recovered after network connectivity was restored and the event backlog was cleared. Queued webhooks were processed and sent to customer endpoints.

October 20th, 2025 20:15 UTC. The technology team began a manual clean up of the small subset of customer databases that began autoremediation when the loss of network connectivity triggered automation prior to when autoremediation was disabled. The incomplete database failovers and replacements were caused by the Heroku Platform API outage that left some databases in a partially remediated state. Due to the emergency maintenance situation, some customers did not receive a notification, or received a last minute notification, of the database recovery operation.

October 20th, 2025 20:25 UTC. The technology team began cycling control plane instances to clear residual issues resulting from database failover and and replacement failures.

October 20th, 2025 23:05 UTC. To remediate partially completed database failovers and replacements and ensure services were operational, Data service auto-remediation was paused and unpaused.

October 21st, 2025 00:09 UTC. Heroku control plane instance cycling was completed. Dyno provisioning, scaling, and cycling were restored for Private Spaces and Common Runtime.

October 21st, 2025 03:33 UTC. The recovered Heroku service heightened monitoring period was completed, and the incident was resolved.

Corrective Actions

Areas of Improvement

Our retrospective identified several key areas of improvement:

• In this case, Heroku Platform API and Data control plane circuit breakers intended to insulate the platform from large-scale infrastructure outages did not sufficiently control impact by not triggering early enough.
• The Heroku control plane being located in a single region – the same as the affected region – meant that during the impact timeframe, automated remediation for Data service failures could not proceed without required manual intervention.

During our review, we found opportunities to improve how we communicated during this incident:

• Update cadence did not fully align with expectations.
• Communications did not always provide the level of detail needed to clearly outline customer impact and any recommended actions.

Planned Corrective Actions

To address the root cause findings, Heroku commits to the following corrective actions to help remediate the potential of these issues from occurring in the future:

Short-term

Control Plane Circuit Breakers. To address the delay in triggering the Platform API and Data control plane circuit breakers, we will be immediately working on improving the “circuit breakers” to ensure they trigger in a timely and appropriately scoped manner. This is to improve fault tolerance.

Incident Communications Process Optimization. Improve incident communication consistency by reinforcing existing comms standards for cadence, validated impact, observed behavior, and recommended actions.

Longer-term

Control Plane Resiliency for Data Services. To address the single region Data services control plane vulnerability, we will investigate distributing the observability tooling that the control planes rely on across multiple regions to mitigate false-positive signals in the case of a regional outage. We will also investigate longer term remediation of over-reliance on a single region of our infrastructure provider.

Control Plane Resiliency for Other Platform Services. We will be exploring ways to add additional resiliency for strategic platform components, including the Platform API.

Our commitment to you

We sincerely apologize for the impact this incident caused you and your business. Our goal is to provide world-class service to our customers, and we are continuously evaluating and improving our tools, processes, and architecture to provide our customers with the best service possible.

If you have additional questions or require further support, please open a case via the Heroku Help portal.

The post Incident Review: Intermittent Disruption and Degradation of Heroku Services on October 20, 2025 appeared first on Heroku.

It’s that time of year for .NET when we get a new major version and a bunch of exciting features. .NET Conf 2025 kicked off earlier today, bringing with it the release of .NET 10, as well as ASP.NET Core 10, C# 14, and F# 10. Congrats (and a big thank you) to the .NET team and everyone who helped get .NET 10 out the door.

At Heroku, we believe you should be able to use language and framework releases when they launch, and we prepare accordingly. You can now build and run .NET 10 apps on Heroku, with buildpack support for new SDK features like file-based apps, .slnx solution files, and more.

Migration and support timelines

This year’s release is significant because .NET 10 is the new Long Term Support (LTS) release, which will be supported for three years. This extended support, including regular updates and security patches, makes it the best release for businesses and developers to build on and migrate to, offering a stable foundation with access to the latest features.

With .NET 10 now available, the clock is ticking on previous versions. Both .NET 8 and .NET 9 will reach End of Support on November 10, 2026. In other words, now is a good time to start planning your migration.

We will continue to support .NET 8 and .NET 9 with consistent, timely updates alongside .NET 10. Our .NET support follows the official .NET support policy, and we are fully committed to providing a stable and secure platform for your .NET applications.

Let’s dive into using .NET 10 on Heroku today!

Zero-config deployment with .NET 10 file-based apps

One of the most exciting features in .NET 10 is file-based apps – .NET applications defined in a single C# file without project or solution files, making it easier than ever to deploy .NET apps to Heroku.

For example, here’s a complete ASP.NET Core 10 web application, HelloHeroku.cs:

// Use the new #sdk directive to pull in the ASP.NET Core SDK
#:sdk Microsoft.NET.Sdk.Web

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();  
  
app.MapGet("/", () => "Hello from .NET 10 on Heroku!");

app.Run();

When you push this to Heroku, the platform detects the *.cs file and uses the .NET buildpack. Since there are no solution or project files, the buildpack treats it as a file-based app, installs the latest .NET SDK, builds and publishes the app, detects and configures it as a web application, and deploys it to serve traffic.

The result is a simple, zero-config experience to get you started quickly, ideal for prototyping and developers new to .NET. And there’s more coming – check out the .NET SDK repository to see what the .NET team is working on!

To learn more about what you can do with file-based apps on Heroku today, see our Dev Center documentation.

SLNX: A modern solution for a modern .NET

For decades, .NET developers have used .sln solution files, a proprietary format introduced in 2002 for Visual Studio. Unlike .NET itself, they haven’t changed much since. In a step towards modernization, the .NET 10 SDK is making SLNX the default format. Heroku ensures a seamless deployment experience by fully supporting both formats.

<solution>
    <project path="MyApp\MyApp.csproj"></project>
</solution>

*.slnx files are easier to read and edit, less likely to cause merge conflicts, and support a wider range of workflows and environments, from Linux shells to Visual Studio on Windows. To migrate existing .sln files, run dotnet solution migrate or see the .NET blog announcement for more details.

Heroku CI and the Microsoft Testing Platform

The .NET 10 SDK integrates the Microsoft Testing Platform (MTP) directly in the dotnet test command. Since Heroku CI runs dotnet test by default, your test suite works out of the box after you migrate your apps.

For more control over the test setup and execution, you can specify custom test commands in your app.json.

Ready to migrate? We’re here to help

To support your .NET 10 migration, we’ve updated all our documentation and resources:

• The .NET Getting Started app now runs on .NET 10.
• The ASP.NET Core configuration article includes new guidance for ASP.NET Core 10, including migration away from the now-obsolete IPNetwork and ForwardedHeadersOptions.KnownNetworks APIs (learn more) often used to integrate with Heroku’s router.
• Apps currently using .NET 10 RC builds on Heroku (with TargetFramework set to net10.0) will automatically be built with the stable .NET 10 release on the next git push. You can pin to specific SDK versions using a global.json file.

For teams migrating from earlier versions, the .NET 10 breaking changes documentation covers important upgrade considerations.

Get started today

We can’t wait to see what you build with .NET 10 on Heroku. From new features like file-based apps to the stability of an LTS release, this is a great time to be a .NET developer.

Check out our updated Getting Started with .NET on Heroku guide and please feel free to reach out with any questions or feedback.

The post Heroku Support for .NET 10 LTS: What Developers Need to Know appeared first on Heroku.

Puma 7 is here, and that means your Ruby app is now keep-alive ready. This bug, which existed in Puma for years, caused one out of every 10 requests to take 10x longer by unfairly “cutting in line.”  In this post, I’ll cover how web servers work, what caused this bad behavior in Puma, and how it was fixed in Puma 7; specifically an architectural change recommended by MSP-Greg that was needed to address the issue.

For a primer on keep-alive connections: what they are and why they are critical for low-latency, performant applications, see our companion post Learn How to Lower Heroku Dyno Latency through Persistent Connections (Keep-alive)

Puma 6 Keepalive bug

When all threads are busy, Puma 6 and prior incorrectly allow a new keep-alive request to “cut the line” like this:

In this image, A is the first request, on a keep-alive connection. After A finishes processing, instead of working on request B, Puma 6 (and prior) incorrectly starts working on C, the next request on the same keep-alive connection. This process repeats until either the keep-alive connection has no more requests or a limit (10) of requests served on a single connection is reached.

That means that C and D both “cut the line” in front of B, just because they came on the same keep-alive connection. In the GitHub issue we described this as “letting one keep-alive connection monopolize a Puma thread.” This is bad behavior, but why did it exist in the first place?

You can read the background of how this was identified, reproduced, and reported in Pumas, Routers & Keepalives—Oh my!. It’s also worth mentioning that this high delay only happens when Puma is “overloaded” with more requests than it has threads. This can happen when the system needs more capacity (when web needs to be scaled), or there is a burst of traffic.

Puma 6 broken Pipe(line) Dreams: The Fast Inline Optimization

Keep-alive line-cutting behavior wasn’t intentionally added to Puma 6; rather, it was an accidental byproduct of an optimization for pipeline connections. This bug wasn’t added recently, either. It’s been part of Puma for a long time. The issue has been independently reported several times over the years, but only recently reproduced in a reliable way. First off, what is HTTP pipelining?

HTTP pipelining is when multiple requests are on the same connection and sent at the same time.

In this image, A, B, C, and D all arrive at the same time. A, B, and C are on the same pipeline connection. The previous case, where one connection “cut in line” in front of another, is not happening here. Either C or D must wait 300ms, and both have an equal chance. That explains pipeline connections, but what was the optimization that led to the keep-alive connection problem?

In Puma, any time spent coordinating the state instead of processing a request is overhead. Normally, when a request is finished, the thread pulls a new request from the queue, which requires housekeeping operations like handling mutexes. To reduce that overhead, a loop was added to handle pipeline connections. With this new code, instead of serving the first request and then sending the remainder back through the regular queue, this loop allowed Puma to process all pipelined requests in order on the same thread.

You can see some of the logic in the Puma 6 code comments:

# As an optimization, try to read the next request from the
# socket for a short time before returning to the reactor.
fast_check = @status == :run

By default, this “fast inline” behavior was limited to ten requests in a row via a Puma setting max_fast_inline:

# Always pass the client back to the reactor after a reasonable
# number of inline requests if there are other requests pending.
fast_check = false if requests >= @max_fast_inline &&
  @thread_pool.backlog > 0

This optimization for pipelined HTTP requests made sense in isolation. Unfortunately, this codepath was reused for the keep-alive case, where new requests may be sent well after the first one.

While it’s fair to serve the pipeline requests one after another, it’s unfair to treat all keep-alive requests as if they arrived at the same time as the connection.

New goal:

Goal 1: Requests should be processed in the order they’re received, regardless of whether they came from calling accept on a socket or from an existing keep-alive request.

Puma 7 Fixed Pipelines

Instead of letting a pipeline connection monopolize a single thread, Puma 7 now places pipelined connections at the back of the queue as if the next request arrived right after the first. With this new logic, the pipeline request ordering changes to this:

Now, instead of waiting for all the pipelined connections to finish, D is interleaved. One way to think of this is that instead of racing to see which request finishes last, the connections now race to determine which finishes second. This ordering now applies to keep-alive connections in addition to pipeline connections.

Unfortunately, Puma 6 had another optimization called wait_until_not_full that prevents it from accepting more connections than it has threads. That had to be adjusted to accommodate the ability to interleave keep-alive requests with new connections.

Note: Puma 7.0 turned off the keep-alive “fast inline” optimization, but they were reintroduced in Puma 7.1.0. This reintroduction relies on the addition of a new safeguard that ensures an overloaded server will process connections fairly. You can read more about it in the linked Puma issue: Reintroduce keep-alive “fast inline” behavior: 8x faster JRuby performance.

Puma 6 – Not accepting

To understand the wait_until_not_full optimization, you need to understand how a socket works on a web server.

A socket is like a solid door that a process cannot see through. When a web request is sent to a machine, the connection line is outside that door. When the web server is ready, it can choose to open that door and let one connection inside so it can start to process it. This is called the “accept” process or “accepting a connection.”

Puma uses an accept loop that runs in parallel to the main response-serving-threadpool. The accept loop will call “accept” with a timeout in a loop (rather than blocking indefinitely). All Puma processes (workers when running in clustered mode) share the same socket, but they operate in isolation from each other. If all processes tried to claim as many requests as possible, it could lead to a scenario where one process has more work than it can handle, and another is idle. That scenario would look like this:

In this picture, worker 1 boots just slightly faster than worker 2. If it has no limit to the number of requests it accepts, it pulls in A, B, and C right away, even though it only has one thread and can only work on one request. Meanwhile, worker 2 finally boots and finds no requests waiting on the socket.

Note: This unbalanced worker condition is not limited to when workers boot; that’s just the easiest way to visualize the problem. It can also happen due to OS scheduling, request distribution, and GIL/GVL contention for the accept loop (to name a few).

An ideal server with two workers would look like this:

In this picture, requests A, B, C, and D arrive one-after-another. Each process accepts one request and processes it. Because A and B arrived first and there are two processes, they don’t have to wait at all. The Puma 6 wait_until_not_full optimization got us pretty close to this ideal ordering by not accepting a new connection unless it had capacity (free threads) to handle the work:

# Pseudo code
if busy_threads < @max_threads
  accept_next_request
else
  # Block until a thread becomes idle
  @not_full.wait @mutex
end

If you remember the pipeline “interleaved” example with Puma 7, it required that both connections (the pipeline carrying A, B, and C as well as the new connection carrying D) to be in the server at the same time. But wait_until_not_full ensures that it cannot happen since servers were prevented from accepting more connections than threads.

Previously, we introduced this goal:

Goal 1: Requests should be processed in the order they’re received, regardless of whether they came from calling accept on a socket or from an existing keep-alive request.

Now we’ll add:

Goal 2: Requests should be received in the order they’re sent, regardless of whether they came from calling accept on a socket or from an existing keep-alive request.

Puma 7 fixed this problem by never blocking the accept loop. But removing wait_until_not_full reintroduces the worker accept problem behavior: One process might accept more work than it can handle, even if another process has capacity. So we need to add a new goal

Goal 3: Request load should be distributed evenly across all Puma processes (workers) within the server.

Puma 7: Accept more, sleep more

To distribute load evenly across workers, we chose to extend a previously existing sleep-sort strategy, wait_for_less_busy_worker, used in the accept loop. In Puma 6, this strategy prioritized a completely idle worker over one serving a single request. Read more about that strategy in the PR that introduced it.

The new Puma 7 logic does that, and adds a proportional calculation such that a busier process will sleep longer (versus before all busy processes slept the same, fixed amount).

This behavior change also means that the semantics of the wait_for_less_busy_worker DSL have changed. Setting that now corresponds to setting a maximum sleep value.

With all of these fixes in place, the original keep-alive bug is gone. Let’s recap.

Puma keep-alive behavior before and after

Before: Puma 6 (and prior) behaved like this:

One keepalive connection can monopolize one thread for up to ten requests in a row.
The accept loop will completely stop when it sees all threads are busy with requests

After: Puma 7 behaves like this:

• The Puma 7 fix ensures fairness: New requests on a keep-alive connection (C, D) must wait their turn behind previously accepted requests (B).
• The accept loop never fully blocks. It now slows down in proportion to the system load.

It’s important to note that Puma 7 does not give your application more request capacity. It still has to do the same amount of work with the same resources. If you overload the Puma 7 server, there will still be some delay in processing requests, but now that delay is evenly and fairly distributed.

Rollout and reception

The effort to find, reproduce, report, investigate, and eventually fix this behavior was massive. It involved many developers for well over a year. When you see it all laid out linearly like this, it might seem that we should have been able to patch this faster, but it involved many overlapping and conflicting pieces that needed to be understood to even begin to work on the problem.

A huge shout-out to Greg, who landed the fix that went out in Puma 7.0.0.pre1. Plenty more changes went into the 7.x release, but this behavior change with keep-alive connections received by far the most amount of maintainer/contributor hours and scrutiny. We let the pre-release (containing only that fix) sit in the wild for several weeks and collected live feedback to gauge the impact. We were fairly cautious and even blocked the release based on what turned out to be a Ruby core bug that was affecting Tech Empower benchmarks.

Once we were happy with the results, I cut a release of 7.0.0 a few hours before the opening keynote of RailsWorld used it live on stage. Neat.

The reception has been overwhelmingly positive. Users of Heroku’s Router 2.0 have reported a massive reduction in response time, though any app that receives keep-alive connections will benefit.

Upgrade and Unlock Lower App Latency

The fix in Puma 7 ensures that your Ruby app is finally capable of realizing the low-latency, high-throughput benefits promised by HTTP/1.1 keep-alives and Heroku Router 2.0.

If you previously experienced unfair latency spikes and disabled keep-alives (in config/puma.rb or via a Heroku lab’s feature), we strongly recommend you upgrade to Puma 7.1.0+.

Follow these steps to upgrade today:

1. Install the latest Puma version

$ gem install puma

2. Upgrade your application

$ bundle update puma

3. Check the results and deploy

$ git add Gemfile.lock

$ git commit -m "Upgrade Puma version"

$ git push heroku

Note:

Your application server won’t hold keep-alive connections if they’re turned off in Puma config, or at the Router level.

You can view the Puma keep-alive settings for your Ruby application by booting your server with PUMA_LOG_CONFIG. For example:

$ PUMA_LOG_CONFIG=1 bundle exec puma -C config/puma.rb

# ...

- enable_keep_alives: true

You can also see the keep-alive router settings on your Heroku app by running:

$ heroku labs  -a <my-app> | grep keepalive
#...
[ ] http-disable-keepalive-to-dyno  Disable Keepalives to Dynos in Router 2.0.

We recommend all Ruby apps upgrade to Puma 7.1.0+ today!

The post Upgrade to Puma 7 and Unlock the Power of Fair Scheduled Keep-alive appeared first on Heroku.

Modern businesses don’t just run on Salesforce—they run on entire ecosystems of applications. At Heroku, we operate dozens of services alongside our Salesforce instance such as billing systems, user management platforms, analytics engines, and support tools. Traditional approaches to unifying this data create more problems than they solve.

In this article, we’ll see how we unified Salesforce and multi-app data into a real-time analytics platform that processes over 10 TB data monthly with 99.99% uptime. We’ve built a data warehouse architecture that eliminates ETL complexity while delivering real-time insights across our entire technology stack. Here’s how we did it and why this approach fundamentally changes data integration.

The Data Integration Challenge: Where Traditional ETL Fails

Similar to most companies, we faced issues where we had scattered data across Salesforce and multiple application databases with no unified analysis capability.

When dealing with Salesforce Apps, traditional ETL creates cascading problems: Salesforce API bottlenecks hit, daily API limits restrict data freshness, complex SOQL queries consume precious API calls, rate limiting causes pipeline delays when you need insights most, and developers are busy managing quotas instead of analyzing data.

With our multi-app Heroku ecosystem—including billing, user management, analytics, and support—complexity multiplies these challenges. This traditional approach results in:

• Separate ETL processes for each application database
• Production database load affecting application performance
• Complex integrations that break with schema changes
• No unified customer view across systems

Infrastructure overhead compounds problems with expensive ETL tools, manual schema management, fragmented monitoring, and dedicated teams just to maintain data pipes.

The Heroku Solution for Architectural Modernization

We leveraged Heroku’s unique position within the Salesforce ecosystem. Instead of fighting API limits and complex integrations, we built an architecture that works with the Heroku platform’s strengths:

• Native Salesforce integration through Heroku Connect eliminates API limitations
• Zero-impact data access via Heroku Postgres follower databases protects production performance
• A unified analytics platform provides a single warehouse for all data
• Heroku AI PaaS allows teams to focus on insights, not infrastructure management
• For any custom requirements, you could build an app using any programming language and deploy to production with the ease of Heroku AI PaaS

The result: We process over 10 TB of data monthly from 20+ data sources while maintaining 99.99% uptime and sub-minute data freshness.

The Heroku Data Warehouse and Data 360 (Salesforce Data Cloud) Synergy

Our architecture is designed to serve two purposes: providing real-time operational analytics for Heroku applications and acting as a low-latency staging layer for the broader enterprise. This data warehouse is perfectly positioned to complement the strategic power of Data 360 (Salesforce Data Cloud). Data 360 is focused on creating the unified customer profile and powering AI-driven business actions, while the Heroku data warehouse handles the high-volume, pro-code, operational data from your applications, ensuring that all mission-critical app data is integrated and available with sub-minute freshness to feed the Customer 360 view.

Architecture: How We Built It

Five core components work together seamlessly to bring this Data Warehouse to life:

1. Central Data Warehouse: Heroku Postgres + AWS Redshift

Heroku Postgres serves as our primary data warehouse, handling real-time operational analytics and serving as the staging area for all incoming data. This enables sub-minute query responses for dashboards and operational reporting.

AWS Redshift powers our historical analytics layer,  optimized for complex analytical workloads. It handles petabytes of historical data with automatic compression.

A Note on Tiered Storage and Scale: Our production environment currently uses this tiered approach to leverage Redshift’s optimized columnar storage for historical analysis. However, for architects planning a new build today, Heroku is innovating to simplify this model. The upcoming Heroku Postgres Advanced tier is built for massive scale (over 200TB storage) and 4X throughput in initial tests, offering the potential to consolidate large-scale historical storage and complex query capacity, further reducing architectural complexity.

2. Salesforce Integration: Heroku Connect

Heroku Connect fundamentally changes Salesforce data integration by providing direct database replication that bypasses API constraints entirely.

• No API Limits: It uses direct replication, not API calls.
• Real-Time Sync: It provides sub-minute latency vs. hours with traditional ETL.
• Bidirectional Capability: You can write to Salesforce from the warehouse and vice-versa.
• Production Scale: It operates through 12 regional instances deployed globally for scale, compliance, and reliability.

3. Source Application Data: Heroku Postgres Follower Databases

The breakthrough came from realizing we needed better database architecture, and not complex ETL.

• Heroku Postgres Follower Databases provide read-only replicas that protect app performance while providing real-time production data access.
• A simple one-command setup eliminates complex ETL infrastructure.
• We integrate 20+ source Heroku systems (billing, addons, pipelines) following a simple pattern: create a follower, store the connection string, and use template-driven jobs. Adding new apps scales linearly.

4. Orchestration: Apache Airflow

Managing 200+ jobs across 20+ sources requires sophisticated orchestration. Apache Airflow, hosted on Heroku, orchestrates everything through 30+ DAGs, ensuring 99.99% pipeline uptime across all data sources.

• Production architecture: 30+ DAGs organized by frequency and business function—hourly DAGs for real-time metrics, daily DAGs for comprehensive reporting, weekly DAGs for trend analysis, and monthly DAGs for historical aggregation. Complex dependency management ensures data consistency across all sources while enabling parallel processing where possible. Apache Airflow’s retry capability helps avoid failures/data-loss.
• Template-driven system: We created templates in Python code for incremental load, bulk load, date range load and have 200+ JSON job definitions to standardize data flow. Templates generate dynamic SQL. Incremental loading reduces transfer 90%. Atomic operations ensure zero-downtime updates.
• Heroku Connect integration: A dedicated monitoring DAG runs every 5 minutes, checking sync status across all 12 regional Heroku Connect instances and automatically retrying failed records. This proactive approach achieves 99.99% pipeline uptime while maintaining data freshness.

5. Analytics and Reporting: Tableau Integration + Heroku Dataclips

Tableau connects directly to both Heroku Postgres for real-time operational dashboards and Redshift for historical trend analysis. Heroku Dataclips provides instant SQL-based reporting directly from Heroku Postgres, offering lightweight, shareable, ad-hoc analytics for operational teams.

• Direct connectivity: It eliminates intermediate data movement for analytics and reduces latency. Tableau connects directly to both Heroku Postgres for real-time operational dashboards and Redshift for historical trend analysis, providing users with the right data source for their specific needs.
• Enterprise capabilities: Pre-built data models and standardized metrics ensure consistency while enabling exploration and discovery. Data governance features provide audit trails and lineage tracking. Self-service analytics empowers business users to create reports and dashboards.
• Performance optimization: Tableau extracts are strategically used for frequently accessed dashboards, while live connections provide real-time data for operational use cases. This hybrid approach balances performance with data freshness requirements.
• Heroku Dataclips: provides instant SQL-based reporting directly from your Heroku Postgres data warehouse, enabling teams to create shareable reports and dashboards without additional BI tools. This complements our Tableau integration by offering lightweight, ad-hoc analytics for operational teams who need quick access to data without complex dashboard setup.

What’s New from Heroku: Accelerating Your Data Strategy

The Heroku data warehouse architecture is proof of Heroku platform’s power, which continues to evolve as the Salesforce AI PaaS. We eliminate complexity and deliver enterprise-scale results.

To keep building with confidence and explore the latest advancements, read our post on new Innovations that expand the capabilities of every Salesforce Org. Key data features include:

• Heroku Postgres Advanced Tier: Delivering massive scale (over 200TB storage), 4x throughput, and decoupled compute/storage for non-disruptive, zero-downtime scaling.
• Expanded Heroku Connect Capabilities: Supporting data synchronization for 170+ standard Salesforce objects and adopting CDC Accelerated Polling to go from an update every 10 minutes to event-based and sync changes as they happen.
• Zero-Copy Data Cloud Ingestion (Beta): Enabling customers to easily bring existing Heroku Postgres data into Data 360 (Data Cloud) with zero data movement, which provides complementary data services to optimize Data Cloud architectures.

Conclusion: Performance and Impact at Scale

This architecture has transformed how we approach data integration, proving that the right platform choices eliminate traditional ETL complexity while delivering enterprise-scale results. By leveraging Heroku’s native Salesforce integration and managed infrastructure, we’ve built a data warehouse that scales effortlessly and maintains itself. The numbers demonstrate what’s possible when you stop fighting against platform limitations and start building with them.

Performance and Impact at Scale

• Performance at Scale: We built an easy-to-maintain Data warehouse on Heroku with over 10 TB data across Salesforce and 20+ Heroku apps.
• Pipeline Reliability: We run 200+ automated jobs for data load, maintaining sub-minute data freshness for critical metrics and 99.99% pipeline uptime with automated recovery.
• Cost and Operational Benefits: With Heroku, we eliminated expensive ETL infrastructure using follower databases. reducing data integration costs by 60% compared to traditional ETL tools. Dynamic scaling optimizes costs automatically, and we reduce operational overhead through managed platforms and unified monitoring across all sources.
• Business Impact: Our solution provides real-time insights that enable data-driven decisions. The unified customer view combines Salesforce and app data, improving customer analysis accuracy by 40%, and self-service analytics eliminates engineering bottlenecks.

This architecture eliminates ETL complexity while delivering real-time insights across your Salesforce and multi-app ecosystem. Heroku’s native integrations and managed platform focus you on business value, not infrastructure management.

The approach grows with you: start with Heroku Connect for Salesforce data, add follower databases for critical apps, then expand analytics as needs evolve. Each step builds on the previous without architectural changes.

Ready to unify your Salesforce and application data for your Data Warehouse? Contact Heroku Sales for architecture consultation and implementation guidance.

The post Building an Enterprise Data Warehouse on Heroku: From Complex ETL to Seamless Salesforce Integration appeared first on Heroku.

The Performance Penalty of Repeated Connections

Before the latest improvements to the Heroku Router, every connection between the router and your application dyno risked incurring the latency penalty of a TCP slow start. To understand why this is a performance bottleneck for modern web applications, we must look at the fundamentals of the Transmission Control Protocol (TCP) and its history with HTTP.

Maybe you’ve heard of a keep-alive connection, but haven’t thought much about what it is or why they exist. In this post, we’re going to peel away some networking abstractions in order to explain what a keep-alive connection is and how it can help web applications deliver responses faster.

In short, a keep-alive connection allows your web server to amortize the overhead involved with making a new TCP connection for future requests on the same connection. Importantly, it bypasses TCP slow start phase so data in requests are transferred over maximum bandwidth. If you’re already familiar with connection persistence, you understand the magnitude of this change. For everyone else, let’s look at the fundamentals of TCP and the slow start performance bottleneck.

The Solution: Keep-Alive Connections and HTTP/1.0

When you type an address into a browser, it uses Transmission Control Protocol (TCP) to create a connection and a request to a destination website. An HTTP request has headers and a body; these are parts that a Python, Ruby, or NodeJS app will receive, process, and then send back a response.

With HTTP/1.0, there was a one-to-one relationship between connections and requests. Every new request required opening a connection, sending the request, and then closing the connection.

This TCP connection is between sockets on computers. Once the connection is established, one server can send data to another in the form of a request or a response. This data queues up on the socket until a program (like a web server) calls accept on it to take the next connection in the queue. HTTP/1.0 was very simple, but it was inefficient due to something called TCP slow start.

TCP slow start

A TCP “connection” isn’t one thing; it’s a stream of packets. The speed (bandwidth) at which the connection operates is dependent on the network speed of the sender, the receiver, and everything in between. If the sender delivers packets too fast, they start getting dropped, which means the sender has to re-deliver those packets.

In a perfect world, the client (sender) would send packets at the maximum possible bandwidth, but not one byte over. In the real world, there’s no way to know that magical number. Even worse, the speed of the network isn’t static and might change. To solve the problem, an algorithm called TCP slow start is used, which dynamically tunes the bandwidth at the same time that data is being sent. You might remember I brought up this algorithm in my article on writing a GCRA rate throttling algorithm. In short, it sends data slowly, and every time that data is received successfully, it increments the speed a bit. If any data is lost, it takes drastic measures to slow down before gradually ramping up again.

TCP slow start is a good thing, but as the name implies, it is slow to start. And since TCP is stateless, every time you start talking to the same server, it has to repeat the process with zero assumptions. So if a browser is making repeated requests to the same endpoint, it has to repeat that TCP slow start multiple times. Not great.

TCP slow start has two parts contributing to this problem. The first is the “slow.” If we could find a faster algorithm, then it would eliminate the problem. We might tune and tweak it some more, but it’s an algorithm that’s already well researched. The other is the “start.” We might not be able to make a faster algorithm, but we only have to pay this cost once: at the start of a connection. If the connection doesn’t close, we can reuse it.

HTTP/1.1 Keepalives and Pipelines

With HTTP/1.1, we have two new tools for this TCP slow start problem: pipeline and keep-alive connections. Both operate on the same basis: decouple requests from connections to reduce the “start” side of the problem.

Pipeline connections allow sending multiple requests in one payload. The headers and bodies are constructed ahead of time, concatenated together, and delivered to the server up front. In this scenario, one connection carries multiple requests (A, B, and C), but they’re all delivered at once.

Keep-alive connections usually only carry one request up front (versus a pipeline request), but they tell the server, “once you’re done responding, don’t hang up, I might have another request for you.” This mechanism is very useful. It allows a browser to do things like: keep a pool of connections to the same origin so it can reuse them when downloading images or CSS. Unlike pipeline requests, it doesn’t have to know the use cases ahead of time, so this mechanism is more flexible.

The important thing here is that both pipeline and keep-alive connections work around the TCP slow start bottleneck by not closing the connection. These are features that come from the HTTP/1.1 spec and are fairly well supported by most web servers.

Heroku Router 2.0: Unlock Lower Latency Today

Repeatedly paying the cost of a new TCP connection for every request is a hidden performance tax, that potentially slows down your application. Heroku’s Router 2.0 is already set up to use keep-alive connections by default, eliminating the costly TCP slow start penalty on repeat requests. Now it’s time to ensure your application can fully take advantage of that unlocked bandwidth and latency reduction.

If you previously experienced unfair latency spikes and disabled keep-alives (in config/puma.rb or via a Heroku lab’s feature), we strongly recommend you upgrade to Puma 7.1.0+.

Follow these steps to upgrade today:

1. Install the latest Puma version

$ gem install puma

2. Upgrade your application

$ bundle update puma

3. Check the results and deploy

$ git add Gemfile.lock

$ git commit -m "Upgrade Puma version"

$ git push heroku

Note: Your application server won’t hold keep-alive connections if they’re turned off in Puma config, or at the Router level.

You can view the Puma keep-alive settings for your Ruby application by booting your server with PUMA_LOG_CONFIG. For example:

$ PUMA_LOG_CONFIG=1 bundle exec puma -C config/puma.rb
# ...
- enable_keep_alives: true

You can also see the keep-alive router settings on your Heroku app by running:

$ heroku labs  -a <my-app> | grep keepalive

[ ] http-disable-keepalive-to-dyno  Disable Keepalives to Dynos in Router 2.0.

We recommend all Ruby apps upgrade to Puma 7.1.0+ today!

The foundation is set for faster experiences. Beyond HTTP/1.1, the new Heroku Router also supports HTTP/2 features, enabling us to deliver new routing capabilities faster than ever before. Start delivering faster, more responsive applications today. Review your web server version and application configurations to enjoy the full power and lower latency of keep-alive connections.

The post Learn How to Lower Heroku Dyno Latency through Persistent Connections (Keep-alive) appeared first on Heroku.

Imagine this: Your sales team is about to close a major deal. They’re building a custom quote in your app, but they need to see the latest product line items from an Opportunity in Salesforce. They refresh. And wait. The data is stale. The quote gets generated, but it’s missing the latest addition to the deal since your data didn’t sync yet.

This isn’t a hypothetical problem. It’s a frustrating reality for developers who have been limited by legacy data synchronization technology. You’ve told us you need faster, more comprehensive data sync, particularly Accelerated Polling support for crucial but unsupported objects like Opportunity Line Items.

We listened. Today, we’re thrilled to announce a foundational upgrade to Heroku Connect, available starting this week: Accelerated Polling can now listen to Salesforce Change Data Capture (CDC) to accelerate the polling frequency for your key objects.

Begin your journey, read the Dev Center guide on setting up accelerated polling of Salesforce.

This isn’t just a technical update; it’s the key to unlocking the rapid synchronization for the mission-critical apps you’ve always wanted to build.

From a Nudge to a Complete Story

Previously, Heroku Connect’s Accelerated Polling feature only used the Salesforce Streaming API to detect changes. This restricted the number of objects that were supported as part of Accelerated Polling.

With Accelerated Polling now supporting Salesforce CDC, the result is a foundational leap forward in sync speed and efficiency. Your Opportunity Line Item data now syncs more quickly, allowing you to finalize that significant deal you were pursuing.

What Salesforce Change Data Capture for Accelerated Polling Unlocks for You

This move from legacy technology to a modern standard solves one of the biggest challenges our customers have faced. Finally, you can enable accelerated sync for your critical objects. The old Streaming API had frustrating limitations. Crucial objects like Opportunity Line Items were left out, creating gaps in your data strategy.

With CDC, we’re blowing the doors open. Accelerated Polling will now support over 170 new Salesforce standard objects, allowing you to sync the complete dataset that drives your business.

How to Get Started Today

Salesforce CDC support for Heroku Connect’s Accelerated Polling is rolling out to all Heroku Connect customers this week. Enabling it is a simple, two-step process between you and your Salesforce Admin.

1. In Salesforce: Ask your Salesforce Administrator to enable Salesforce Change Data Capture for the specific objects you want to sync with Accelerated Polling (like Pricebook2, Asset, or OpportunityLineItem). They can find this in Salesforce’s Setup menu.
2. In Heroku Connect: Once an object has Salesforce CDC enabled in Salesforce, a new option will automatically appear in your Heroku Connect dashboard. Simply select the “Uses Accelerated Polling” option for Accelerated Polling on your mappings for those objects.

That’s it. For a detailed walkthrough, check out our new step-by-step guide in the Heroku Dev Center.
Welcome to the next generation of seamless Salesforce data synchronization. We can’t wait to see what you build with it.

The post Heroku Connect: Faster, More Reliable Data Sync with Salesforce CDC appeared first on Heroku.

Today’s businesses face a tremendous amount of complexity in tools, data silos, and systems that teams need to navigate to deliver unique and engaging experiences to their customers. Meanwhile developers are only able to spend a fraction of their time coding due to the cognitive load of technology complexity, constant context switching, and figuring out how to adopt AI effectively into their daily work.

The Heroku AI PaaS is the Cloud Native Application Platform from Salesforce to seamlessly build and scale any custom service for greenfield app development, modernizing existing apps, and as part of a Salesforce cloud implementation.

At Dreamforce, we are excited to introduce new innovations to our AI PaaS that expand the capabilities of every Salesforce org and empower new builders. Today’s announcement includes innovations in three key areas:

1. Expanding the capabilities of every Salesforce org with the flexibility of more pro-code and elastic compute with enterprise performance, scale and security enhancements.
2. Enhancing and expanding the data foundation to empower our customers’ modern and AI app strategies.
3. Delivering new vibes using AI to make the process of building new applications as accessible as sending a text message.

Expanding the capabilities of every Salesforce org with AppLink

Following up to our July release of AppLink, a feature that seamlessly and securely connects custom services on Heroku with workflows and configurations in Salesforce Platform, Agentforce, and Data Cloud, we are delivering the following enhancements:

• Enhanced Security with support for JWT auth enables Heroku to provide custom user facing experiences for headless Agentforce deployments.
• Scalability and Performance with a 4X increase in the invocation rate throughput to handle higher levels of traffic and more complex operations with greater efficiency.
• Automation with Open API Spec to streamline Agentforce topic generation. Eliminate manual steps and errors by using annotations to speed up your configuration, deployment, and time to market.

Enhancing our data foundation to empower AI

Heroku’s long history in managed data services continues to innovate and evolve to meet the changing demands on data for modern, AI powered solutions. Our innovations focus on futurizing our data foundations and delivering unique capabilities to Salesforce orgs and Data Cloud.

• Next Gen Heroku Postgres replatforms the popular Postgres offering to enhance performance, deliver massive scale, and deliver storage flexibility, zero downtime provisioning and updates, and user experience improvements to enable developers to build the apps of the future. Read more here.
• Expanding Heroku Connect capabilities to support data synchronization for 170+ standard Salesforce objects and adopting CDC Accelerated Polling to go from an update every 10 minutes to event-based and sync changes as they happen.
• Heroku for Data Cloud leverages AppLink to bring the power of industry programming languages to build and run custom apps against your Data Cloud, provide complimentary data services to optimize Data Cloud architectures, and the beta of Zero Copy for Heroku Postgres to enable customers to easily bring their existing data into a unified Data Cloud for a fuller picture of their customer and to enable Agentforce agents.

Bringing AI vibes to how new apps are built and deployed

Software development has largely been the domain of technical experts specialized in specific programming languages, frameworks, and tools making it inaccessible to those in non-technical backgrounds. While the demand for new apps has continued to grow, the available developer tools have only increased in complexity and increased cognitive load on a highly constrained group of skilled professionals. Enter AI and vibe coding to provide a new experience that makes creating apps as intuitive as sending text messages.

• Heroku Vibes is an AI-powered, collaborative agent experience for both developers and non-developers to create and deploy new applications in minutes using natural language instructions. Heroku Vibes takes those instructions to prepare a spec driven development plan, provisions the required infrastructure, and automatically deploys the application for the user. Learn more and try it here.

AI is rapidly changing the landscape of app creation and what these new apps can do. With more creators entering the space, the friction and gap for secure delivery and challenges of being performant at scale will only compound. Heroku AI PaaS is about solving the challenges at every step along the way – so that your team can focus on what’s important – building value for your customers, employees, and business.

The post Heroku Introduces New Innovations to Expand the Capabilities of Every Salesforce Org appeared first on Heroku.

We are thrilled to announce the next generation of Heroku Postgres to power a data foundation for the next wave of intelligent and mission-critical applications. This roadmap has been driven by listening closely to our customers, culminating in the introduction of a new Heroku Postgres Advanced tier. This revolutionary data foundation is designed to eliminate previous scaling limits, unlock unprecedented architectural flexibility and performance, and reduce operational friction. As the AI PaaS from Salesforce, Heroku is the force multiplier for developers building this future with an integrated platform with powerful capabilities made simple to use – removing friction along the software delivery lifecycle. We invite you to sign up for the pilot.

Heroku Postgres has a long history of enabling the most demanding workloads, from HealthSherpa’s high volume during peak enrollment periods of over 1200 requests and 30,000 queries per second to the Salesforce Data Migration Team’s ability to transform complex data processing from weeks to minutes.

Today’s announcement builds on a year of data innovations from replatforming new Essential-tier plans to delivering innovative new capabilities like streamlining upgrades.

Postgres Advanced: Heroku’s innovation layer for scale, speed and reliability

The Heroku Postgres Advanced tier is built on the latest database technologies from AWS through a collaboration with the AWS data team. Heroku transforms that robust underlying database technology by adding innovative capabilities, a superior developer experience, and operational automation. The result is a powerful managed data service that offers simplicity, reliability, and non-disruptive, zero-downtime scaling for massive scale environments.

What’s new in Heroku Postgres:

• High performance and scalability: The new architecture is built for demanding applications. We’ve seen over 4X throughput during initial tests, and it introduces high storage scalability, allowing over 200TB of storage. This immense capacity ensures that your database can grow seamlessly alongside your business, accommodating ever-increasing data volumes and throughput without compromising performance. Furthermore, Postgres Advanced dramatically increases connection capacity, ensuring your application can handle concurrent users at scale.
• Compute and storage flexibility: We’ve decoupled compute and storage to allow complete flexibility in how you configure and consume database resources, including high-availability standby, to match the specific needs of the application at any time. This architecture shift provides increased vertical and horizontal scaling and flexibility to support more complex customer data architectures.
• Proprietary follower pool architecture: Achieve superior read performance and operational agility. This unique Heroku innovation allows you to organize your database topology by attaching named follower pools to specific applications for effortless read distribution and horizontal or vertical scaling of replicas without disrupting the applications. This ensures your scaling operations are non-disruptive to achieve zero-downtime and maintain optimal performance during peak load.
• Refreshed user experience: We’re committed to enhancing the intuitive UX that Heroku is known for. Postgres Advanced will feature a new and intuitive interface in the UI dashboard and CLI that is interactive and easily scales.

The next generation of data is here. Join the pilot.

We are excited to have you try the pilot and get your feedback. Your involvement is critical; over the course of the pilot we will continue to update the product with more features, both familiar and new – including full support for our customers that require regulatory compliance. You can expect the General Availability (GA) in early 2026. Following GA, we will provide tooling enabling you to migrate your existing database seamlessly. This new Heroku Postgres Advanced tier will eventually replace our existing Standard, Premium, Private and Shield tiers.

Join the waitlist

The post Introducing the Next Generation of Heroku Postgres – Unlocking Performance, Scale, and Zero-Friction Ops appeared first on Heroku.

Introducing the pilot of Heroku Vibes, your collaborative agent for turning ideas into running apps.

For those who have been with us on this journey for a while, the name “Heroku Garden” might stir up a bit of nostalgia. It was the web experience that enabled developers to become immediately productive in creating and deploying Rails applications with a turnkey, opinionated environment, with the goal of making software easier and more accessible. That seed of an idea that would grow into the platform powering millions of mission-critical apps. We’re thrilled to announce the pilot of Heroku Vibes, a reimagining of our original mission into an experience built for the future.

The Heroku philosophy: effortless developer experience

From the very start, Heroku has been guided by a powerful philosophy: everyone can be a builder. We believe in the power of a great developer experience (DX). A great DX isn’t just about making things easy; it’s about making the right things easy and removing the wrong things from your path. It’s an opinionated approach that clears the way for developers to focus on what they do best: creating.

We’ve always strived to abstract away the complexities of infrastructure, so you can pour your energy into your code, not into configuring servers. This philosophy manifested in features that have become industry standards, from seamless git push heroku main deployments to buildpacks that automatically detect, build, and configure your application’s environment. We handled the tedious work of infrastructure management so you could stay in your creative flow.

Building apps with natural language

This obsession with a seamless workflow is more critical now than ever. The landscape of application development has changed dramatically with AI bringing in a whole new generation of builders. After building their first app, these developers today navigate a sea of container orchestration, CI/CD pipelines, and a dozen different cloud services just to get an application live. The cognitive overhead is immense for developers while this process is almost completely inaccessible to anyone else. We see a world where the power of modern applications is often locked behind a wall of incidental complexity. We believe it’s time to tear down that wall.

Heroku Vibes: AI-powered app building

That’s why we are excited to introduce the next evolution of this vision: Heroku Vibes. This represents the next evolution of our commitment to an effortless DX, but this time for all of the builders, not just developers. Heroku Vibes is a web-based experience that takes natural language to build and deploy full apps. The barrier to entry for building and deploying an application has been lowered to the ability to simply describe what you want to create. It’s the ultimate abstraction, the purest form of the Heroku vision.

From natural language to deployment in minutes

Imagine typing:

Let’s create an app that combines the tour schedules for my favorite bands with locations and weather data, so I can plan which outdoor concerts to hit.

or

Create a Node.js API with a Postgres database and a Redis cache, and deploy it to a staging environment in my pipeline.

Heroku Vibes parses your intent and seamlessly handles the rest: generating code, provisioning the database, connecting the cache, configuring the environment variables, connecting the services, and deploying the application. It transforms the complex choreography of software development and modern infrastructure into a simple, powerful conversation. This is the next chapter in making the right things easy.

Heroku Vibes is for every builder

Heroku Garden was for Rails developers. The new Heroku Vibes is for everyone. It’s for the seasoned developer who wants to spin up a prototype in minutes without breaking their flow. It’s for the student who is just starting their coding journey and wants to see their ideas come to life without getting bogged down by having to manage infrastructure. It’s for the entrepreneur who has a great idea but not the technical background to bring it to life on their own. We are returning to our roots to empower you to build the future. A future where the only thing standing between you and your next great application is the power of your words.

How to access Heroku Vibes

The new experience is live at vibes.heroku.com. We’ll be expanding user access from today onward.

Welcome to Heroku Vibes. We can’t wait to see what you build.

What is Heroku Vibes? Heroku Vibes is the simplest way to go from idea to app. Vibes is your AI-powered, collaborative agent for everyone – both developers and non-developers – turning ideas into live applications in minutes. Vibes removes friction from creating, evolving, and scaling apps. For individuals, Vibes grows from prototype to production. For enterprises and Salesforce customers, it is a safe and secure way to create and scale apps extending the platform.

Why Heroku Vibes? Heroku’s vision has always been to make software development much easier and more accessible. With the advent of generative AI, Heroku can now bring its deep experience and platform excellence to bear in creating an AI environment that enables users to bring their ideas to life as applications, with all of that operational expertise in play to create well-written applications that work well on the Heroku platform. This enables everyone from non-developers to expert programmers to get up and running with extremely low friction, creating and iterating on new apps, or driving meaningful change to existing apps.

The post Welcome to Heroku Vibes appeared first on Heroku.

Ever found yourself in the endless loop of tweaking a prompt, running your code, and waiting to see if you finally got the output you wanted? That slow, frustrating feedback cycle is a common headache for AI developers. What if you could speed that up and get back to what you do best? Let’s focus on building amazing applications.

We’re excited to introduce Heroku AI Studio, a new set of tools designed to streamline your generative AI development from prompt to production. We’ve focused on creating a more intuitive and efficient workflow, so you can focus on innovation instead of wrestling with your development environment. When using the Heroku Managed Inference and Agents add-on, this new tool is about to become an essential part of your workflow.

Heroku AI Studio: your interactive AI workspace

Heroku AI Studio is your interactive workspace for the Heroku Managed Inference and Agents add-on. It allows you to directly engage with the underlying models and tools you’ve provisioned. Think of it as a real-time sandbox where you can experiment freely, understand model behavior, and fine-tune your prompts to get the exact output your application needs.

Key benefits for developers

Heroku AI Studio is more than just a testing tool; it’s a complete environment for rapid prototyping and iteration. Here’s how it helps you build better AI features, faster:

• Understand model nuances: Get a feel for the strengths and subtleties of your provisioned AI model by experimenting with different prompts and parameters in real time. This will help you quickly learn how to get the best results.
• Tune prompts with efficiency: Now, you can tune and refine your prompts directly in the studio. Iterate on instructions and text until they’re perfect, and then seamlessly integrate them into your application.
• Ensure appropriate and effective tool use: AI Studio provides affordances to ensure that tool use is effective and appropriate for your specific use case, leading to more reliable and predictable outcomes.
• Integration into your code: The studio provides built-in guidance and example code snippets to make the integration into your application’s codebase as smooth as possible.

Getting started with Heroku AI Studio

If you already have a Heroku Managed Inference and Agents add-on provisioned for your app, you can get started in just a few clicks:

1. Navigate to your app’s Resources page in the Heroku Dashboard.
2. Click on your Heroku Managed Inference and Agents add-on from the resource list.
3. On the resource view, simply click the “Open Playground” button.

You’ll be launched directly into the Heroku AI Studio, ready to start exploring, testing, and building.

Let’s start building

Heroku AI Studio helps you tackle some of the most common challenges in AI development. You can now fine-tune your prompts with greater speed and precision, ensuring your AI-powered features are both effective and appropriate for your users. We’ve also made it easier to manage and integrate the various tools and services your application relies on.
Ready to see how Heroku AI Studio can improve your workflow? Get started today and let us know what you think. We’re excited to see what you’ll build!

The post Heroku AI Studio is Your Workspace for Smarter, Faster AI Apps appeared first on Heroku.

Salesforce customers often leverage third-party or custom services to extend their orgs, and they do so with two common options: Connected Apps and External Services. Connected Apps let third-party vendors or custom code call Salesforce APIs using long-lived OAuth tokens, while External Services call vendor APIs through declarative configurations with vendor-managed hosting, scaling, and endpoint security. While both approaches deliver functionality, the dynamic security threat landscape challenges us to continuously improve the risk and governance of our applications.

Heroku AppLink improves your security model and provides a managed bridge between Salesforce and Heroku, so developers or vendors can deploy services in any language and expose them as native Salesforce actions. Heroku AppLink automatically handles authentication, service discovery, and request validation while its service mesh and short-lived credentials mean that your integrations no longer depend on stored credentials or exposed endpoints. Development teams can reuse existing code and libraries instead of rewriting in Apex, admins get centralized visibility into connections and authorizations, and security teams gain tighter trust boundaries across both Connected App and External Service scenarios.

In this post, we’ll explain how AppLink enforces trust at each step across both directions of integration traffic and give you concrete actions you can take when building.

Securing Salesforce outbound API calls with AppLink

Salesforce orgs often call out to external logic like AI models, payment gateways, or industry-specific APIs that live on public clouds or are operated by a third-party vendor. Traditionally, the vendors expose a public endpoint and trust any client presenting a bearer token. This delivers functionality but creates risk. If a token is stolen or the endpoint is misconfigured, attackers can replay calls and pull data directly from Salesforce.

Heroku AppLink solves this by putting a service mesh in front of the integration service when it is deployed. Instead of a public endpoint, only Salesforce orgs that you explicitly connect can reach the app. The mesh validates each request before handing safe context to the SDK. This ensures that inbound traffic is authenticated at the org level, not just by a token.

For customers, this means you can ask vendors to move their integration service onto Heroku with AppLink and gain the assurance that only your org can invoke it. For vendors, it means they can take the same Node.js or Python service running in AWS or Azure, deploy it to Heroku, and instantly benefit from Salesforce-native request validation.

Setting up a Salesforce External Service with AppLink on Heroku

Provision the AppLink add-on

heroku addons:create heroku-applink -a example-app

Add the service mesh buildpack

heroku buildpacks:add --index=1 heroku/heroku-applink-service-mesh -a example-app

Connect the Salesforce org

Publish an API spec as an External Service

Assign the generated permission set to users who will invoke the External Service action.

Inbound API calls to Salesforce: scoped, on-demand credentials

External services often need to call back into Salesforce to update records, write support case notes, or sync customer data. Salesforce enables this by storing long-lived OAuth refresh tokens. The risk of those tokens being compromised gives malicious actors broad, long-term access to bypass MFA, which is often a weakness targeted in token replay attacks.

Heroku AppLink employs short-lived credentials obtained at runtime for outbound calls for services deployed on Heroku. For user and user-plus modes, vendors do not need to cache refresh tokens, and in authorized-user mode, AppLink stores a customer-controlled authorization for a named integration user, which contains the credential material needed to obtain short-lived credentials. These authorizations are scoped and managed within the AppLink add-on, not in a multi-tenant vendor system. Each call is scoped by the mode you select:

• User mode runs with the permissions of the Salesforce user invoking the service.
• User-plus mode adds a temporary session permission set defined in your API spec.
• Authorized-user mode runs as a designated integration identity that you authorize.

Salesforce customers can request that vendors utilize AppLink to secure inbound calls and prevent the storing of tokens that can be replayed against a Salesforce org. Using AppLink also benefits the vendors to continue to run the same integration logic but with stronger controls that satisfy enterprise security requirements.

Using AppLink authorizations for calls to Salesforce

Publish with user-plus mode

heroku salesforce:publish api-spec.yaml \
--client-name MyAppAPI \
--authorizationPermissionSetName MyAppUserPlusSet \
-a example-app

Add an authorization for authorized-user mode

heroku salesforce:authorizations:add auth-user \
--addon applink-regular-78506 \
-a example-app

And in code:

const auth = getAuthorization('org_name');

To understand the critical importance of this design, it’s helpful to examine the common attack pattern that AppLink prevents. This pattern has enabled recent data thefts by exploiting long-lived tokens.

When long-lived tokens turn into attack vectors

Consider a scenario where an integration provider stores OAuth tokens for many Salesforce orgs. These tokens are long-lived and grant broad access to Salesforce APIs and can lead to the following attack scenarios:

• Token replay for direct API access: The attacker can present the stolen token to Salesforce and gain the same access as the connected app. This bypasses MFA and session controls since OAuth bearer tokens are accepted until revoked.
• SOQL reconnaissance: With valid tokens, the attacker can issue queries against objects like User, Case, Account, and Opportunity to inventory sensitive data. They can count records, filter by fields, and identify where credentials or secrets might be stored in free-text fields.
• Bulk API data export: Once valuable objects are identified, the attacker can launch Bulk API jobs to extract large volumes of records quickly. This method is efficient and can drain high-value datasets with a handful of requests.
• Covering tracks: After completing Bulk API jobs, the attacker can attempt to delete the jobs to hide evidence, making detection harder in standard monitoring flows.

Attacks that leverage long-lived OAuth tokens stored by third-party systems do not exploit Salesforce itself. They exploit the reuse of bearer tokens issued legitimately but stored outside the customer’s control.

AppLink reduces the opportunities for attackers to replay OAuth tokens dramatically because each credential is short-lived and bound to a specific org, and the service mesh enforces that only Salesforce orgs you have explicitly connected can send requests to your service on Heroku. In user and user-plus modes, tokens are not long-lived refresh tokens sitting in a vendor system. The AppLink SDK obtains short-lived, scoped credentials at runtime, tied to the mesh context and the user mode you define. Your code does not handle bearer tokens. In authorized-user mode, AppLink stores a customer-controlled authorization for a named integration user, which is then used to obtain short-lived credentials only when needed. These authorizations live with your AppLink add-on for your app, not in a multi-tenant vendor cache.

How the AppLink service mesh enforces inbound validation

Every call from Salesforce carries an x-client-context header with base64-encoded JSON that describes the org and user. The mesh allows traffic only from connected orgs before the request reaches your code. The SDK decodes this header so your app sees safe context, not raw credentials:

javascript

const ctxHeader = req.headers["x-client-context"];
const ctxJson = Buffer.from(String(ctxHeader), "base64").toString("utf8");
const ctx = JSON.parse(ctxJson);

The SDK decodes x-client-context automatically. Read it manually only for troubleshooting.

This context is what your app uses to decide business logic. You never see or manage bearer credentials directly.

How the AppLink service mesh enforces scoped outbound calls

When your app needs to call Salesforce, AppLink obtains a short-lived credential at runtime based on the user mode. In user or user-plus mode, the credential reflects the invoking user’s rights and any session permission set you defined at publish time. In authorized-user mode, you first add an authorization, then reference it in code so the SDK can obtain a short-lived credential when needed:

bash

heroku salesforce:authorizations:add auth-user \
--addon applink-regular-78506 \
-a example-app

javascript

const auth = getAuthorization("org_name"); // default add-on
// or specify a particular attached add-on by name or UUID
const auth2 = getAuthorization("org_name", "applink-regular-78506");

The SDK uses that authorization to obtain a short-lived token only when needed, and it expires quickly.

Built-in protection against credential replay

The mesh ties every inbound request to a connected org and every outbound call to a fresh, short-lived credential. Captured credentials have very limited replay value since they expire quickly and are bound to a specific org and mesh context

This design is what closes the gap exploited in token replay attacks. The mesh validates the caller, the SDK scopes the action, and the credentials themselves expire fast enough to have no value if stolen.

Why this matters to developers and security teams

Salesforce customers extend their orgs in two main ways. Connected Apps let vendors call Salesforce APIs, but often require storing long-lived OAuth tokens. External Services let Salesforce call out to vendor APIs, but put endpoint security and token handling on the vendor. Both approaches work but introduce risk.

AppLink strengthens this model by combining the usability of External Services with managed security and by removing the token exposure often seen with Connected Apps:

• No long-lived credential storage. Credentials are minted per request by the mesh, not cached by vendors.
• Validated inbound traffic. Only explicitly connected Salesforce orgs can reach the Heroku app.
• Scoped outbound calls. User, user-plus, and authorized-user modes enforce least privilege.
• Governed publication. APIs are registered in the Salesforce API Catalog, giving admins and security teams visibility.
• Reduced blast radius. Credentials are tied to a single org and cannot be replayed across customers.

This means Salesforce customers can keep using External Services to connect to third-party APIs and can still rely on Connected Apps where needed, but by adopting AppLink or requiring vendors to use it, both patterns gain stronger controls, better governance, and a lower risk profile.

Strengthening Salesforce integration security with AppLink

Long-lived tokens create risk when stored and reused. AppLink eliminates that risk by obtaining short-lived, scoped credentials at runtime through the service mesh. In authorized-user mode, AppLink maintains a customer-controlled authorization for a designated integration user, scoped to your Heroku app and used only to obtain short-lived credentials when needed.

Whether you are building, buying, or managing integrations, AppLink provides a consistent framework for securing and governing them.

• Customers building their own integrations can adopt AppLink directly to secure inbound and outbound traffic.
• Customers who rely on ISVs or partners can raise the bar by requiring those vendors to use AppLink as their integration pattern.
• Developers benefit from cleaner integration workflows.
• Admins gain visibility and control over what is connected.
• Security teams and CISOs get stronger assurance that integrations cannot be replayed or abused.

Adopting AppLink and asking partners to do the same improves security and trust for every Salesforce org.

The post Securing Salesforce Integrations with Heroku AppLink appeared first on Heroku.

When Production Goes Sideways

Imagine this: It’s 2 AM, your phone buzzes with an alert, and your dashboards are screaming. Production is down. Sound familiar? An automated health check has failed, and your internal dashboards are showing a spike in errors. You’ve just pushed a new release that included a critical database schema change, and a background worker task that relies on it is now failing. The web application is still running, but users are starting to report issues. You need to investigate and fix the problem, but doing so on a running production dyno could be risky and impact your live service.

In the past, you might have used heroku run:inside to connect to a running web dyno and troubleshoot, but that can consume resources from a live process and potentially destabilize a running production application. Alternatively, you might have used heroku run:detached to run a command in the background, but this doesn’t give you the interactive session you need for real-time diagnostics.

This is a classic developer’s nightmare, but it’s exactly the kind of scenario where Heroku’s next-gen platform capabilities shine. Now, you can use heroku run to launch a dedicated, one-off dyno to perform administrative or maintenance tasks, completely separate from your formation dynos. This is a key difference from heroku run:inside and heroku run:detached.

Fixing the problem: The power of heroku run interactive

Heroku’s next-gen platform (codename Fir) introduces the heroku run command for launching a one-off dyno to execute administrative or maintenance tasks for your application. This command initiates an interactive CLI session, relaying input and output between your terminal and the running dyno. This is a critical solution to a functional gap, providing an isolated, yet responsive shell for hands-on operations.

This new interactive capability is perfect for a critical task like a database migration. You get a shell inside a temporary dyno that has your application’s code and environment variables, allowing you to run a migration script and watch the output in real time. The ability to run interactive commands like this in a safe space is paramount for effective debugging and troubleshooting.

To use heroku run on Fir, you must first add a public SSH key to your account. This is a new security feature that provides a robust authentication mechanism for interactive sessions. You must also have your application deployed.

Then, simply run your command with heroku run. For a migration, you might use a command like this:

$ heroku run -a my-test-application -- rake db:migrate

This new workflow provides a much-needed bridge between a quick fix and a full-scale deployment, giving developers the power and flexibility they need to manage their applications more effectively.

Gaining full visibility with OTel

Now that the database migration is complete, how do you know your application’s performance has returned to normal? This is where the new OpenTelemetry (OTel) signal enhancements, natively integrated into the Fir platform, come into play. Heroku’s telemetry provides comprehensive out-of-the-box data, ensuring consistency by adhering to semantic conventions.

This adherence to an open standard is not a trivial detail; it is a design choice that ensures consistency and interoperability. The benefit of Heroku’s telemetry data using standardized attribute names and formats is that it allows the data to be easily ingested and correlated by any OTel-compliant observability platform, such as Grafana, Honeycomb or Datadog. This approach mitigates the risk of vendor lock-in and simplifies integration into an existing observability ecosystem.

• Request duration percentiles: Heroku’s router now emits detailed metrics that include request duration summary statistics and percentiles. This allows you to see the “long tail” of performance issues that affect a small but significant percentage of your users. For example, you can inspect metrics like http.server.request.duration.p0-999 to see the 99th percentile request duration. The heroku.router.connect and heroku.router.service attributes are now captured as floats, providing more precise timing data. This detailed view gives you the confidence that your fix not only restored the service but also improved the experience for all users.
• The heroku.app.name attribute: The heroku.app.name attribute is now automatically added to all application signals. This simple addition is incredibly powerful for filtering and analyzing data. You can easily filter all of your logs, metrics, and traces by this attribute to get a unified and complete view of a specific application’s health without having to look up the app UUID. This is especially useful in a microservices architecture where you have multiple applications running in the same space. This holistic data model allows for efficient correlation and analysis across all components of the system.

Heroku’s platform also emits signals from first-party services like the Heroku Platform API, Heroku Postgres, and Heroku Kafka. These signals are all filterable by the service.name attribute, allowing you to see all activity related to a specific service. This enables a level of operational visibility that is invaluable for root cause analysis.

A complete debugging workflow

With Heroku Fir, you have a complete and powerful debugging workflow that covers every stage of an incident. It’s a significant leap forward to improved operational efficiency, reduced risk, and faster incident resolution.

1. Identify the problem: Start with your observability tools. The OTel signal enhancements, including the new http.server.request.duration router metrics, can help you identify a problem like high latency or a spike in errors. Use the heroku.app.name attribute to filter the traces and quickly pinpoint the affected application.
2. Fix with confidence: Use the interactive heroku run command to launch a dedicated, one-off dyno to perform your fix. This provides a safe, isolated environment that won’t disrupt your live formation dynos. This capability reduces the risk of maintenance tasks affecting production by providing an isolated environment.
3. Verify and monitor: Once the fix is complete, use the new OTel signals to confirm that your application’s performance has returned to normal. The request duration percentiles give you a detailed view of latency, and the heroku.app.name attribute ensures you can monitor the long-term health of your application with ease. This comprehensive telemetry provides the data needed for quick and effective root cause analysis, thereby reducing Mean Time to Resolution (MTTR) and improving operational resilience.

By combining the powerful interactivity of heroku run with the deep insights from native OTel signals, you’re not just fixing problems — you’re building a more resilient and observable application. This is the new era of Heroku development, built to empower you to debug, manage, and scale your applications with unprecedented visibility and control.

Ready to experience this new level of control and visibility? Explore Heroku Fir today.

The post Triage and Fix with Confidence: <code>heroku run</code> and OTel on Heroku Fir appeared first on Heroku.

Beginning at 06:00 UTC on Tuesday, Jun 10, 2025, Heroku customers began experiencing a platform service disruption due to an unintended system update applied to our production infrastructure by our vendor. To compound the issue, the Heroku Status site was affected by the outage. Shortcomings in site design and API latency resulted in timeouts, and the Status site appeared as if there were no active incidents.

On June 15th we published a summary of our initial investigation, mitigation, and root cause analysis. We also identified the following post-incident remediation objectives:

• Ensuring immutable infrastructure
• Increasing resilience of communication channels
• Accelerating investigation and recovery

As promised, we are providing a status update of our continued corrective actions.

Ensuring Immutable Infrastructure

Our June 15th commitment to customers

The root cause of this outage was an unexpected change to our running environment. We disabled the automated upgrade service during the incident (June 10), with permanent controls coming early the next week. No system changes will occur outside our controlled deployment process going forward. Additionally, we’re auditing all base images for similar risks and improving our network services to handle graceful service restarts.

Where we are today

To ensure that future system changes occur only in a controlled manner, we:

• Implemented a permanent halt on all unattended vendor operating system upgrades
• Audited our images to rule out any other sources of mutation
• Developed a risk-based strategy for what types of changes could be safely automated as an attended upgrade

For network resiliency, we added automated startup scripts for our networking services. We are also actively working with our colleagues to help maintain and validate our system images.

Increasing Resilience of Communication Channels

Our June 15th commitment to customers

Our status page failed you when you needed it most because our primary communication tools were affected by the outage. We are building backup communication channels that are fully independent to ensure we can always provide timely and transparent updates, even in a worst-case scenario.

Our approach

Our objective is to move as quickly as possible while providing a smooth transition for customer Status site integrations and without compromising our internal operational safeguards.

Where we are today

We immediately added CDN caching to the Heroku Status site for resiliency and optimized our page load state to eliminate the appearance of false negatives. We are methodically migrating our internal and customer-facing integrations to the Salesforce Trust site, including internal release gating, CLI, and App Metrics integrations. We are also working on a formalized backup incident communications channel for business continuity. From the process side, new Trust site templates and incident commander protocols have been prepared. Heroku has aligned with global incident commander protocols, which require an incident update cadence of at least one update every 30 minutes for active Sev-0 incidents, and at least one update every 60 minutes for Sev-1, and Sev-2 incidents. The Heroku Status site configuration will be fully migrated to the Salesforce Trust site. Beginning on Oct 10th, the Salesforce Trust site will serve as the primary channel for all incident and maintenance communications.

What customers should expect

Incident and Maintenance Notifications

Customers who are currently subscribed to the Heroku Status site will be sent an email to confirm their intent to remain subscribed to incident notifications. Any Status site subscribers that don’t explicitly opt out will be automatically subscribed to the new Trust site.

Status API Migration

We are working on a longer-term Status API migration strategy to minimize disruption for customers with Status API integrations. We will keep Heroku customers informed of future migration expectations, provide migration guidance, and ensure that a minimum of 30 days is provided for customers to migrate their Status API integrations.

Migration instructions and guidance

We will provide Status site migration updates and guidance through the following communication channels:

• Emails to Status site subscribers
• Heroku changelog
• Heroku DevCenter Status site page
• Heroku Status site scheduled maintenance event

Accelerating Investigation and Recovery

Our June 15th commitment to customers

The time it took to diagnose and resolve this incident was unacceptable. To address this, we are overhauling our incident response tooling and processes. This includes building new tools and improving existing ones to help engineers diagnose issues faster and run queries across our entire fleet at scale. We are also streamlining our “break-glass” procedures to ensure teams have rapid access to critical systems during an emergency and enhancing our monitoring to detect complex issues much earlier.

Where we are today

We enhanced our testing and monitoring to more effectively prevent, detect, and diagnose issues, including the addition of:

• Automated regression testing for dyno-to-dyno communications
• Canaries for long-running applications
• Additional monitoring and alerting for our monitoring and alerting orchestration service
• Streamlined monitoring for our platform log drain collection and forwarding service
• Improved introspection and monitoring for our customer notifications service

We are investigating the feasibility of monitoring operating system drift. Additionally, we plan to add canaries for dyno network connectivity.

To reduce the time to issue detection and remediation, we streamlined authorized engineers’ access to Private Spaces and dynos to conduct investigations. We are also working on safe processes at scale to expedite the detection and remediation of configuration-caused incidents.

We streamlined our “break-glass” tooling, and are in the process of revising related procedures for all core services.

Our ongoing commitment

We greatly appreciate the opportunity to serve our customers, and are committed to ensuring that this magnitude of outage and lapse in communications never happens again. We will continue to improve our processes, platform monitoring, performance, and resilience even after we have completed our identified corrective actions. We will keep you informed on the progress of pending corrective actions, including the Trust site migration.

The post Corrective Action Update for the Heroku June 10th Outage appeared first on Heroku.

This blog will take you through key Dreamforce highlights. Want a deeper dive? Need to book a meeting? Visit Heroku at Dreamforce for additional details, including featured sessions, special events, and opportunities to meet our experts.

The AI revolution presents a critical challenge: moving from experimentation to production. This year, Heroku has evolved beyond a traditional PaaS to become an AI PaaS, a fully managed platform designed to solve this problem and accelerate the delivery of AI-powered apps. With new capabilities like AppLink, Managed Inference and Agents, and MCP on Heroku, Heroku now provides a fully managed platform designed for the AI era.

This evolution accelerates the delivery of AI-powered apps and intelligent agents, bringing a new level of speed and simplicity to your development process. Dreamforce 2025 is your chance to see firsthand how the Heroku AI PaaS is delivering business value faster and with less complexity.

Here’s your Dreamforce guide to experiencing the new Heroku and unlocking its full potential.

See how customers are driving business impact with Heroku

Workday Supercharges BizOps with Agentforce & Heroku

Discover how Workday uses Agentforce & Heroku AppLink to create powerful automation for complex workflows, deliver transformative user experiences with intelligent agents, and streamline operations.

Audata Projects 50% Revenue Growth with Agentforce & Heroku

Discover how Audata used Heroku and Agentforce to launch a global media platform, resolve 60% of support cases with AI, and fuel 50% revenue growth by saving on DevOps costs.

AT&T Slashes Lead Delivery Time with Heroku & Salesforce

Learn how AT&T cut lead delivery from 48 hours to 15 minutes! See how it builds fast, scalable sales data systems for any industry, discovering new insights and reducing manual work.

How Salesforce Drives Productivity with Heroku & Slack

See how Salesforce uses Heroku to run Slack apps at scale for 80k+ employees, saving millions and cutting approval times from days to hours, freeing up resources to drive corporate goals.

Vestmark Increases DevOps Efficiency by 80% with Heroku

Vestmark optimized DevOps by 80% and accelerated new product development by 94%. Attendees will learn how it reduced operational burden, freed resources for innovation, and significantly saved costs.

Connect with Heroku experts

Heroku Happy Hour

Monday, October 13, 2025 | 6-9pm PDT | Madarae, San Francisco

Start your Dreamforce week off right. Join us for an evening of appetizers, cocktails, and music from our live DJ, all just a short walk from the Moscone Center.

Register Today

Salesforce Ben Breakfast Blend: Move Beyond the AI Hype

Wednesday, October 15, 2025 | 7:30-9:30am PDT | Fireside at Local Kitchen, San Francisco

Join our expert panelists for a lively discussion on how Agentforce and the new Heroku AppLink can solve your most critical business problems, drive integration, and enable innovation at scale.

Register Today

Get hands-on with Heroku

Go beyond the sessions with exclusive opportunities to get hands-on with the Heroku platform.

Unlock the future with Heroku at Dreamforce

Dreamforce isn’t just about talking AI—it’s about showing what’s possible for you to do today. With Heroku’s new AI PaaS capabilities, you’ll discover how to go beyond the hype and start building intelligent, real-world applications.

• Connect with Heroku leadership to explore strategy, business ROI, and our product roadmap.
• Get personalized puidance from our product experts on how to revolutionize your business with tools like AppLink and Agentforce
• Hear from customers firsthand how they are achieving dramatic results with Heroku’s AI capabilities

This is your chance to see how Heroku can transform the way you build and scale. Don’t miss it – request a meeting today to connect with Heroku experts at Dreamforce.

The post Discover How Heroku’s AI PaaS Delivers Real-World Results at Dreamforce appeared first on Heroku.

Building intelligent applications requires powerful, cost-effective AI. Today, we’re simplifying that process by making Amazon’s cutting-edge Nova models directly available via Heroku Managed Inference and Agents. Provisioning these models is as simple as attaching the add-on to your Heroku application, providing a direct, managed path for developers and businesses to leverage a new class of powerful and cost-effective AI models with unparalleled simplicity.

Heroku AI: balancing performance and cost with Nova models

The Amazon Nova family of models is engineered to provide an exceptional balance of performance and cost. Both nova-pro and nova-lite are optimized for modern development patterns like Retrieval-Augmented Generation (RAG) and building powerful AI agents.

While these models have powerful multimodal capabilities, our initial integration on Heroku focuses on their robust text-to-text functionality. Support for multimodal capabilities will be introduced in a future release.

Model comparison at a glance

nova-pro: for demanding, high-accuracy tasks

The nova-pro model is optimized for complex scenarios where accuracy and deep reasoning are critical. It excels at processing and reasoning over vast amounts of information, making it exceptionally well-suited for tasks that require a deep understanding of extensive context.

Use cases:

• Financial document analysis: Analyze the full scope of lengthy financial reports or contracts in a single pass.
• Sophisticated agentic workflows: Build autonomous agents that can maintain context across many steps and tool interactions.

nova-lite: for high-throughput, real-time applications

The nova-lite model is built for speed. It delivers rapid, low-cost inference, making it the ideal choice for high-volume applications that require immediate responsiveness, while still handling significant contextual information.

Use cases:

• Interactive customer support: Power intelligent chatbots that can recall long conversation histories to provide personalized support.
• Live document processing: Instantly classify and extract data from large documents as they are uploaded.

From text generation to action: powerful tool use with Nova and Heroku

What truly sets these models apart is their powerful ability to move beyond text and take action. Both nova-pro and nova-lite have tool use (also known as function calling) capability. This feature allows the models to go beyond generating text and interact with external systems.

Simplified by Heroku Managed Inference and Agents

We’ve made connecting these models to your apps seamless. Just attach the Heroku Managed Inference and Agents add-on, and you are ready to go. Heroku simplifies the operation with these models by providing two powerful, purpose-built endpoints:

An OpenAI-compatible endpoint: For straightforward chat and text-generation tasks, use the familiar /v1/chat/completions endpoint. This allows for easy integration with existing codebases and libraries designed for the OpenAI API.

A powerful agents endpoint: To build more sophisticated agentic workflows, the /v1/agents/heroku endpoint provides native support for both built-in Heroku tools (like running code or querying a database) and custom tools via the Model Context Protocol (MCP). This makes it simple to create AI agents that can take action within your application ecosystem.

This dual-endpoint approach gives you the flexibility to choose the right level of abstraction for your needs, from simple text generation to complex, multi-step agentic tasks.

Getting started

You can provision Nova models in both the US and EU regions. To attach a model to your application, simply attach the Heroku Managed inference and Agents addon or use the Heroku CLI. For example, to provision the nova-pro model:

heroku addons:create heroku-inference:nova-pro -a your-app-name

From there, your application is ready to start making calls to the model and building the next generation of intelligent, responsive applications.

The post Amazon Nova Models: Now Available on Heroku appeared first on Heroku.

Start building with OpenAI’s new open-weight model, gpt-oss-120b, now available on Heroku Managed Inference and Agents. This gives developers a powerful, transparent, and flexible way to build and deploy AI applications on the platform they already trust. Access gpt-oss-120b with our OpenAI-compatible chat completions API, which you can drop into any OpenAI-compatible SDK or framework.

Why gpt-oss-120b matters for the AI community and enterprise teams

OpenAI has released gpt-oss-120b as part of its new family of open-source models. This 120-billion parameter model and a Mixture-of-Experts (MoE) architecture are designed for a wide range of text generation and understanding tasks. It represents a significant step forward in making powerful AI more accessible to the developer community. Key features of the gpt-oss-120b include:

• Open Weight: As an open-weight model, developers can inspect the model’s architecture, understand its inner workings, and fine-tune it for specific use cases. The weights are released under a permissible Apache 2.0 license
• Architecture: The model uses a Mixture-of-Experts (MoE) architecture, which allows it to be highly performant while remaining computationally efficient. With 117 billion total parameters, it only activates 5.1 billion per token, enabling it to run on a single 80GB GPU.
• Designed for Agentic Workflows: The model was built with tool use in mind, demonstrating strong capabilities in instruction following, function calling, and executing tasks like web searches and running Python code.

Performance and benchmarks

According to OpenAI, the gpt-oss-120b model delivers performance that is competitive with, and in some cases exceeds, their proprietary o4-mini model. Early benchmark results show that gpt-oss-120b matches or surpasses o4-mini and other open weight models such as DeepSeek and Qwen3.

While official benchmarks are strong, early community feedback is still emerging, with some users reporting excellent results in reasoning, scientific research, and tool-assisted tasks.

gpt-oss-120b on Heroku: simplifying AI infrastructure

With Heroku Managed Inference and Agents, your team can:

• Deploy gpt-oss-120b with zero infrastructure overhead
• Call the model securely from your Heroku apps
• Build agents that take action, run code, and fetch data in real time
• Monitor and scale inference as usage grows

And because it’s built into the Heroku platform, your team avoids the cost and complexity of managing and provisioning inference.

Transparent pricing for scalable AI

The pricing for gpt-oss-120b is designed to allow you to scale your applications cost-effectively.

• Input Tokens: $0.15 per million tokens
• Output Tokens: $0.60 per million tokens

Get started today with gpt-oss-120b on Heroku

The gpt-oss-120b model is now available in the Heroku Managed Inference and Agents add-on, which can be added from the Elements Marketplace.

Ready to build? Get Started with Heroku Managed Inference and Agents today.

We look forward to seeing what you create.

The post Heroku AI Expands Model Offering with OpenAI’s gpt-oss-120b appeared first on Heroku.

Building AI applications that can interact with private data is a common goal for many organizations. The challenge often lies in connecting large language models (LLMs) with proprietary datasets. A combination of Heroku Managed Inference and Agents and LlamaIndex provides an elegant stack for this purpose.

This post explores how to use these tools to build retrieval-augmented generation (RAG) applications. We’ll cover the technical components, Use Cases and the development process, and how to get started.

LlamaIndex for data orchestration

LlamaIndex is an open-source framework for building context-aware LLM applications. Its core function is to orchestrate a retrieval-augmented generation (RAG) pipeline, which manages the entire data lifecycle for your application.

It uses data connectors from LlamaHub to ingest information from various sources (like Slack, Notion, Google Docs, or APIs), indexes that data into a searchable knowledge base, and then retrieves the most relevant context to help an LLM answer user queries accurately. In essence, it makes your private data accessible and useful for the LLM.

Heroku AI for managed inference

Heroku is an AI PaaS designed to simplify building, deploying, and scaling AI applications. Heroku AI provides several primitives useful for RAG applications

• Managed Inference for models like Anthropic’s Claude Sonnet through a OpenAI compatible API
• Embedding models like Cohere’s Embed Multilingual to convert text data into vector representations for search.
• The pgvector extension for Heroku Postgres enables vector search capabilities, allowing it to function as a vector store.
• Heroku also provides an easy way to access data using Model Context Protocol (MCP) and AppLink to securely connect to your Salesforce org

Understanding retrieval-augmented generation (RAG)

Retrieval-augmented generation (RAG) is a technique that improves LLM outputs by providing them with relevant information retrieved from an external knowledge base. Instead of relying solely on its pre-trained data, the LLM can reference this external data before generating a response.

Common use cases for RAG and agents

The value of this stack becomes clear when applied to specific business problems that involve querying large volumes of documents.

• In financial analysis, professionals can bypass the time-consuming manual search of dense reports and instead use the RAG system to receive a synthesized answer with the relevant context retrieved directly from the document.
• The insurance industry can build powerful agents. For example, an agent could be tasked with assessing a claim for hail damage. It would first use a RAG tool to retrieve the specifics of the customer’s auto policy from a knowledge base. Then, it might use a weather data API as a second tool to verify if a hailstorm was reported in the customer’s location on the specified date. Finally, the agent would synthesize these findings to determine if the policy covers the event and generate a summary for a human adjuster.
• For customer support and internal knowledge, RAG can power chatbots built on top of scattered knowledge bases like FAQs and HR policies.

Building a RAG application with Heroku AI and LlamaIndex

The integration between LlamaIndex and Heroku Managed Inference and Agents streamlines the development of RAG applications.

First, provision the necessary Heroku resources: a Postgres database with pgvector, a Claude 4 Sonnet model for inference, and Cohere model for embeddings.

heroku addons:create heroku-postgresql:essential-0 --app your-app-name --wait 
heroku pg:psql --command "CREATE EXTENSION vector" --app your-app-name
heroku addons:create heroku-managed-inference:claude-4-sonnet --as INFERENCE --app your-app-name  
heroku addons:create heroku-managed-inference:cohere-embed-multilingual --as EMBEDDING --app your-app-name 

Next, use LlamaIndex in your Python application to connect to these services. Since Heroku provides an OpenAI-compatible API for its embedding service, we can use LlamaIndex’s OpenAILikeEmbedding class by pointing it to the correct Heroku environment variables.

from llama_index.llms.heroku import Heroku
from llama_index.embeddings.openai_like import OpenAILikeEmbedding
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext
from llama_index.vector_stores.postgres import PGVectorStore
from sqlalchemy import make_url
import os

llm = Heroku()

# Use OpenAILikeEmbedding class pointed at Heroku's service
# It reads the EMBEDDING_URL, EMBEDDING_KEY, and EMBEDDING_MODEL_ID from env vars
embed_model = OpenAILikeEmbedding(
    api_base=os.environ.get("EMBEDDING_URL") + "/v1",
    api_key=os.environ.get("EMBEDDING_KEY"),
    model=os.environ.get("EMBEDDING_MODEL_ID")
)

# Load data from a local directory
documents = SimpleDirectoryReader("your_data_directory").load_data()

# Connect to the Heroku Postgres database with pgvector support
# The DATABASE_URL config var is automatically set by Heroku and contains the connection string
# We need to parse the connection string and pass it to the PGVectorStore
database_url = os.environ.get("DATABASE_URL").replace(
    "postgres://", "postgresql://")
url = make_url(database_url)
vector_store = PGVectorStore.from_params(
    database=url.database,
    host=url.host,
    port=url.port,
    user=url.username,
    password=url.password,
    table_name="my_vector_table",
    embed_dim=1024  # Cohere embeddings have a dimension of 1024
)

# Create a storage context to store the index
storage_context = StorageContext.from_defaults(vector_store=vector_store)

# Create the index, which will embed and store the documents
index = VectorStoreIndex.from_documents(
    documents,
    vector_store=vector_store,
    embed_model=embed_model,
    storage_context=storage_context
)

# Create a query engine to interact with the data
query_engine = index.as_query_engine(llm=llm)
response = query_engine.query("What is the main takeaway from my documents?")
print(response)

This code snippet demonstrates how to load documents, create embeddings with Cohere, store them in pgvector, and query them with Claude Sonnet 4, all orchestrated by LlamaIndex on Heroku.

You can find a complete and deployable version of the previous code snippet in our Heroku Reference Applications repository.

Start building with Heroku AI and LlamaIndex

The combination of Heroku Managed Inference and Agents, and LlamaIndex provides a practical toolset for building data-aware AI applications. This stack allows developers to build applications that leverage private data sources with managed infrastructure. For developers building AI applications that require integration with proprietary data, the Heroku and LlamaIndex stack offers a great solution.

The post Building Data-Aware AI Applications with Heroku AI and LlamaIndex appeared first on Heroku.

Building production-grade AI applications can be complex, but with Heroku and Pydantic AI, developers gain a powerful and reliable solution for integrating advanced AI capabilities. Heroku makes it easy to integrate AI into your applications with Heroku Managed Inference and Agents. With a single click, you can attach powerful Large Language Models like Anthropic’s Claude 4 Sonnet to your apps. Heroku AI also provides built-in tools like secure code execution and an OpenAI-compatible API that you can drop directly into popular frameworks and SDKs.

Complementing this, Pydantic AI is a Python agent framework designed to make it less painful to build production-grade applications with Agents. Just as FastAPI revolutionized web development with an ergonomic design built on Pydantic validation, Pydantic AI aims to bring that same reliability and developer experience to agent development. Since virtually every agent framework in Python already uses Pydantic for validation, Pydantic AI leans into this foundation to provide a familiar and robust experience.

Together, this combination empowers developers with advanced tooling and extensibility, including support for the Model Context Protocol (MCP) and Agent2Agent (A2A) protocol, facilitating complex, modular agentic workflows that are truly ready for enterprise demands.

Using Heroku Managed Inference and Agents with Pydantic AI

To use Heroku Managed Inference and Agents with Pydantic AI, you can use the dedicated HerokuProvider. You can set the INFERENCE_KEY and INFERENCE_URL environment variables to set the API key and base URL, respectively. The HerokuProvider will automatically use them.

export INFERENCE_KEY='your-heroku-api-key'
export INFERENCE_URL='https://us.inference.heroku.com'

With the environment variables set, you can configure the Pydantic AI agent.

from pydantic_ai import Agent
from pydantic_ai.models.openai import OpenAIModel
from pydantic_ai.providers.heroku import HerokuProvider

model = OpenAIModel(
    'claude-4-sonnet',
    provider=HerokuProvider(api_key='your-heroku-inference-key'),
)
agent = Agent(model)

Model Context Protocol (MCP)

Heroku Managed Inference and Agents supports built in tools as well as tool calling via MCP. Pydantic AI also supports the Model Context Protocol (MCP), enabling agentic workflows.

1. MCP Client: Pydantic AI agents can act as an MCP Client, connecting to MCP servers to use their tools. Learn more…
2. MCP Server: Agents can be exposed as MCP servers, allowing other agents to use them as tools. Learn more…

Agent2Agent Protocol (A2A)

Pydantic has also built the FastA2A library to simplify implementing the A2A protocol in Python. You can conveniently expose a Pydantic AI agent as an A2A server with just a few lines of code.

from pydantic_ai import Agent
agent = Agent('HerokuProvider:claude-4-sonnet', instructions='Be fun!')
app = agent.to_a2a()

You can run the example with uvicorn:

uvicorn agent_to_a2a:app --host 0.0.0.0 --port 8000

This will expose the agent as an A2A server, ready to receive requests. See more about exposing Pydantic AI agents as A2A servers.

Again, to get started with Heroku AI, provision Managed Inference and Agents from Heroku Elements or via the command line. We are excited to see what you build with Heroku AI and Pydantic.

Join the official Heroku AI Trailblazer Community to keep up with the latest news, ask questions, or meet the team. To learn more about Heroku AI, check out our Dev Center docs and try it out for yourself.

The post Building Agents With Heroku AI and Pydantic AI appeared first on Heroku.

This blog series has taken you on a journey through the world of AppLink, from its foundational concepts and core components in Heroku AppLink: Extend Salesforce with Any Programming Language, to a deep dive into its key integration patterns in AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications, and then we explored advanced integrations with Data Cloud, automation, and AI in AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI. Now, in this final installment, we turn our attention to the practical aspects of building with AppLink, focusing on the development workflow, including local testing and managing changes to the OpenAPI specification, and crucial considerations when choosing the best programming language for your Salesforce extensions.

Tell me more about integrating with Agentforce?

Agentforce integration leverages AppLink’s full computational flexibility to extend agent capabilities far beyond native Salesforce functionality. Due to the compute power and framework availability at developers’ disposal, agents can return rich content – not just text data – including generated images, PDFs, complex calculations, and processed data from external APIs.

The Heroku Agentforce Tutorial provides comprehensive step-by-step guidance for creating custom Agent Actions, from initial setup through production deployment.

Real-world example: Automotive finance agent

Car dealership agents need to provide instant, competitive finance estimates that consider complex pricing rules, customer credit profiles, and generate professional documentation. Here’s how a Koa Cars Finance Agent performs real-time credit assessments, applies complex pricing rules, and generates professional PDF agreements:

Customer: Finance estimate request
    ↓
Agent: "What's your contact email?"
    ↓
Customer: "[email protected]"
    ↓
Agent: "Which car model interests you?"
    ↓
Customer: "I'm interested in the Zig M3 car"
    ↓
Agent: Calls Heroku Finance Service

The service also automatically generates a professional PDF finance agreement:

This demonstrates AppLink’s capability to handle complex business logic including multi-tier interest rate calculations, real-time credit assessments, dynamic pricing with dealer incentives, and automatic PDF generation – all while seamlessly integrating with Salesforce CRM data.

Enhanced OpenAPI configuration for agent actions

Agentforce requires additional OpenAPI YAML attributes beyond standard external service configuration. AppLink automatically handles these specialized requirements when you include the appropriate x-sfdc agent extensions:

x-sfdc:
  agent:
    topic:
      classificationDescription: "This API allows agents to calculate automotive finance estimates, assess credit profiles, and generate professional documentation."
      scope: "Your job is to assist customers with vehicle financing by providing instant competitive estimates, applying complex pricing rules, and generating finance agreements."
      instructions:
        - "If the customer asks for finance estimates, collect contact email and vehicle model information."
        - "Use real-time credit assessment and dealer-specific pricing rules for accurate calculations."
        - "Generate professional PDF agreements and attach them to Contact records automatically."
      name: "automotive_finance_topic"
    action:
      publishAsAgentAction: true
      isUserInput: true
      isDisplayable: true
  privacy:
    isPii: true

These extensions enable:

• Agent Topic Generation: Creates logical groupings of related actions for agent organization – agent topics help agents understand when and how to use your services
• Action Publishing: Automatically makes your endpoints available as Agent Actions within the defined topic
• User Input Configuration: Controls whether fields require additional user input
• Display Configuration: Determines which response fields are shown to users
• Privacy Controls: Enables PII handling for sensitive operations

For complete details on OpenAPI configuration for Agentforce, see Configuring OpenAPI Specification for Heroku AppLink.

Development flow

The AppLink development workflow supports rapid iteration across Salesforce environments, from scratch orgs to production deployments. Understanding the development tools and processes ensures smooth implementation and reliable deployments.

Local development

Local development with AppLink focuses on testing Pattern 2 applications (Extending Salesforce) that receive requests from Salesforce. Pattern 1 applications (API access) don’t require special local testing since they make outbound calls to Salesforce APIs directly.

The invoke.sh script (found in /bin folders of sample applications) simulates requests from Salesforce with the correct headers, enabling local development and testing before deployment. For example, see the Pattern 3 invoke.sh script for testing batch operations locally.

Usage: ./bin/invoke.sh    [session-based-permission-set]

The script provides several key features for development workflow:

• User Authentication Simulation: The script uses the Salesforce CLI to extract org details including access tokens, API versions, and org identifiers. It constructs the required x-client-context header with base64-encoded JSON containing authentication and context information that your application would receive from Salesforce in production.
• Permission Set Testing: For applications requiring elevated permissions (user mode plus), the script supports session-based permission set activation through a third parameter. It automatically creates and removes SessionPermSetActivation records, allowing developers to test permission-dependent functionality locally before deploying to environments where these permissions would be granted through Flows, Apex, or Agentforce configurations.
• Request Payload Simulation: The script accepts JSON payloads as parameters, enabling testing of various request scenarios and edge cases. This capability is essential for validating business logic and error handling before moving to integration testing.

To use the invoke.sh script for local testing, authenticate with your target org using the Salesforce CLI, then execute the script with your org alias and request payload:

# Authenticate with your Salesforce org
sf org login web --alias my-org

# Install dependencies and start local development server
npm install
npm run dev  # or npm start depending on your package.json scripts

# In a separate terminal, test locally with simulated Salesforce headers
./bin/invoke.sh my-org 'https://localhost:8080/api/generatequote' '{"opportunityId": "006am000006pS6P"}'

This local development workflow integrates seamlessly with your existing Node.js development tools – use nodemon for auto-reloading, your preferred debugger, and standard logging libraries. The invoke.sh script is language and framework agnostic, working with any technology stack you choose for your Heroku application.

Managing changes to the OpenAPI specification

Managing changes in the interface between your Heroku application and Salesforce requires careful attention to the OpenAPI specification file that defines your service contract. This specification serves as the single source of truth for both your application’s API endpoints and the Salesforce components that consume them.

When developing new features or modifying existing endpoints, maintaining specification alignment prevents breaking changes that could disrupt dependent Salesforce components. The OpenAPI specification defines not only the request and response schemas but also the HTTP methods, status codes, and error formats that your consuming Flows, Apex classes, or Agentforce Actions expect.

Salesforce enforces this alignment through validation during the publish process. If you attempt to publish an updated application with breaking changes to an existing specification, and there are active Apex classes, Flows, or Agentforce Actions referencing those endpoints, the publish command will fail with validation errors. This protection mechanism prevents accidental service disruptions in production environments.

For development environments where you need to iterate rapidly on service interfaces, scratch orgs provide the flexibility to start fresh when needed. However, if you’re working with persistent sandboxes or production environments, you have two options when breaking changes are necessary: either remove all references to the modified endpoints from your Flows, Apex classes, and Agentforce Actions before publishing, or use a different client name parameter in the CLI publish command to create a parallel service definition, for example --client-name MyService_v2.

Using scratch orgs

Scratch orgs represent the optimal development environment for AppLink applications, particularly when your service interfaces change frequently during development. Unlike traditional sandboxes, scratch orgs provide a clean, disposable environment that can be recreated as needed when breaking changes occur or when you need to test deployment scenarios from ground zero.

The key advantage of scratch orgs for AppLink development lies in their ability to start fresh without the complexity of cleaning up existing references, published applications, or permission configurations. When your service evolves significantly, you can create a new scratch org, configure the necessary features, and test your complete deployment pipeline without worrying about conflicts from previous iterations.

To configure a scratch org for AppLink development, you must enable the required features in your scratch org definition file. For standard Salesforce integration, include the HerokuAppLink feature in your project’s config/project-scratch-def.json:

{
  "orgName": "AppLink Development",
  "edition": "Developer",
  "features": ["HerokuAppLink"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    }
  }
}

For Data Cloud integration scenarios, also include the CustomerDataPlatform feature alongside HerokuAppLink. Once configured, create and authenticate with your scratch org using standard Salesforce CLI commands, then proceed with your AppLink connection and deployment workflow.

Scratch orgs excel in scenarios where you’re developing new integration patterns, testing permission model changes, or validating deployment automation. They provide the confidence that your deployment process works correctly from a clean state, which is essential for production readiness. While traditional sandboxes remain valuable for longer-term testing scenarios and stakeholder demonstrations, scratch orgs offer the rapid iteration cycle that modern development practices require.

CI/CD integration

The JWT-based authentication flow (heroku salesforce:connect:jwt) integrates seamlessly with scratch org workflows, enabling automated connection setup as part of your CI/CD pipeline. This capability allows you to script complete environment provisioning, from scratch org creation through application deployment and testing, providing reproducible development environments for your entire team.

Coding language choices

When extending Salesforce functionality, choosing the right programming language depends on your specific requirements, team expertise, and operational constraints. While Apex remains a powerful option for many scenarios, AppLink opens up the entire spectrum of modern programming languages, each bringing unique capabilities and development ecosystems to your Salesforce solutions.

The following comparison helps you understand the tradeoffs between Apex and other programming languages when building Salesforce extensions, highlighting where each approach excels and the specific capabilities that become available when hosting code on Heroku using the AppLink add-on. Consider using Apex for transaction-critical operations requiring database triggers and system-level access, while leveraging AppLink and modern programming languages for computationally intensive tasks, external integrations, and scenarios where existing code investments can be preserved and extended.

Capability	Apex	Node.js, Python, Java…*
Fully Managed Trusted Infrastructure
Extend Apex, Flow and Agentforce
Record Update Logic in Transaction		Triggers not supported
Secure by Default	With Annotations
Run as User	With Annotations
Run as System	Default	Principle of Least Privilege**
Limits Handling	Fixed CPU Timeout, Heap and Concurrency Limits	Elastic Horizontal and Vertical Scale***
Extend Existing Code Investment	N/A

* Capabilities only available when hosting code on Heroku using the Heroku AppLink Add-on

** Heroku logic can leverage Session-based Permission Sets to elevate beyond user permissions

*** Salesforce API limits still apply; use Unit of Work patterns to make optimal use of updates

AppLink also enables developers with skills in your wider organization or hiring pool to contribute to Salesforce programs using languages they’re already proficient in, expanding your team’s ability to deliver sophisticated Salesforce extensions without requiring specialized Apex training.

Summary

AppLink represents a fundamental shift in how developers can extend Salesforce, breaking through traditional platform limitations to bring unlimited computational flexibility to the Salesforce ecosystem. With enterprise-grade security through User Mode authentication, seamless integration where Heroku applications appear natively within Salesforce through generated Apex classes, Flow actions, and Agentforce capabilities, and support for unlimited language choice in Node.js, Python, Java, and other languages, AppLink bridges the gap between Salesforce’s declarative power and unlimited programming flexibility.

Whether you’re extending core CRM functionality, building sophisticated agent actions, or integrating with external systems, AppLink provides the foundation for enterprise-grade Salesforce extensions using the languages and frameworks you know best.

Read More of the AppLink Fundamentals series

1. AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications
2. AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI
3. AppLink Fundamentals III: Building with AppLink – Development Flow and Language Choices

The post AppLink Fundamentals III: Building with AppLink – Development Flow and Language Choices appeared first on Heroku.

In our previous posts, we introduced Heroku AppLink and explored its foundational integration patterns for connecting Heroku applications with Salesforce. Now, we’ll delve into how AppLink truly expands Salesforce capabilities, focusing on advanced integrations with Data Cloud, Flow, Apex, and Agentforce. This blog will highlight how AppLink empowers you to infuse your Salesforce orgs with powerful external logic, real-time data processing, and intelligent automation.

Extending Salesforce automation, code, and AI

Once your Heroku application is deployed and connected using AppLink, it becomes available for invocation from Apex, Flow, and Agentforce. The key to this integration is the OpenAPI specification that describes your endpoints, enabling automatic service discovery and registration in Salesforce.

OpenAPI specification integration

AppLink uses your OpenAPI (YAML or JSON) specification to understand your service capabilities and generate the appropriate Salesforce integration artifacts. Here’s an example from the Pattern 2 sample showing how the generateQuote operation is defined:

components:
  schemas:
    QuoteGenerationRequest:
      type: object
      required:
        - opportunityId
      description: Request to generate a quote, includes the opportunity ID to extract product information
      properties:
        opportunityId:
          type: string
          description: A record Id for the opportunity

paths:
  /api/generatequote:
    post:
      operationId: generateQuote
      summary: Generate a Quote for a given Opportunity
      description: Calculate pricing and generate an associated Quote.
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/QuoteGenerationRequest"
      x-sfdc:
        heroku:
          authorization:
            connectedApp: GenerateQuoteConnectedApp
            permissionSet: GenerateQuotePermissions
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/QuoteGenerationResponse"

The x-sfdc section contains Salesforce-specific metadata that AppLink uses to configure authentication and permissions. When you run heroku salesforce:publish, this specification becomes:

• Generated Apex classes with strongly-typed request/response objects
• External Service definitions visible in Flow Builder’s Action palette
• Agent Actions available for Agentforce configuration
• Connected App and Permission Set configurations for secure access

Rather than writing OpenAPI specifications manually (which can be tedious and error-prone), most AppLink samples leverage the schema definition features already built into popular Node.js frameworks. The Pattern 2 sample uses Fastify’s schema system to automatically generate the specification, but similar approaches work with Express.js using libraries like swagger-jsdoc or express-openapi:

// From heroku-applink-pattern-org-action-nodejs/src/server/routes/api.js
const quoteGenerationSchema = {
  operationId: 'generateQuote',
  summary: 'Generate a Quote for a given Opportunity',
  'x-sfdc': {
    heroku: {
      authorization: {
        connectedApp: 'GenerateQuoteConnectedApp',
        permissionSet: 'GenerateQuotePermissions'
      }
    }
  },
  body: { $ref: 'QuoteGenerationRequest#' },
  response: {
    200: { schema: { $ref: 'QuoteGenerationResponse#' } }
  }
};

This approach ensures your API documentation stays synchronized with your implementation while providing the metadata Salesforce needs for seamless integration.

Invoking from Apex

AppLink enables both synchronous and asynchronous invocation from Apex:

Synchronous Invocation: Your Heroku service appears as a generated Apex class that you can invoke directly:

// From heroku-applink-pattern-org-action-nodejs sample
HerokuAppLink.GenerateQuote service = new HerokuAppLink.GenerateQuote();
HerokuAppLink.GenerateQuote.generateQuote_Request request = new HerokuAppLink.GenerateQuote.generateQuote_Request();
HerokuAppLink.GenerateQuote_QuoteGenerationRequest body = new HerokuAppLink.GenerateQuote_QuoteGenerationRequest();
body.opportunityId = '006SB00000DItEfYAL';
request.body = body;
System.debug('Quote Id: ' + service.generateQuote(request).Code200.quoteId);

The generated classes handle authentication, serialization, and HTTP communication automatically. Synchronous calls are subject to Apex callout limits and timeout constraints.

Asynchronous Invocation with Callbacks: For long-running operations beyond Apex governor limits, AppLink supports asynchronous processing with callback handling. This requires additional OpenAPI specification using the standard callbacks definition to define the callback endpoint that Salesforce will invoke when processing completes.

This pattern enables background processing workflows where your Heroku application can perform extensive calculations or external API integrations without blocking the Salesforce user interface. For detailed callback configuration examples, see Getting Started with AppLink and Pattern 3: Scaling Batch Jobs.

Invoking from Flow

Flow Builder provides no-code access to your Heroku applications through External Service Actions. After publishing your service, it appears automatically in the Action palette:

Flow Builder integration

Flow developers can drag your Heroku operation onto the canvas, configure input variables, and capture output data just like any other Flow action. This enables sophisticated business automation combining Salesforce’s declarative tools with your custom processing logic.

Invoking from Agentforce

Agentforce leverages your Heroku applications as Agent Actions organized within Agent Topics through the enhanced OpenAPI configuration detailed in the dedicated Agentforce section below. Once configured with the appropriate x-sfdc agent extensions, agents can automatically invoke your Heroku endpoints to fulfill user requests requiring specialized processing, external API calls, or complex calculations beyond native Salesforce capabilities.

Permission elevation and security

AppLink operates using User Mode authentication, meaning your code inherits the exact permissions of the Salesforce user who triggers the operation. This provides the most secure integration by following the principle of least privilege.

However, for scenarios where your application needs to access data or perform operations beyond the triggering user’s permissions, AppLink supports elevated permissions (known as “user mode plus” in the main documentation) through Permission Sets. This optional advanced feature allows administrators to grant specific additional permissions that are activated exclusively during code execution.

For example, your Heroku application might need to access sensitive discount override fields that regular users cannot see, or create records in objects where users have read-only access. The Permission Set approach ensures these elevated permissions are:

• Explicitly defined and administrator-controlled
• Only active during Heroku application execution
• Visible through standard Salesforce Permission Set management
• Applied temporarily without changing the user’s permanent permissions

For detailed implementation guidance including permission set configuration and testing approaches, see the Pattern 2 sample documentation.

What’s next?

This blog has explored how AppLink facilitates advanced integrations with Salesforce, extending capabilities across Data Cloud, automation with Flow and Apex, and intelligent interactions with Agentforce. We’ve seen how OpenAPI specifications streamline service discovery and how AppLink’s permission model offers granular control over elevated access.

In our final blog, we’ll shift focus to the practical aspects of the development workflow, including local testing, managing OpenAPI changes, and crucial considerations when choosing between Apex and other programming languages for your Salesforce extensions. Stay tuned for insights into building and deploying your AppLink solutions with confidence.

Read More of the AppLink Fundamentals series

1. AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications
2. AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI
3. AppLink Fundamentals III: Building with AppLink – Development Flow and Language Choices

The post AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI appeared first on Heroku.

In our previous post, we introduced AppLink as a powerful new way to extend Salesforce with any programming language at any scale, detailing its core components and overarching benefits. Now, we’ll dive deeper into the practical application of AppLink by exploring its primary integration patterns. Understanding these patterns is key to leveraging AppLink effectively, as they dictate how your Heroku applications interact with and enhance your Salesforce orgs.

Usage patterns

AppLink supports four proven integration patterns, but we’ll focus on the two primary patterns that represent the main integration approaches – the other two patterns are variations of these same foundational concepts. Note that these patterns align with AppLink’s three official user modes: Pattern 1 corresponds to “run-as-user mode”, while Pattern 2 uses both “user mode” and “user mode plus” (for elevated permissions). Let’s explore both core patterns with their specific architectures and implementation approaches.

Pattern 1: Salesforce API access

This pattern uses run-as-user mode authentication, which enables system-level operations with consistent, predictable permissions by using a specific designated user’s context. This approach is ideal for automated processes and customer-facing applications that require stable permission sets and don’t depend on the triggering user’s access level. Run-as-user authorizations allow your Heroku applications to access Salesforce data across multiple orgs with the permissions of the designated user.

For a Heroku application that accesses Salesforce APIs, you need:

• AppLink Add-on: heroku addons:create heroku-applink
• AppLink CLI Plugin: Install the Heroku CLI plugin for deployment commands
• Org Login: An org login for a user with the ‘Manage Heroku Apps’ permission
• AppLink SDK (optional): For your chosen language to simplify integration

Here’s the complete command sequence for deploying and connecting a Node.js application with Salesforce API access, adapted from our Pattern 1 sample:

# Create and configure Heroku app
heroku create
heroku addons:create heroku-applink --wait
heroku buildpacks:add heroku/nodejs
heroku config:set HEROKU_APP_ID="$(heroku apps:info --json | jq -r '.app.id')"

# Connect to Salesforce org(s) using run-as-user mode
heroku salesforce:authorizations:add my-org
heroku config:set CONNECTION_NAMES=my-org

# Deploy application
git push heroku main
heroku open

Your application retrieves named authorizations and performs SOQL queries across multiple Salesforce orgs. The SDK simplifies multi-org connectivity through the AppLink add-on, which manages authentication and connection pooling automatically.

The first step in your Node.js application is initializing the AppLink SDK and retrieving a specific named authorization. This follows familiar Node.js patterns where connection details are managed through environment variables:

// From heroku-applink-pattern-api-access-nodejs/index.js
const sdk = init();

// Get connection names from environment variable  
const connectionNames = process.env.CONNECTION_NAMES ? 
  process.env.CONNECTION_NAMES.split(',') : []

// Initialize connection for specific org
const org = await sdk.addons.applink.getAuthorization(connectionName.trim())
console.log('Connected to Salesforce org:', {
  orgId: org.id,
  username: org.user.username
})

Once you have an org connection, executing SOQL queries becomes straightforward using the Data API. The SDK handles authentication, session management, and provides structured responses that are easy to work with:

// Execute SOQL query using the Data API
const queryResult = await org.dataApi.query('SELECT Name, Id FROM Account')
console.log('Query results:', {
  totalSize: queryResult.totalSize,
  done: queryResult.done,
  recordCount: queryResult.records.length
})

// Transform the records to expected format
const accounts = queryResult.records.map(record => ({
  Name: record.fields.Name,
  Id: record.fields.Id
}))

For Java developers, refer to the SalesforceClient.java class in the Java Pattern 1 sample for equivalent functionality. This implementation directly uses the AppLink API endpoint GET /authorizations/{connection_name} as described in the AppLink API documentation, demonstrating how to integrate without the SDK by making HTTP calls to ${HEROKU_APPLINK_API_URL}/authorizations/{developerName} with Bearer token authentication.

When you run the sample application locally or deploy it to Heroku, the code above produces a web interface that displays Account records from your connected Salesforce orgs. The application demonstrates both single-org and multi-org connectivity, with automatic authentication handling through the AppLink add-on:

The interface shows Account records from each connected org, along with connection details and bulk API capabilities. This demonstrates how AppLink simplifies multi-org data access patterns that would otherwise require complex OAuth flows and session management.

Pattern 2: Extending Salesforce

This pattern enables Salesforce users to invoke your Heroku applications directly from within Salesforce through Flow, Apex, or AgentForce. Your application becomes a published service that extends Salesforce capabilities across Lightning Experience, Sales Cloud, Service Cloud, and other Salesforce products. By publishing your application through AppLink, you’re extending the Salesforce platform with custom business logic that users can seamlessly access from their familiar Salesforce interface.

This pattern uses User Mode authentication, which provides the most secure integration by inheriting the exact permissions of the Salesforce user who triggers the operation. Additionally, User Mode supports elevated permissions (known as “user mode plus” in the main documentation) that are granted exclusively during code execution through Permission Sets. This allows your Heroku application to perform operations that the triggering user cannot normally perform, with admin-approved elevated permissions visible through Permission Sets in the org.

For a Heroku application designed to be invoked by Salesforce, you need:

• AppLink Add-on: heroku addons:create heroku-applink
• AppLink Buildpack: heroku buildpacks:add --index=1 heroku/heroku-applink-service-mesh
• AppLink CLI Plugin: Install the Heroku CLI plugin for deployment commands
• OpenAPI YAML file: Describing your HTTP endpoints for Salesforce discovery
• Org Login: An org login for a user with the ‘Manage Heroku Apps’ permission
• AppLink SDK (optional): For your chosen language to simplify integration
• Procfile Configuration: To inject the service mesh for authentication

The deployment process requires an api-docs.yaml file that describes your HTTP endpoints using the OpenAPI specification format. This file serves as the bridge between your Heroku application and Salesforce, enabling automatic generation of Apex classes, Flow actions, and Agentforce integrations. The YAML file contains both standard API documentation and Salesforce-specific metadata that controls authentication and permissions – we’ll explore its structure and contents in detail later in this blog.

The following command sequence installs the AppLink add-on, configures a buildpack that injects a request interceptor known as the service mesh (which handles authentication and blocks external access), and establishes the secure connection between your Heroku application and Salesforce org. Note that Pattern 2 uses salesforce:connect to create connections (for app publishing) rather than salesforce:authorizations:add used in Pattern 1 (for data access). This deployment and connection process is adapted from our Pattern 2 sample:

# Create and configure Heroku app
heroku create
heroku addons:create heroku-applink
heroku buildpacks:add --index=1 heroku/heroku-applink-service-mesh
heroku buildpacks:add heroku/nodejs
heroku config:set HEROKU_APP_ID="$(heroku apps:info --json | jq -r '.app.id')"

# Deploy and connect to Salesforce
git push heroku main
heroku salesforce:connect my-org
heroku salesforce:publish api-docs.yaml --client-name GenerateQuote --connection-name my-org --authorization-connected-app-name GenerateQuoteConnectedApp --authorization-permission-set-name GenerateQuotePermissions

Your Procfile needs to route requests through the service mesh for authentication, and your application should use APP_PORT instead of the standard PORT environment variable (which is now used by the service mesh). For example, in Node.js:

// From config/index.js
port: process.env.APP_PORT || 8080,
web: APP_PORT=3000 heroku-applink-service-mesh npm start

Important security note: The service mesh will by default block all incoming requests to the application unless they are from a Salesforce org. The HEROKU_APP_ID config variable is currently required as part of the implementation – in future releases we will look to remove this requirement.

Once your application is deployed and published, you need to grant the appropriate permissions to users who will be invoking your Heroku application through Apex, Flow, or Agentforce:

# Grant permissions to users
sf org assign permset --name GenerateQuote -o my-org
sf org assign permset --name GenerateQuotePermissions -o my-org

The permission sets serve different purposes: GenerateQuote grants users access to the Heroku app (through the Flow, Apex or Agentforce interaction they are using), while GenerateQuotePermissions provides additional permissions the code might require to access objects and fields in the org that the user cannot normally access – this elevated permission model is discussed in the next section in more detail.

Applications use familiar Express-style middleware to parse incoming Salesforce requests and enable transactional operations. The SDK’s parseRequest method handles the complex process of extracting user context and authentication details from Salesforce requests – no need to manually parse headers or manage authentication tokens.

When using the AppLink SDK with your preferred Node.js web framework, middleware configuration follows standard patterns. The Pattern 2 sample uses Fastify (though Express.js, Koa, or other frameworks work equally well), where the SDK automatically parses incoming request headers and body, extracting user context and setting up the authenticated Salesforce client for your route handlers.

The middleware is implemented as a Fastify plugin that applies to all routes:

// From heroku-applink-pattern-org-action-nodejs/src/server/middleware/salesforce.js
const preHandler = async (request, reply) => {
  const sdk = salesforceSdk.init();
  try {
    // Parse incoming Salesforce request headers and body
    const parsedRequest = sdk.salesforce.parseRequest(
      request.headers, 
      request.body, 
      request.log
    );
    
    // Attach Salesforce client to request context
    request.salesforce = Object.assign(sdk, parsedRequest);
  } catch (error) {
    console.error('Failed to parse request:', error.message);
    throw new Error('Failed to initialize Salesforce client');
  }
};

This middleware plugin is registered in the main application file where the Fastify server is configured:

// From heroku-applink-pattern-org-action-nodejs/src/server/app.js
import { salesforcePlugin } from './middleware/salesforce.js';

// Register Salesforce plugin
await fastify.register(salesforcePlugin);

For developers not using the AppLink SDK, the key integration point is parsing the x-client-context header that contains base64-encoded JSON with authentication and user context. Here’s how you can implement this manually in Java:

// From heroku-applink-pattern-org-action-java/.../SalesforceClientContextFilter.java
private static final String X_CLIENT_CONTEXT_HEADER = "x-client-context";

// Decode the base64 header value and parse the JSON
String encodedClientContext = request.getHeader(X_CLIENT_CONTEXT_HEADER);
String decodedClientContext = new String(
  Base64.getDecoder().decode(encodedClientContext), 
  StandardCharsets.UTF_8
);

ObjectMapper objectMapper = new ObjectMapper();
JsonNode clientContextNode = objectMapper.readTree(decodedClientContext);

// Extract authentication and context fields
String accessToken = clientContextNode.get("accessToken").asText();
String apiVersion = clientContextNode.get("apiVersion").asText();
String orgId = clientContextNode.get("orgId").asText();
String orgDomainUrl = clientContextNode.get("orgDomainUrl").asText();

JsonNode userContextNode = clientContextNode.get("userContext");
String userId = userContextNode.get("userId").asText();
String username = userContextNode.get("username").asText();

This approach bypasses the SDK entirely and directly constructs the Salesforce SOAP API endpoint ({orgDomainUrl}/services/Soap/u/{apiVersion}) using the authentication details from the header. The JSON structure in the x-client-context header contains:

{
  "accessToken": "00D...",
  "apiVersion": "62.0",
  "requestId": "request-123",
  "orgId": "00Dam0000000000",
  "orgDomainUrl": "https://yourorg.my.salesforce.com",
  "userContext": {
    "userId": "005am000001234",
    "username": "[email protected]"
  }
}

One of the key advantages of Pattern 2 applications is the ability to perform multiple DML operations atomically – similar to database transactions in Node.js ORMs like Sequelize or Prisma. The SDK’s Unit of Work pattern ensures all operations succeed or fail together, providing transactional integrity for complex business processes that involve creating or updating multiple related records:

// From heroku-applink-pattern-org-action-nodejs/src/server/services/pricingEngine.js
const { context } = client;
const org = context.org;

// Create Unit of Work for transactional operations
const unitOfWork = org.dataApi.newUnitOfWork();

// Register Quote creation
const quoteRef = unitOfWork.registerCreate({
  type: 'Quote',
  fields: {
    Name: 'New Quote',
    OpportunityId: request.opportunityId
  }
});

// Register related QuoteLineItems  
queryResult.records.forEach(record => {
  const discountedPrice = (quantity * unitPrice) * (1 - effectiveDiscountRate);
  
  unitOfWork.registerCreate({
    type: 'QuoteLineItem',
    fields: {
      QuoteId: quoteRef.toApiString(), // Reference to Quote being created
      PricebookEntryId: record.fields.PricebookEntryId,
      Quantity: quantity,
      UnitPrice: discountedPrice / quantity
    }
  });
});

// Commit all operations in one transaction
const results = await org.dataApi.commitUnitOfWork(unitOfWork);
const quoteResult = results.get(quoteRef);
return { quoteId: quoteResult.id };

For comprehensive examples including Bulk API operations, event handling, and advanced patterns, explore the complete integration patterns samples which demonstrate real-world scenarios across Node.js, Java, and Python implementations.

In the second part of this blog, we’ll dive deeper into how to invoke this Heroku logic from Apex, Flow, and Agentforce, including the specific Salesforce security models in effect and practical implementation guidance for each integration point.

Pattern Comparison

Now that you’ve seen both primary patterns, here’s a comparison of their key differences:

For detailed guidance on all integration patterns and when to use each one, note that we have a Getting Started Guide that goes through this in more detail, as well as being covered in context in each of the README files for our accompanying samples.

Additional integration patterns and features

While Patterns 1 and 2 cover the foundational approaches, AppLink also supports two additional patterns that extend these core concepts:

Pattern 3: Scaling batch jobs

This pattern builds on Pattern 2’s extension approach by delegating large-scale data processing with significant compute requirements to Heroku Worker processes. This pattern is ideal when you need to process large datasets that exceed Salesforce batch job limitations, providing parallel processing capabilities and sophisticated error handling. See the complete Pattern 3 implementation for detailed guidance on batch processing architectures.

Pattern 4: Real-time eventing

This pattern extends Pattern 1’s API access approach by using Run-as-User authentication to establish event listening for Platform Events and Change Data Capture from Salesforce. The work is performed by the Run-as-User, enabling real-time responses to data changes and event-driven automation with custom notifications sent to desktop or mobile devices. Explore the Pattern 4 implementation for event-driven integration examples.

To summarize, Pattern 3 builds on Pattern 2’s extension approach (Invoking User), while Pattern 4 builds on Pattern 1’s API access approach (Run-as-User), focusing on different scenarios and authentication models. Complete sample implementations for all four patterns are available in the AppLink integration patterns repository.

Data Cloud integration

AppLink provides comprehensive Data Cloud integration capabilities that enable bi-recreational data flow between your Heroku applications and Salesforce Data Cloud. Your applications can execute SQL queries against Data Cloud using the dataCloudApi.query() method to access unified customer profiles, journey analytics, and real-time insights.

Additionally, you can create Data Cloud Actions that allow Data Cloud to invoke your Heroku applications through Data Action Targets. The SDK’s parseDataActionEvent() function handles incoming Data Cloud events, providing structured access to event metadata, current and previous values, and custom business logic integration points. This creates powerful scenarios like real-time personalization engines, automated customer journey optimization, and intelligent data enrichment workflows that combine Data Cloud’s analytics capabilities with Heroku’s computational flexibility.

What’s next?

In our next blog in the AppLink Fundamentals series, we’ll delve into advanced integrations with Flow, Apex, and Agentforce, demonstrating how AppLink amplifies Salesforce’s existing features. Following that, we’ll cover the practical aspects of the development flow, including local testing, managing OpenAPI changes, and the key considerations when choosing between Apex and other programming languages for your Salesforce extensions.

Read More of the AppLink Fundamentals series

1. AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications
2. AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI
3. AppLink Fundamentals III: Building with AppLink – Development Flow and Language Choices

The post AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications appeared first on Heroku.

The Salesforce platform offers a powerful array of tools for customization and building customer-centric experiences, from no-code automation with Flow, Prompt Builder, and Agent Builder, to robust Apex and Lightning Web Components. The art lies in choosing the right blend of these tools to achieve agility, optimize skill sets, and quickly adapt to business demands. Today, we’re introducing a new ingredient to this powerful mix: Heroku + AppLink.

New to Heroku? Watch this brief introduction video to get familiar with the platform before diving into AppLink.

With the general availability of Heroku AppLink directly on the Salesforce Setup menu, Heroku is significantly expanding the programming language options available to Salesforce developers. AppLink empowers you to securely deploy code written in virtually any language directly to the Salesforce platform, enabling enhanced growth and capabilities for existing workloads. Heroku applications can be seamlessly attached to multiple Salesforce orgs, allowing your customizations and automations to leverage Heroku’s renowned scaling capabilities. This groundbreaking integration makes it possible to build nearly anything on the Salesforce platform without the need to store or move data off-platform for complex processing. With AppLink, you get the same trust commitment as every other Salesforce product, as AppLink handles all the security and integration for you!

Want to take the next step in your experience with Heroku? Talk with a Heroku rep!

Use AppLink with the language of your choice

If you’re a Salesforce architect or developer familiar with Node.js (the same runtime used by Lightning Web Components) or Python, this blog is for you. This initial release of AppLink provides SDK support for Node.js and Python, with a primary focus on Node.js examples and patterns. We’ve also included Java samples that demonstrate how to use AppLink in languages that don’t currently have a dedicated SDK, by working directly with AppLink’s APIs. Importantly, AppLink’s APIs are designed to work with virtually any programming language, giving you the freedom to use the tools and frameworks you’re already productive with.

In this series, we’ll embark on a journey to explore the key components of AppLink, discover how to extend Salesforce Flows, Apex, and Agentforce with external logic, and understand how AppLink helps build solutions with customer data security as a top priority, with user mode enabled by default. We’ll also delve into various usage patterns, the development flow, and crucial considerations for when to leverage AppLink versus traditional Apex development.

Exploring Heroku AppLink features

AppLink functions as a standard Heroku add-on. However, unlike add-ons from ecosystem partners, AppLink is owned and managed directly by Heroku engineers as an extension to the Heroku platform itself. As an add-on, you can expect a familiar UI, normal provisioning processes, and the ability to share the add-on across multiple Heroku applications and services. AppLink is available to all Salesforce orgs and can be easily found under the Setup menu. The add-on itself is free; you only pay for the Heroku compute and any desired data resources through normal Heroku billing. Click here to learn more about Heroku Add-ons.

AppLink is comprised of several key components that work in concert to create a fully managed bridge between your Heroku application and other Salesforce products. Understanding this architecture is crucial for successful implementation, as each component plays a specific role in enabling secure, authenticated communication between your custom code and the Salesforce platform.

The diagram below illustrates the complete AppLink ecosystem, showcasing how requests flow between Salesforce orgs and your Heroku applications, the vital role of the AppLink add-on in managing connections and authentication, and how various AppLink components coordinate to provide seamless integration. Whether you’re building applications that call Salesforce APIs or services that extend Salesforce functionality, this architecture forms the foundation for all integration scenarios.

Each component within AppLink serves a distinct purpose in creating the integrated experience. The table below provides a detailed overview of the role and capabilities of each AppLink component, demonstrating how they work together to provide comprehensive Salesforce-Heroku connectivity.

Together, these components offer a comprehensive and cohesive ecosystem that simplifies the complex task of integrating Heroku applications with Salesforce. By providing dedicated tools for everything from secure connectivity and automatic authentication to streamlined deployment, monitoring, and service discovery, AppLink reduces development overhead and accelerates time to market. This holistic approach ensures that developers can focus on building powerful business logic, knowing that the underlying infrastructure for secure and scalable Salesforce extension is fully managed and integrated.

Stay tuned: from foundation to practical application

This blog post has provided a foundational understanding of AppLink – what it is, why it’s a critical new tool for Salesforce developers, and its core components.

In our three part series, AppLink Fundamentals, we’ll dive into the practical application of AppLink by exploring its key integration patterns, showing you how to connect your Heroku applications to Salesforce for various use cases. Subsequent posts in this series will delve into advanced integrations with Data Cloud, Flow, Apex, and Agentforce, followed by a look at the development workflow, language choices, and best practices for building robust solutions with AppLink. Stay tuned to unlock the full potential of extending Salesforce with the power of Heroku.

Additional AppLink resources

• Getting Started with Heroku AppLink and Salesforce
• Getting Started with Heroku AppLink and Data Cloud
• Getting Started with Heroku AppLink and Agentforce

Read the AppLink Fundamentals series

1. AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications
2. AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI
3. AppLink Fundamentals III: Building with AppLink – Development Flow and Language Choices

The post Heroku AppLink: Extend Salesforce with Any Programming Language appeared first on Heroku.

Modern cloud-native architectures are composed of multiple microservices running across dynamic environments. Effectively diagnosing performance issues, bottlenecks, or failures requires comprehensive observability. For this, many organizations look to OpenTelemetry, which provides a standardized approach to capturing and analyzing telemetry data.

Fir is Heroku’s next generation cloud platform, designed to offer more modern cloud-native capabilities with flexibility and scalability. It’s built on proven, open-source technologies. Traditional Heroku relied on proprietary technologies, which was appropriate at the time because high-quality open-source alternatives didn’t exist. But now, technologies like Kubernetes and OpenTelemetry are considered best-in-class solutions that are widely deployed and supported by a vast ecosystem.

Kubernetes is at the core of Fir’s infrastructure, providing automated scaling, self-healing, and efficient resource management. And while Kubernetes powers Fir, end users are not exposed to it directly—which is a good thing, since Kubernetes is very complex. Under the hood, Fir takes advantage of the powerful capabilities of Kubernetes, but it only exposes the user-friendly Heroku interface for user interaction.

OpenTelemetry offers standard-based visibility into how applications and services interact within Fir as well as integrate with external systems. By leveraging OpenTelemetry with Fir, developers can gain deep insights into application performance. They can track distributed requests and even route telemetry data to external monitoring platforms if they wish.

Let’s look more deeply into OpenTelemetry and what it brings to the table.

Understanding OpenTelemetry

As an observability framework, OpenTelemetry is designed to standardize the collecting, processing, and exporting of telemetry data from applications. It aims to provide a unified approach to capturing this data across distributed systems so that developers can monitor performance and diagnose issues effectively.

One of the primary goals of OpenTelemetry is to eliminate vendor lock-in. You can send telemetry data to various backends, such as Prometheus, Jaeger, Grafana, Datadog, and—of course—Heroku, without modifying application code.

OpenTelemetry consists of language-specific APIs and SDKs coupled with the OpenTelemetry Collector, all working together to provide a unified observability framework. The APIs define a standard way to generate telemetry data, while the SDKs offer language-specific implementations for instrumenting applications. The OpenTelemetry Collector acts as a processing pipeline. It supports the ingestion, filtering, and export of telemetry data using the OpenTelemetry Protocol (OTLP), which standardizes the transmission of data to various observability backends.

OpenTelemetry supports three primary telemetry data types, each serving a critical role in observability:

1. Logs capture discrete events, such as errors or system messages, providing a detailed record of application behavior.
2. Metrics track numerical data over time, offering quantifiable insights into system performance.
3. Traces track the flow of requests across distributed services, enabling developers to diagnose latency issues and optimize performance.

Fir: Heroku’s next generation platform

By integrating Kubernetes into its core, Fir empowers developers to deploy and manage applications with greater control and resilience. Leveraging Kubernetes ensures that applications can handle varying workloads seamlessly, adapting to changing demands without manual intervention. Because it runs specifically on top of AWS EKS, Fir can take advantage of more diverse and powerful instance types, such as the AWS Graviton processor.

Fir utilizes Open Container Initiative (OCI) images and Cloud Native Buildpacks to package and deploy services and applications. This is a major improvement, because it means developers in the Heroku world can tap into their standards-based knowledge and tooling. In addition, Fir integrates seamlessly with OpenTelemetry, providing a built-in collector and easy ways to configure drains for transmitting telemetry data to additional destinations if needed.

Basing Fir on open-source standards and technologies is a major advantage for several reasons:

• If a company already uses these technologies and has a centralized observability platform, then they can gradually migrate some systems to Fir, while retaining a single pane of glass for all systems.
• It avoids lock-in because companies can easily migrate to other Kubernetes providers and still use their existing OpenTelmetry instrumentation and CNB pipelines.
• Companies have the option of maintaining a hybrid environment, in which some systems run on Heroku Fir while others run on other Kubernetes providers if they need more control.

The benefits of OpenTelemetry in Fir

Native integration with OpenTelemetry means Fir enables automatic telemetry collection without requiring extensive manual setup.

By tracing requests across distributed services (including on non-Heroku systems interacting with Fir), developers can easily pinpoint failures and optimize system performance. These capabilities enable teams to proactively address issues before they impact end users, improving application reliability.

OpenTelemetry’s vendor-agnostic approach gives organizations the flexibility to choose their preferred monitoring and analytics tools. Since OpenTelemetry is an open-source project, it benefits from continuous improvements and broad community support.

Because of its lightweight and distributed architecture, OpenTelemetry is well-suited for large-scale, cloud-native environments like Fir’s Kubernetes-based infrastructure. It efficiently handles high-volume telemetry data, ensuring that performance monitoring scales alongside the application.

How does OpenTelemetry work with Fir?

Fir provides out-of-the-gate OpenTelemetry logs and metrics for your dynos and the applications running on them. These are displayed in your app’s dashboard.

You can take this even further. If you configure an OpenTelemetry SDK and instrument your application, then you can generate custom metrics and distributed traces. You can also configure drains to send your telemetry data to third-party observability platforms.

How do all the pieces fit together? Consider the following diagram:

The built-in Heroku OpenTelemetry Collector does all the heavy lifting for you.

1. Fir uses the Heroku OpenTelemetry Collector to collect data from various telemetry sources such as your web application, the Heroku router, and the Heroku API.
2. The collector is configured with various telemetry destinations (drains).
3. The collector sends the relevant telemetry data to destinations like Heroku CLI logs, the Heroku dashboard, or other observability platforms.

OpenTelemetry drains can be defined at the space level—meaning they apply to all applications in the space—or at an individual application level. This is done using the Heroku CLI:

$ heroku telemetry -h
list telemetry drains

USAGE
  $ heroku telemetry [-s ] [--app ]

FLAGS
  -s, --space=  filter by space name
  --app=        filter by app name

DESCRIPTION
  list telemetry drains

EXAMPLES
  $ heroku telemetry

COMMANDS
  telemetry:add     Add and configure a new telemetry drain. Defaults to collecting all telemetry unless otherwise specified.
  telemetry:info    show a telemetry drain's info
  telemetry:remove  remove a telemetry drain
  telemetry:update  updates a telemetry drain with provided attributes (attributes not provided remain unchanged)

The key to the interoperability of Heroku’s telemetry data is the Open Telemetry Protocol (OTLP). This protocol has two transports: gRPC and HTTP. Heroku supports both. While the gRPC transport is more efficient and has more features (HTTP/2 streaming, bi-directional streaming, Protocol Buffers payload), it might not be able to traverse some firewalls or be routed properly. In these cases, the HTTP transport, based on simple HTTP 1.1, may be the best option. It may depend also on the support in the SDK of your programming language.

Conclusion

As cloud-native applications become more complex and distributed, observability is no longer optional. It is a fundamental requirement for ensuring reliability, performance, and rapid debugging. OpenTelemetry is quickly becoming the industry standard for telemetry collection, and its seamless integration into Fir ensures that applications running on the platform can be monitored with minimal effort.

Fir’s underlying Kubernetes foundation allows organizations to benefit from industry-leading infrastructure without needing to manage the complexity of Kubernetes directly. This combination provides a powerful and future-proof platform that simplifies operations while ensuring full visibility into application behavior.

Fir’s reliance on open standards and technologies is a win-win because it reduces the risk of vendor lock-in for users and also benefits from the development effort of the open-source community to enhance and improve those technologies.

Additional resources

• Planting New Platform Roots in Cloud Native with Fir
• Heroku Documentation
  • Monitoring & Metrics
  • OpenTelemetry Concepts and Heroku
• Cloud Native Buildpacks: Go tutorial from Heroku
• OTLP Specification 1.5.0 | OpenTelemetry

The post OpenTelemetry, Kubernetes, and Fir: Putting it All Together appeared first on Heroku.

We’re thrilled to announce the general availability of Valkey v8.1 in Redis OSS compatible Heroku Key-Value Store. This isn’t just an incremental update; it’s a significant leap forward, bringing enhanced performance and greater efficiency. To add to this excitement, we’re bringing powerful new module capabilities to v8.1, with Valkey Bloom and ValkeyJSON.

For years, Heroku customers have relied on our managed in-memory data store services for caching, session management, real-time leaderboards, queueing, and so much more. Valkey is a drop-in, open-source fork of Redis OSS at v7.2, maintained by the Linux Foundation, and is backwards compatible with Redis OSS protocols and clients. With Valkey v8.1, we’re continuing our commitment to providing you with a robust, scalable, and developer-friendly in-memory datastore. We are delivering this enhancement to empower you to build faster, smarter, and more efficient applications on Heroku.

What’s New in Valkey v8.1

Valkey v8.1 itself comes packed with core improvements designed to make your applications perform:

• Enhanced Performance: Experience lower latencies and higher throughput. Valkey v8.1 features a new, more memory-efficient hash table implementation and optimizations in I/O threading. This means your apps can handle more requests, faster. Active memory defragmentation also sees a significant reduction in request latency.
• Better Memory Efficiency: Squeeze more out of your instances. The new hash table design reduces memory usage per key, allowing you to store more data cost-effectively.

These improvements mean your existing Heroku Key-Value Store use cases will run faster and more efficiently, mostly without needing any changes on your end.

How to upgrade to Valkey v8.1

You can upgrade your Heroku Key-Value Store instance to the latest version with:

heroku redis:upgrade –version 8.1 –app app-name

If you’re on mini, above command will upgrade your instance immediately. If you’re on premium or larger plans, the above command will prepare the maintenance and you can upgrade by running maintenance.

Valkey 8 Benchmark Highlights (vs Valkey 7.2)

To give you a clearer picture of the performance uplift, our internal benchmarks (combination of SETS and GETS operations) comparing Valkey 8.0 (a precursor to 8.1, sharing many core enhancements) with Valkey 7.2 on various Heroku Key-Value Store premium plans show significant improvements. Here’s a snapshot of the average gains observed:

These benchmarks demonstrate that as you scale to plans with more CPU cores, the performance advantages of Valkey 8.x become even more pronounced, allowing your applications to handle substantially more operations per second with lower latency. While specific gains can vary by workload, the trend is clear: Valkey 8.1 is engineered for speed and efficiency. We offer a variety of Heroku Key-Value Store options to tailor to your needs.

Valkey Bloom & ValkeyJSON: Powerful New Modules for Heroku Key-Value Store

The real headline-grabbers with this release are the new, highly anticipated modules now available: Valkey Bloom and ValkeyJSON. These modules (similar to extensions on Heroku Postgres) unlock entirely new ways to leverage the power and simplicity of Heroku Key-Value Store within your Heroku applications. Let’s go over each one in more detail!

Valkey Bloom: Probabilistic Data Structures for Efficiency

Valkey Bloom introduces Bloom filters, a probabilistic data structure that excels at quickly and memory-efficiently determining if an element is probably in a set, or definitely not in a set.

• Benefit: Bloom filters can dramatically reduce the load on your primary databases and improve application efficiency by avoiding unnecessary, expensive lookups for items that don’t exist. They achieve this with remarkable memory savings – potentially over 90% compared to traditional methods for some applications.
• Use Cases:
  • Cache “Probably Not Found” Queries: Before hitting your main database for an item, quickly check a Bloom filter. If it says the item is definitely not there, you save a costly database query. This is fantastic for recommendation engines (filtering out already-seen items), unique username checks, or fraud detection systems (checking against known fraudulent IPs or transaction patterns).
  • Content Filtering: Efficiently check against large lists of malicious URLs or profanity.
  • Ad Deduplication: Ensure users aren’t shown the same advertisement repeatedly.

While Bloom filters have a chance of a “false positive” (saying an item might be in the set when it isn’t), they guarantee no “false negatives” (if it says an item isn’t there, it’s truly not there). For many use cases, this trade-off is incredibly valuable for the performance and memory gains.

ValkeyJSON: Native JSON Handling for Rich Data Structures

Many modern applications rely heavily on JSON. With ValkeyJSON, you can now work with JSON data more naturally and efficiently within a Heroku Key-Value Store instance.

• Benefit: ValkeyJSON provides native support for storing, retrieving, and manipulating JSON documents. This allows for atomic operations on specific parts of a JSON object without needing to fetch and parse the entire thing in your application, leading to better performance and simpler application code.
• Use Cases:
  • Store Complex Objects: Easily store user profiles, product catalogs with nested attributes, configuration data, or any other complex objects as JSON documents.
  • Atomic Updates: Modify specific fields within a JSON document directly in Valkey. For example, update a user’s last login time or add an item to an array within a product’s attributes without rewriting the whole object.
  • Simplified Development: Reduce boilerplate code for serializing and deserializing JSON in your application.

If your application deals with structured but flexible data, ValkeyJSON can significantly streamline your data management and improve performance.

Getting Started with Valkey Modules on Heroku Key-Value Store

Once you upgrade to Valkey v8.1, these powerful modules are already enabled and commands can be used. For example, to add an item to bloom filter through the CLI:

BF.ADD name-of-filter item-to-insert

We encourage you to explore the official Valkey documentation for Valkey Bloom and Valkey JSON to dive deeper into their commands and capabilities.

Valkey v8.1 & Module Power: Your Faster, More Flexible Heroku Data Store

The addition of Valkey v8.1, along with the Valkey Bloom and ValkeyJSON modules to Heroku Key-Value Store offerings, represents a significant step forward in the capabilities available to you on the Heroku platform. We’re excited to see how you’ll leverage these new tools to build the next generation of innovative applications.

As always, we’re here to support you if you get stuck. Stay tuned for more detailed guides and examples on using these new features. For now, get ready to explore the enhanced power and flexibility of Heroku Key-Value Store! Happy coding!

The post Heroku Key-Value Store Now Supports Valkey 8.1 with JSON and Bloom Modules appeared first on Heroku.

Today, we are pleased to announce the evolution of Heroku to an AI Platform as a Service (AI PaaS). GenAI has changed how we build software (vibe coding), the kind of technology we use (Cursor, LLMs), the type of software we make (agents), and redefined what it means to be a developer in this new world.

In a recent Salesforce study, 84% of developers with AI say it helps their teams complete their projects faster. AI-powered, natural language development tools make it possible for anyone to create software by typing instructions in English. This increase in new apps is only matched by the increasing complexity of new technology to choose from, integrate, and maintain as a stable and secure platform – stressing the existing delivery gaps and friction in software delivery.

Heroku was founded to make deploying and scaling Ruby on Rails apps in the cloud easy for developers. Over the last decade, we remained steadfast in this mission by expanding to support more languages, databases, and now to AI. The Heroku AI PaaS brings powerful AI primitives into our opinionated platform with a simplified developer experience and automated operations to accelerate delivery of AI-powered apps and agents.

The Heroku AI PaaS adds these new capabilities to our robust cloud-native platform foundation:

• Heroku AppLink: Enable Agentforce to more use cases with custom actions, channels, tools in any programming language and securely integrated with a single click through Salesforce Flows, Apex, and Data Cloud. Agentforce is the agentic layer of the Salesforce Platform for deploying autonomous AI agents across any business function. This capability brings the ecosystem of programming languages and custom code to augment and enhance Salesforce implementations. AppLink will GA in July.
• AI-Native Tools Integration: Leverage tools like Cursor, Windsurf, and Claude Code to vibe code new apps, modernize existing apps, and add capabilities to agents. Deploy and manage code running on Heroku directly from these new developer tools. This capability is available today.
• MCP Server Toolkit: Enable your agents with more capabilities by exposing relevant tools and data with MCP Servers, a critical element of agentic workflows. Build and run custom MCP Servers, the official Heroku MCP Server, or the Heroku Remote MCP Server on Heroku and Heroku MCP Toolkits provide a unified gateway to deploy and manage multiple MCP servers on the platform. With Agentforce 3.0‘s native MCP support, bringing your Heroku Remote MCP Server to Agentforce is now a reality. MCP Server support is available today.
• Heroku Managed Inference and Agents: Brings together a set of powerful primitives into the platform that make it simple for developers to build, scale, and operate AI-powered features and applications, without the heavy lifting of managing their own AI infrastructure. Access to leading models from Claude, Cohere, Stability, and more; plus primitives for building agents that can reason, act, and call tools, developers can focus on delivering differentiated experiences for their users, rather than wrangling inference infrastructure or orchestration logic. Heroku Managed Inference and Agents is available today.

Plus these new AI apps and agents will benefit from Heroku’s built-in automation, autoscaling, observability, and dashboards for all workloads running on the platform, giving you peace of mind at any scale and the metrics to monitor ongoing performance.

Complementing the platform innovations are new additions to our partner program to increase the technical expertise available to our customers around the world that help deliver their new app projects faster and more successfully. New certifications deepen expertise in solution design and implementation while a new Heroku Expert Area in Partner Navigator makes it easy for customers to find the right partner for their needs. Learn more about the partner updates here.

Our focus has always been on the apps, the code that drives your business. The software being built today is agentic and these new apps and agents require access to data, tools, and other agents to get the job done. The Heroku AI PaaS brings powerful AI technology to your fingertips with ease of use in mind to help you deliver value to your business faster and with less complexity. Start exploring the new Heroku today.

The post Introducing the Heroku AI Platform as a Service (AI PaaS) appeared first on Heroku.

Partners are a critical part of the community in driving customer success in technology adoption. Today, we’re thrilled to announce new solution expertise and program benefits for Salesforce Consulting Partners to expand their practice with Heroku AI PaaS. Building on our announcement from earlier this year, today’s announcement is designed to deepen technical expertise and help partners expand the service offerings they can provide their customers with the Salesforce portfolio.

Salesforce is the world’s #1 AI CRM and provider of the Agentforce digital labor platform bringing together the C360 apps and data with Heroku. Every customer’s business is unique and that often means designing solutions that bring together multiple Salesforce Clouds with 3rd party systems, and building customized experiences around them. Heroku’s robust AI PaaS provides the flexibility developers need and the reliability businesses need to enable these solutions with custom apps, services, and native integration to the Salesforce platform.

What’s new for partners:

• Heroku Expert Area: Available in July as part of the Salesforce Partner Navigator, the new Heroku Expert Area is designed to recognize and reward partners with proven Heroku expertise.
• Trailblazer Community Group: A private community group for Salesforce Consulting Partners on their Heroku journey to get the latest updates, network with peers, and connect with the Heroku team.
• Product Benefits: Partners are provided access to Heroku products to get hands on with the technology, enable their teams, and build demos.

“At Showoff we deeply value our partnership with Heroku—not just for the powerful technology platform it provides, but for the trust and collaboration that underpin our relationship. Our customers understand the value Heroku brings, and we see that every day in the agility and scalability it enables. What sets this partnership apart is the personal connection—the ability to pick up the phone, solve problems together, and collaborate on innovative solutions that truly drive business value”
– Barry Sheehan, CCO, Showoff

Certifications to build deep expertise

Expertise is built through knowledge and experience. We have two certifications to help partners continue their enablement journey on the path to becoming a Heroku Expert. Partners can achieve Heroku Specialist and Heroku Cloud Expert distinctions, with Heroku Implementation Expert distinction launching in 2026. Information on how to achieve Heroku distinctions is available in the Heroku Partner Readiness Guide and Heroku Technical Learning Journey.

• Heroku Developer Specialist [new]: This speciality area demonstrates an individual’s ability to build and manage Heroku applications effectively with an emphasis on practical skills related to deploying, maintaining, and scaling apps on the Heroku platform. A core component of this distinction is the Heroku Developer Accredited Professional certification.
• Heroku Architect Specialist [new]: This speciality area demonstrates an individual’s ability to design and implement applications on Heroku with a focus on architectural best practices. It involves understanding complex architectural considerations and leveraging Heroku features to build robust, scalable applications. A core component of this distinction is the Heroku Architect certification.
• Heroku Cloud Expert [new]: This distinction demonstrates an organization’s proven expertise in successfully delivering Heroku implementations that achieve high customer satisfaction scores.

Access to Heroku products

Starting next month, eligible Salesforce Consultants and Cloud Resellers will get access to Heroku products within a Heroku Demo Org with access to a Heroku Dev Starter Package which includes Dynos, Heroku Connect, and General Credits. This direct access to products provides a hands-on environment to build demos, design and prototype solutions, and complements enablement for certification.

“At Cognizant, we deeply value our partnership with Heroku. Its platform has empowered our teams to accelerate application development, streamline deployment, and deliver scalable, resilient solutions for our clients. We’ve seen measurable improvements in time-to-market and customer satisfaction. As we continue to innovate, we’re excited to build on this collaboration to drive even greater impact for the businesses we serve.”
– Sivakumar Meenakshi Sundaram, Global Delivery Head, Cognizant

Heroku Lighthouse Partners

These announcements mark an exciting new chapter for our partner community with new opportunities to grow their practice and expand their customer relationships. We are especially thankful for the lighthouse partners featured throughout this blog. These partners have worked diligently to become Heroku Experts; providing early participation and feedback in building a robust partner network. This group of standout consulting firms have demonstrated deep platform knowledge and delivered innovative solutions to clients using Heroku.

“Heroku lets our team focus on building great products, not managing infrastructure—empowering us to deliver faster, smarter solutions for our clients.”
– Scott Weisman, Co-Founder & CEO, LaunchPad Lab

By removing the friction of infrastructure management, Heroku has enabled partners like LaunchPad Lab to spend more time on what matters: creating high-impact digital experiences for their customers. This is the foundation of the Heroku Expert model, it’s a model designed to free teams to deliver client value at speed.

“Heroku by Salesforce gives our clients the flexibility to scale agentic AI across their end-to-end processes. From microservices to BYOM, Heroku enables us to deliver enterprise-grade solutions with speed and precision.”
– Sadagopan Singam, EVP (Global), Digital Business – Commercial Applications, HCLTech

For global consulting firms like HCLTech, Heroku provides the agility and control needed to meet the evolving demands of enterprise clients—especially as AI, data, and integration use cases grow more complex. Heroku’s ability to support both modern architectures and emerging AI use cases makes it a powerful enabler of digital transformation.

“Heroku gives Vanshiv’s engineering team the flexibility to build scalable microservices and extend Salesforce with modern architectures—helping us deliver robust, enterprise-grade solutions.”
– Gaurav Kheterpal, Founder & CEO, Vanshiv

As clients look to bring more custom logic and scalable services into their Salesforce environment, partners like Vanshiv are building microservices on Heroku to handle complexity and ensure reliability. This approach, that leans into custom solutions is essential for industries with high security and performance requirements.

“We’ve always embraced the pro-code ethos of Heroku as it allows us, a Salesforce Consulting Partner, to greatly extend the capabilities of Salesforce.”
– Jaime Solari, CEO & Founder, Oktana

The developer experience is a key differentiator for Heroku and a core reason why engineering-driven consultancies choose to invest in the platform. Oktana’s work demonstrates how Heroku enables partners to bridge the gap between low-code solutions and the full power of custom development.

Together, these Lighthouse Partners exemplify how Heroku is the best AI PaaS for innovation and growth. Their success stories are just the beginning, and we’re thrilled to continue building a thriving ecosystem of expert partners delivering next-generation solutions to Salesforce customers.

Get started today

Join the Heroku Partner Trailblazer Community to stay informed on the latest news, enablement, events, and network with other partners and Heroku.

“We are values aligned and value driven. Selling, delivering and growing with Heroku and Salesforce for the past 15 years has proven that success is a 3-way celebration with our joint customers.”
– Chris Peacock, CEO, Kilterset

The post Elevate Your Salesforce Consulting Practice with Heroku appeared first on Heroku.

Today, we’re thrilled to announce a new way in which agents can access the Heroku platform using the Heroku Remote MCP Server, now available at https://mcp.heroku.com/mcp.

This new remote server is an expansion of our earlier stdio-based MCP server and comes with secure OAuth authentication. It’s designed to provide a secure, scalable, and incredibly simple way for agents to interact with the Heroku platform and use tools to perform actions such as creating a Heroku app from your favorite agents such as Claude, Agentforce, or Cursor. With Agentforce 3.0 announcing native support for MCP, you can bring Heroku Remote MCP Server to Agentforce.

Secure access and authentication with remote MCP servers

If you’re new to MCP, read this introduction to MCP to familiarize yourself. While our initial stdio MCP server supports local development capabilities by allowing agents to interact with the Heroku platform as a subprocess, it was limited to tethering your agent’s capabilities to a single machine. The new Heroku Remote MCP Server overcomes this with enhanced security for your AI workflows by centralizing access to the Heroku platform. The Heroku Remote MCP Server is easily accessible through clients that support remote servers and uses the industry-standard OAuth 2.0 protocol. When you connect a new client, you’ll be prompted to authenticate with your Heroku account, giving you clear and user-consented control over which tools can be accessed by your client.

How to connect your MCP client

As long as your agent supports remote MCP servers with OAuth, you can connect to Heroku in a few easy steps.

1. Configure the server: Following your client’s documentation, add a new MCP server and use the URL: https://mcp.heroku.com/mcp
2. Authenticate: Your client will redirect you to login with the Heroku account via OAuth.
3. Connect: Once you authenticate, your client is securely connected and ready to go!

Claude Desktop (Free)

For the Claude desktop application, you can connect using a proxy command.

1. Open the configuration file located at ~/Library/Application Support/Claude/claude_desktop_config.json.
2. Add the following entry to the mcpServers object and restart the Claude app:

{
    "mcpServers": {
      "Heroku": {
        "command": "npx",
        "args": ["-y", "mcp-remote", "https://mcp.heroku.com/mcp"]
      }
    }
}

Cursor

For Cursor, you can connect on the Tools & Integrations section in the Cursor settings page.

1. Click on Add a Custom MCP.
2. Add the following entry to the mcpServers object.
3. Go back to Tools & Integrations, click on “Needs login” to the right of the Heroku MCP entry and authenticate via OAuth.

{
    "mcpServers": {
      "heroku": {
        "url": "https://mcp.heroku.com/mcp"
      }
    }
}

VSCode

For Visual Studio Code, open the command palette and select the following:

1. Select MCP: Add Server....
2. HTTP (HTTP or Server Sent Events)
3. Insert the url https://mcp.heroku.com/mcp.
4. Insert heroku as server id.

This will add the MCP configuration to the settings.json file, from here it will ask to start the OAuth authentication.

Extend your agents with the Heroku Remote MCP Server

The Heroku Remote MCP Server empowers your agent with a rich set of tools to understand and interact with the Heroku platform. Your agent can now perform a wide array of tasks on your behalf:

• Manage application lifecycle: list your apps, get info on a specific app, and even create and update applications directly via natural language.
• Info: Get a list of the teams you belong to, and view your Private Spaces.
• Add-on marketplace: List available Heroku Add-ons and check their various plans.

This is just the initial set of tools that we have enabled. We are continuously working to enable additional tools to help you with an increasing variety of workflows.

What’s next

We’re excited about the rapid innovation in the MCP and AI ecosystem and are keeping close to the community. We expect to make updates to our MCP tools as the protocol evolves and from customer feedback. We at Heroku are obsessed with providing the best developer and operator experience for your AI workflows and agents. We started this journey with the launch of Heroku Managed Inference and Agents and support to build stdio MCP servers on Heroku and the Heroku Remote MCP Server (mcp.heroku.com/mcp) is the next exciting milestone on this journey.

Join the official Heroku AI Trailblazer Community to keep up with the latest news, ask questions, or meet the team.

To learn more about Heroku AI, check out our Dev Center docs and try it out for yourself.

The post Heroku AI: Heroku Remote MCP Server appeared first on Heroku.

Beginning at 6:00 UTC, on Tuesday, Jun 10, 2025 Heroku customers began experiencing service disruption, creating up to 24 hours of downtime for many customers. This issue was caused by an unintended system update across our production infrastructure; it was not the result of a security incident, and no customer data was lost. Now that we have fully restored our services, we would like to share more details.

The entire Heroku team offers our deepest apology for this service disruption. We understand that many of you rely on our platform as a foundation for your business. Communication during the incident did not meet our standards, leaving many of you unable to access accurate status updates and uncertain about your applications. Incidents like this can affect trust, our number one value, and nothing is more important to us than the security, availability, and performance of our services.

What happened

A detailed RCA is available here. Let’s go over some of the more important points. Our investigation revealed three critical issues in our systems that combined to create this outage:

1. A Control Issue: An automated operating system update ran on our production infrastructure when it should have been disabled. This process restarted the host’s networking services.
2. A Resilience Issue: The networking service had a critical flaw—it relied on a legacy script that only applied correct routing rules on initial boot. When the service restarted, the routes were not reapplied, severing outbound network connectivity for all dynos on the host.
3. A Design Issue: Our internal tools and the Heroku Status Page were running on this same affected infrastructure. This meant that as your applications failed, our ability to respond and communicate with you was also severely impaired.

These issues caused a chain reaction that led to widespread impact, including intermittent logins, application failures, and delayed communications from the Heroku team.

Timeline of Events

(All times are in Coordinated Universal Time, UTC)

Phase 1: Initial Impact and Investigation (06:00 – 08:26)

At 06:00, Heroku services began to experience significant performance degradation. Customers reported issues including intermittent logins, and our monitoring detected widespread errors with dyno networking. Critically, our own tools and the Heroku Status Page were also impacted, which severely delayed our ability to communicate with you. By 08:26, the investigation confirmed the core issue: the majority of dynos in Private Spaces were unable to make outbound HTTP requests.

Phase 2: Root Cause Discovery (08:27 – 13:42)

With the impact isolated to dyno networking, the team began analyzing affected hosts. They determined it was not an upstream provider issue, but a failure within our own infrastructure. Comparing healthy and unhealthy hosts, engineers identified missing network routes at 11:54. The key discovery came at 13:11, when the team learned of an unexpected network service restart. This led them to pinpoint the trigger at 13:42: an automated upgrade of a system package.

Phase 3: Mitigation and Service Restoration (12:56 – 22:01)

While the root cause investigation was ongoing, this became an all-hands-on-deck situation with teams working through the night to restore service.

• Communication & Relief: At 12:56, the team began rotating restarts on internal instances, which provided some relief. A workaround was found to post updates to the @herokustatus account on X at 13:58.
• Stopping the Trigger: The team engaged an upstream vendor to invalidate the token used for the automated updates. This was confirmed at 17:30 and completed at 19:18, preventing any further hosts from being impacted.
• Restoring Services: The Heroku Dashboard was fully restored by 20:59. With the situation contained, the team initiated a fleetwide dyno recycle at 22:01 to stabilize all remaining services.

Phase 4: Long-Tail Cleanup (June 11, 22:01 – 05:50)

This started a long phase of space recovery as well as downstream fixes. Many systems had to catch up after service was restored. For example status emails from earlier in the incident started being delivered. Heroku connect syncing had to catch back up. Heroku release phase had a long backlog that took a few hours to catch up. After extensive monitoring to ensure platform stability, all impacted services were fully restored, and the incident was declared resolved at 05:50 on June 11.

Identified Issues

Our post-mortem identified three core areas for improvement.

First, the incident was triggered by unexpected weaknesses in our infrastructure. A lack of sufficient immutability controls allowed an automated process to make unplanned changes to our production environment.

Second, our communication cadence missed the mark during a critical outage, customers needed more timely updates – an issue made worse by the status page being impacted by the incident itself.

Finally, our recovery process took longer than it should have. Tooling and process gaps hampered our engineers’ ability to quickly diagnose and resolve the issue.

Resolution and Concrete Actions

Understanding what went wrong is only half the battle. We are taking concrete steps to prevent a recurrence and be better prepared to handle any future incidents.

• Ensuring Immutable Infrastructure: The root cause of this outage was an unexpected change to our running environment. We disabled the automated upgrade service during the incident (June 10), with permanent controls coming early next week. No system changes will occur outside our controlled deployment process going forward. Additionally, we’re auditing all base images for similar risks and improving our network routing to handle graceful service restarts.
• Guaranteeing Communication Channels: Our status page failed you when you needed it most because our primary communication tools were affected by the outage. We are building backup communication channels that are fully independent to ensure we can always provide timely and transparent updates, even in a worst-case scenario.
• Accelerating Investigation and Recovery: The time it took to diagnose and resolve this incident was unacceptable. To address this, we are overhauling our incident response tooling and processes. This includes building new tools and improving existing ones to help engineers diagnose issues faster and run queries across our entire fleet at scale. We are also streamlining our “break-glass” procedures to ensure teams have rapid access to critical systems during an emergency and enhancing our monitoring to detect complex issues much earlier.

Thank you for depending on us to build and run your apps and services. We take this outage very seriously and are determined to continuously improve the resiliency of our service and our team’s ability to respond, diagnose, and remediate issues. The work continues and we will provide updates in an upcoming blog post.

The post Summary of Heroku June 10 Outage appeared first on Heroku.

Ah, another day, another deep dive into the ever-evolving world of Python development! Today, let’s talk about something near and dear to every Pythonista’s heart – managing those crucial external packages. For years, pip has been our trusty companion, the workhorse that gets the job done. But the landscape is shifting, and a new contender has entered the arena, promising speed, efficiency, and a fresh approach: uv.

As a Python developer constantly striving for smoother workflows and faster iterations, the buzz around uv has definitely caught my attention. So, let’s roll up our sleeves and explore the benefits of using uv as your Python package manager, taking a look at where we’ve come from and how uv stacks up. We’ll even walk through setting up a project for Heroku deployment using this exciting new tool.

A trip down memory lane: The evolution of Python package management

To truly appreciate what uv brings to the table, it’s worth taking a quick stroll down memory lane and acknowledging the journey of Python package management.

In the early days, installing Python packages often involved manual downloads, unpacking, and running setup scripts. It was a far cry from the streamlined experience we have today. Then came Distutils, which provided a more standardized way to package and distribute Python software. While a significant step forward, it still lacked robust dependency resolution.

Enter setuptools, which built upon Distutils and introduced features like dependency management and package indexing (the foundation for PyPI). For a long time, setuptools was the de facto standard, and its influence is still felt today.

However, as the Python ecosystem grew exponentially, the limitations of the existing tools became more apparent. Dependency conflicts, slow installation times, and the complexities of managing virtual environments started to become significant pain points.

This paved the way for pip (Pip Installs Packages). Introduced in 2008, pip revolutionized Python package management. It provided a simple and powerful command-line interface for installing, upgrading, and uninstalling packages from PyPI and other indices. For over a decade, pip has been the go-to tool for most Python developers, and it has served us well.

But the increasing complexity of modern Python projects, with their often intricate web of dependencies, has exposed some of pip’s performance bottlenecks. Resolving complex dependency trees can be time-consuming, and the installation process, while generally reliable, can sometimes feel sluggish.

Another challenge with the complexity of modern applications is package versioning. Lockfiles that pin project dependencies have become table stakes for package management. Many package management tools use them. Throughout the course of the evolution of package management in Python, we’ve seen managers such as Poetry and Pipenv, just to name a few. However, many of these projects don’t have dedicated teams. Sometimes this results in them not being able to keep up with the latest standards or the complex dependency trees of modern apps.

This is where the new generation of package management tools, like uv, comes into play, promising to address these very challenges, with a dedicated team behind them.

Enter the speed demon: The benefits of using uv

uv isn’t just another package manager; it’s built with a focus on speed and efficiency, leveraging modern programming languages and data structures to deliver a significantly faster experience. Here are some key benefits that have me, and many other Python developers, excited:

1. Blazing Fast Installation: This is arguably uv’s headline feature. Written in Rust from scratch using a thoughtful design approach uv significantly outperforms pip in resolving and installing dependencies, especially for large and complex projects. The difference can be dramatic, cutting down installation times from minutes to seconds in some cases. This speed boost translates directly into increased developer productivity and faster CI/CD pipelines.
2. Efficient Dependency Resolution: uv employs sophisticated algorithms for dependency resolution, aiming to find compatible package versions quickly and efficiently. While pip has made improvements in this area, uv’s underlying architecture allows it to handle complex dependency graphs with remarkable speed. This reduces the likelihood of dependency conflicts and streamlines the environment setup process.
3. Drop-in Replacement for pip and venv: One of the most appealing aspects of uv is its ambition to be a seamless replacement for both pip and venv (Python’s built-in virtual environment tool). It aims to handle package installation and virtual environment creation with a unified command-line interface. This simplifies project setup and management, reducing the cognitive load of juggling multiple tools.
4. Compatibility with Existing Standards: uv adheres to existing Python packaging standards like pyproject.toml (PEP 621). This means that projects already using these standards can easily adopt uv without significant modifications. It reads and respects your existing pyproject.toml files, making the transition relatively smooth. uv is built with a strong emphasis on modern packaging practices, encouraging the adoption of pyproject.toml for declaring project dependencies and build system requirements. This aligns with the direction the Python packaging ecosystem is heading.
5. Improved Error Messaging: While pip’s error messages have improved over time, uv, being a newer tool, has the opportunity to provide more informative and user-friendly error messages, making debugging dependency issues easier.
6. Potential for Future Enhancements: As a relatively new project with a dedicated development team, uv has the potential to introduce further optimizations and features that could significantly enhance the Python development experience. The active development and growing community support are promising signs.

How to use uv with Heroku

Now, let’s put some of this into practice. Imagine we’re building a simple Python web application (using Flask, for instance) that we want to deploy to Heroku, and we want to leverage the speed and efficiency of uv in our development and deployment process.

Here’s how we can set up our project:

1. Install uv

There are a variety of options to install uv, depending on your operating system. For a full list, take a look at the official Installation Guide site. I’m going to install it using Homebrew:

~/user$ brew install uv

2. Create the project directory and initialize uv

~/user$ uv init my-app
~/user$ cd my-app
~/user/my-app$ ls -a

In doing that, uv generates several project files

my-app/
├── main.py
├── pyproject.toml
├── README.md
└── .python-version

Our main.py looks like this:

def main():
    print("Hello from my-app!")

if __name__ == "__main__":
    main()

We can run this with the uv run main.py command which does a few things for us. In addition to actually running main.py and generating the “Hello from my-app!” output, uv also generates a virtual environment for the project and generates a uv.lock file which describes the project. More on that in a bit.

3. Expanding the project… slightly.

Let’s take this project a bit further and turn it into a Flask app that we can deploy to Heroku. We’ll need to specify our dependencies, Flask and Gunicorn for this example. We can do this using pyproject.toml.

Using pyproject.toml:

The uv generated pyproject.toml file looks like this:

[project]
name = "my-app"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires_python =">=3.13"
dependencies = []

To add dependencies we use the uv add command.

~/user/my-app$ uv add Flask
~/user/my-app$ uv add gunicorn

This accomplishes a couple of things:

First, it adds those packages to the pyproject.toml file:

[project]
name = "my-app"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires_python =">=3.13"
dependencies = [
    "Flask>=3.1.1",
    "gunicorn>=23.0.0",
]

Second, it updates the uv.lock file for dependency management.

4. Updating main.py

Let’s update the code in main.py to be a basic Flask web application

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
    return "Hello from uv on Heroku!"

if __name__ == '__main__':
    app.run(debug=True)

5. Preparing for Heroku deployment:

Heroku needs to know how to run your application. For a Flask application, we typically use Gunicorn as a production WSGI server. We’ve already included it in our dependencies.

We’ll need a Procfile in the root of our project to tell Heroku how to start our application:

web: gunicorn main:app

Here, app refers to the name of our Flask application instance in main.py.

6. Deploying to Heroku:

Now, assuming you are in the project working directory, have the Heroku CLI installed, and have logged in, you can create a local git repository and Heroku application:

~/user/my-app$ git init
~/user/my-app$ heroku create python-uv  # Replace python-uv with your desired app name
~/user/my-app$ git add .
~/user/my-app$ git commit -m "Initial commit with uv setup"

The Heroku CLI will create a remote in your git repository, but you check to make sure it’s there before you and push your code

~/user/my-app$ git remote -v
heroku https://git.heroku.com/python-uv.git (fetch)
heroku https://git.heroku.com/python-uv.git (push)
~/user/my-app$ git push heroku main

Heroku will detect your Python application, install the dependencies (based on .python-version, uv.lock and pyproject.toml), and run your application using the command specified in the Procfile.

The future is bright (and fast!)

We’re excited to announce that Heroku now natively supports uv for your Python development. By combining uv’s performance with Heroku’s fully managed runtime, teams can ship faster with greater confidence in their environment consistency. This reduces onboarding time, eliminates flaky builds, and improves pipeline performance.

While uv is still relatively new, its potential to significantly improve the Python development workflow is undeniable. The focus on speed, efficiency, and modern packaging standards addresses some of the long-standing frustrations with existing tools.

As the project matures and gains wider adoption, we can expect even more features and tighter integration with other parts of the Python ecosystem. For now, even the significant speed improvements in local development are a compelling reason for Python developers to start exploring uv.

The journey of Python package management has been one of continuous improvement, and uv represents an exciting step forward. If you’re a Python developer looking to boost your productivity and streamline your environment management, I highly recommend giving uv a try. You might just find your new favorite package manager!

Try uv out on Heroku

Whether you’re modernizing legacy apps or spinning up new services, uv gives you the speed and flexibility you need—now with first-class support on Heroku. Get started with uv on Heroku today.

The post Local Speed, Smooth Deploys: Heroku Adds Support for uv appeared first on Heroku.

We’re excited to announce the general availability of Heroku Postgres version 17, packed with new features and enhancements to your database performance. And that’s not all – we’re also introducing a game-changing feature that streamlines your upgrade experience. This new method of version upgrade is now the default, so you can try it to upgrade to Postgres 17!

Postgres 17: Powering your applications with enhanced performance and security

Before we dive into the simplicity of the new upgrade process, let’s talk about what makes PostgreSQL 17 a must-have. This release brings significant improvements that directly translate to better performance and stronger security for your applications.

• Fast Query Performance: Postgres 17 delivers notable enhancements to query optimization. Expect to see faster execution times, especially for complex queries. IN clauses with B-tree indexes should see a big improvement, so should IS NOT NULL clauses from improved query planning. Also, the new streaming I/O interface helps optimize sequential scans when reading massive amounts of data from a table.
• Improved Write Performance: For applications that heavily rely on write operations, Postgres 17 brings good news. Expect better throughput and reduced latency, ensuring your data is written quickly and efficiently, thanks to improvements with WAL processing.
• JSON Enhancements: Postgres 17 introduces enhanced JSON support, including the JSON_TABLE function to convert JSON data into standard PostgreSQL tables. Additionally, SQL/JSON constructors and query functions simplify working with JSON data.
• Vacuum Memory Optimization: Postgres 17 utilizes a new internal memory structure, leading to faster vacuum speeds and a significant reduction in memory consumption of up to 20 times. This optimization allows your workload to have more memory available since the essential PostgreSQL vacuum process now requires less memory to maintain healthy operations.
• Better Observability: Understanding how your database performs is critical. Postgres 17 brings improvements that allow for better monitoring and observation of your database instances with additional EXPLAIN output, capturing time spent for I/O block reads/writes and SERIALIZE and MEMORY options.

These enhancements, and more, mean your Heroku applications will run smoother, safer, and more efficiently with Postgres 17.

Simplify Postgres upgrades

Upgrading your Postgres database has traditionally been a multi-step process involving creating a follower database, upgrading the follower, stopping your application, waiting for data synchronization, and finally promoting the upgraded database. This process can be time-consuming, error-prone, and disruptive to your application’s availability.

We want to change all that. With the new, now default, upgrade method, we’re simplifying this process significantly. This new feature allows you to upgrade your leader Postgres database directly with a 1-step process, removing many manual steps, by default. Rest assured, we have been using this method internally, and successfully performed upgrades on nearly 20,000 databases so far.

Benefits of the new upgrade method

The new Upgrade leverages the capabilities of Postgres’ pg_upgrade utility to perform the upgrade directly on your existing database, in-place. This eliminates the need for data copying and synchronization, resulting in a faster and more efficient upgrade process.

• Reduced Manual Tasks: The new method skips many manual steps required today to perform an upgrade. The improvements in automation can help reduce human-errors and provide peace of mind during upgrades.
• Reduced Downtime: By eliminating the need for a follower database preparation and data synchronization, this in-place upgrade method significantly reduces the time required to upgrade your database.
• Simplified Process: The streamlined upgrade process eliminates the complexity of multi-step procedures that are prone to human errors, leading to safer maintenance overall.

For example, below diagram compares the typical non-Essential database upgrade process vs the new, in-place upgrade process:

Getting started with the new upgrade

The new Upgrade is available for all Heroku Postgres plans. To use the new process, simply initiate it from your CLI.

First, prepare the upgrade (skip this step if you’re on Essential plan):

heroku pg:upgrade:prepare HEROKU_POSTGRESQL_RED --app example-app

Then run the upgrade when it is ready by running below command, or wait for the next maintenance window.

heroku pg:upgrade:run HEROKU_POSTGRESQL_RED --app example-app

That’s it!

Please refer to our Dev Center article or take a look at Heroku Postgres Upgrade Guide: Simplify Your Move to Version 17 to learn more about the change.

While the new Upgrade offers significant benefits by automating many steps, it’s important to note that if the database is very large, the upgrade duration or follower recreation can take about the same time as the previous, manual approaches.

Although we are changing the default method to use the new method for upgrading going forward, you can always use pg:upgrade or pg:copy as documented here.

Conclusion

Heroku Postgres 17 launching with the new upgrade method represents a major step forward in developer experience to manage a database on Heroku. We’re committed to providing you with the tools and features you need to build and run powerful, scalable applications. Our support team is available to assist you should you have any questions or need help. Upgrade to Heroku Postgres 17 today and experience the benefits of the new upgrade method for yourself!

The post Heroku Postgres 17 with the New Upgrade Process: Faster Performance, Easier Upgrade appeared first on Heroku.

If you’ve ever deployed an app on Heroku, chances are you’ve used Heroku Postgres — our fully managed, reliable, and scalable Postgres database service. It’s the backbone for millions of applications, from weekend side projects to enterprise-grade systems running in production.

But Postgres, like all software, continues to evolve. With new versions released each year, you gain access to performance enhancements, critical security updates, and powerful new features. Keeping your database up to date isn’t just good practice — it’s essential for long-term stability and success.

That’s why we’re thrilled to share that Postgres 17 is now available on Heroku. And with our newly simplified upgrade process, keeping your database current has never been easier. There’s no better time to plan your next upgrade and take full advantage of everything Postgres 17 has to offer.

What is Heroku Postgres?

Heroku Postgres is a managed Postgres service built into the Heroku platform. It handles provisioning, maintenance, backups, high availability, and monitoring so that customers can focus on building engaging data-driven applications, instead of managing infrastructure.

Why upgrading your Postgres version matters

There are several important reasons for why upgrading your Postgres database is necessary,

• Security: Postgres regularly releases security updates to patch vulnerabilities. Running an outdated version could expose your database to known security risks. Once a version is unsupported, the Postgres Community won’t have any more security releases for that version.
• Bug Fixes: Each new version includes fixes for bugs and issues found in previous versions.
• Performance Improvements: Newer versions often include performance optimizations, better query planning, and improved resource utilization.
• New Features: Postgres releases bring new features and capabilities that can enhance your database’s functionality. For example:
  • Better parallel query execution
  • Improved indexing options
  • Enhanced monitoring capabilities
  • New data types and functions
• Compatibility: Staying current helps maintain compatibility with other tools, libraries, and applications that interact with your database.

The backstory: Our Postgres version support & deprecation policy

At Heroku, we follow a well-defined lifecycle for Postgres versions:

• Each major version is supported for a set period — currently three years.
• When a version approaches end-of-support, we begin our deprecation process — announcing an upcoming removal from the platform and stopping new provisioning.
• When deprecation is announced, we give customers advance notice and time to upgrade manually.
• If no action is taken, we then automatically upgrade databases still on unsupported versions, ensuring security and platform stability.

What we learned

Our internal upgrade automation has quietly and successfully upgraded tens of thousands of databases each year leading many customers to ask:

That demand inspired the improved pg:upgrade CLI experience — a safer, more transparent, and self-service version of our proven internal tools. Now, all Heroku Postgres users can benefit from the same automation and built-in checks that power our large-scale upgrade process.

Visit our devcenter for more details on how Heroku manages Postgres version support and deprecation timelines.

Introducing new pg:upgrade commands

We’re rolling out five new heroku pg:upgrade:* commands that give you more control, visibility, and confidence during Postgres version upgrades:

pg:upgrade:prepare – Schedule a Postgres upgrade for Standard-tier and higher leader databases during your next maintenance window.

pg:upgrade:run – Trigger an upgrade manually. Perfect to start an upgrade immediately on Essential-tier databases and follower databases, or run a prepared upgrade before the next scheduled maintenance window on a Standard-tier or higher database.

pg:upgrade:cancel – Cancel a scheduled upgrade (before it starts running).

pg:upgrade:dryrun – Simulate an upgrade on a Standard-tier or higher database using a follower to preview the upgrade experience and detect any potential issues — no impact on your production database.

pg:upgrade:wait – Track the progress of your upgrade in real time.

You’ll receive email notifications at every key stage:

• When the upgrade is scheduled, running, cancelled and completed (successfully or not).
• After a dry run completes, with a summary of the results and any potential issues detected.

Upgrading is now a simple 1-step process

You might notice there are more commands available now, but upgrading your database has actually become much simpler — it’s now just a 1-step process!

Heroku handles what used to be multiple manual steps — provisioning a follower, entering maintenance mode, promoting, reattaching, exiting maintenance mode — all with a single workflow.

See the section below for the most efficient path based on your database tier.

Step-by-step: How to upgrade Heroku Postgres

Essential-tier database upgrades

To upgrade, just run:

heroku pg:upgrade:run HEROKU_POSTGRESQL_RED --app example app

That’s it — no preparation step required.

Note: If you don’t specify a version with --version, the upgrade will use the latest supported Postgres version on Heroku.

Standard-tier & higher database upgrades

We recommend this process for Standard-tier and higher, regardless of whether or not you have follower databases.

Step 0 – Optional (but recommended)

Run a test upgrade to detect any potential issues before upgrading your production database.

heroku pg:upgrade:dryrun HEROKU_POSTGRESQL_RED --app example-app

Then proceed with the actual upgrade in one simple step:

Step 1 – Prepare the upgrade

heroku pg:upgrade:prepare HEROKU_POSTGRESQL_RED --app example-app --version 17

This schedules the upgrade for your next maintenance window.

Note: If --version is not specified, we’ll automatically use the latest supported Postgres version on Heroku.

Use the following to track when the upgrade is scheduled and ready to run:

heroku pg:upgrade:wait HEROKU_POSTGRESQL_RED --app example-app

Step 2 (Optional) – Manually run the upgrade

heroku pg:upgrade:run HEROKU_POSTGRESQL_RED --app example-app

This will upgrade your leader database and its follower(s) automatically.

Track the progress until completion with:

heroku pg:upgrade:wait HEROKU_POSTGRESQL_RED --app example-app

Tip: If you don’t manually run this command, the upgrade will be run automatically during the scheduled maintenance window. You can view your app’s maintenance window and scheduled maintenances by running:

heroku pg:info HEROKU_POSTGRESQL_RED --app example-app

For more information on maintenance windows, check out the Heroku Postgres Maintenance documentation.

Benefits of the new upgrade mechanism

• The new upgrade operates in-place using an internal replica, simplifying the process, removing the need to manage a separate follower add-on, and minimizing the risk of data loss or inconsistencies by managing database access internally throughout the upgrade.
• Using this automation will reduce downtime to about 5-10 minutes for a typical upgrade.
• When you upgrade your leader database, any followers are automatically upgraded – no need to recreate or manually reattach followers.
• Your app’s DATABASE_URL and other config_vars remain unchanged after the upgrade, ensuring your application continues to operate without any reconfiguration.
• The same simple steps apply to upgrading databases with Streaming Data Connectors, replacing what used to require at least 8 manual steps as outlined here.
• If we detect a known issue with your data/schema during the upgrade, you’ll receive an email with remediation steps to help you complete the upgrade.
• If the issue is unexpected or cannot be resolved automatically, we’ll prompt you to open a support ticket so our team can help troubleshoot.
• In all cases, your database remains available, and user access is restored once the upgrade process completes — whether it finishes successfully or is automatically aborted for safety.
• Want added peace of mind? Run a test upgrade in advance using heroku pg:upgrade:dryrun. This simulates the upgrade on a copy of your database and highlights potential issues before touching production.

The “old” follower upgrade approach

While we now recommend upgrading the leader database directly using the approach explained
above, customers who prefer the traditional flow can still use the follower upgrade approach.

To do this, you can continue to follow the steps as described here.

In order to run the upgrade, use:

heroku pg:upgrade:run HEROKU_POSTGRESQL_RED --app example-app

This approach has one notable benefit, your original leader database remains untouched during the upgrade, which allows for easier rollback, testing, or verification before promoting the upgraded follower.

Deprecation notice

The legacy heroku pg:upgrade command will be deprecated soon. To ensure a smoother, safer upgrade experience, we strongly recommend switching to the new heroku pg:upgrade:* subcommands.

If you continue to use the old command, you’ll receive tailored warnings and redirection to help guide you toward the updated flow. Make the switch today to take full advantage of the simplified, automated upgrade process.

Upgrading shouldn’t be a chore – it should be a habit

Upgrading your Postgres database shouldn’t be a last-minute scramble — it should be a routine habit. Regular upgrades help keep your applications secure and performant, while also giving you access to the latest features and improvements that drive innovation. By making upgrades a part of your development rhythm, you set your systems up for long-term stability, scalability, and success.

At Heroku, we’re focused on making the overall Postgres experience safer and more intuitive for developers. A key part of that is improving the upgrade process: with streamlined tooling, automation, and built-in safeguards, upgrading your Postgres version is now significantly faster and more reliable. All of this is designed to help you stay focused on what matters most – building and shipping great apps – while staying confident that your data layer is future-ready.

The post Heroku Postgres Upgrade Guide: Simplify Your Move to Version 17 appeared first on Heroku.

Anthropic’s Claude 4 Sonnet, part of the next generation of Claude models, is now available on Heroku Managed Inference and Agents. This gives developers immediate access to a model designed for coding, advanced reasoning, and the support of capable AI agents. Heroku Managed Inference and Agents expands your AI choices, offering the freedom to build transformative applications with the developer and operational ease Heroku is known for. Claude 4 Sonnet extends what’s possible with AI systems by improving task planning, tool use, and overall agent experience within the Heroku ecosystem.

Claude 4 Sonnet offers a significant leap in performance, balancing cutting-edge intelligence with impressive speed and cost-efficiency. It’s designed to excel at a wide range of tasks, making it a versatile tool for developers looking to integrate advanced AI capabilities into their Heroku applications.

Building with Claude 4 Sonnet made simple

Integrating Claude 4 Sonnet into your Heroku applications is streamlined through Heroku Managed Inference and Agents:

• Seamless Integration: Easily attach Claude 4 Sonnet as a resource to your Heroku app. Environment variables are automatically configured, enabling straightforward API calls from your application code.
• Build Powerful AI Agents: Combine Claude 4 Sonnet’s intelligence with Heroku’s agentic capabilities. Utilize the Model Context Protocol (MCP) to connect your LLM-powered agents to your existing tools, databases (like pgvector for Heroku Postgres for RAG), and other services within Heroku’s trusted environment.
• Unified API Access: Heroku Managed Inference and Agents provides a consistent API experience, making it easier to experiment with and switch between different models as your requirements evolve.

Getting started with Claude 4 Sonnet on Heroku

You can start leveraging Claude 4 Sonnet in your Heroku applications today.

1. Provision the Model: Attach the Claude 4 Sonnet model to your application using the Heroku CLI.

   heroku ai:models:create -a YOUR_APP_NAME claude-4-sonnet

2. Utilize API Endpoints: Once provisioned, your application will have the necessary configuration variables to make API calls to the /v1/chat/completions endpoint (or the relevant agent endpoint like /v1/agents/heroku) to interact with Claude 4 Sonnet.You can invoke the model using various methods, including curl, or libraries available for Python, Ruby, and JavaScript, as detailed in the Heroku Dev Center documentation for Managed Inference and AgentsExample curl request:

   export INFERENCE_MODEL_ID=$(heroku config:get -a $APP_NAME INFERENCE_MODEL_ID) 
   # Ensure this is the Claude 4 Sonnet ID
   export INFERENCE_KEY=$(heroku config:get -a $APP_NAME INFERENCE_KEY)
   export INFERENCE_URL=$(heroku config:get -a $APP_NAME INFERENCE_URL)
   
   curl $INFERENCE_URL/v1/chat/completions \
     -H "Authorization: Bearer $INFERENCE_KEY" \
     -H "Content-Type: application/json" \
     -d '{
           "model": "'"$INFERENCE_MODEL_ID"'",
           "messages": [
             {"role": "user", "content": "Explain the benefits of using PaaS for AI applications."}
           ]
         }'

The future of AI Development on Heroku

The addition of Claude 4 Sonnet to Heroku Managed Inference and Agents represents our ongoing commitment to providing developers with powerful, accessible AI tools. We are excited to see the innovative applications and intelligent solutions you will build.

For detailed documentation, model IDs, and further examples, please visit the Heroku Dev Center.

Start building with Claude 4 Sonnet on Heroku today and redefine what’s possible with AI!

The post Heroku AI: Claude 4 Sonnet is now available appeared first on Heroku.

Heroku recently made the next generation platform – Fir – generally available. Fir builds on the strengths of the Cedar generation while introducing a new modern era of developer experience. Fir leverages modern cloud-native technologies to provide a seamless and performant platform.

One of the goals we set out to achieve with Fir is to modernize our platform’s observability architecture. Applications being written today are becoming increasingly more distributed and complex in nature. With this increase in complexity, the need for good observability becomes critical. With solid observability practices in place, it becomes possible to gain deep insights into the internal state of these complex systems.

The Cloud Native Computing Foundation (CNCF)’s second most popular project, OpenTelemetry, standardizes and simplifies the collection of observability data (logs, metrics, and traces) for distributed systems. Integrating OpenTelemetry into Fir makes it easier to monitor, troubleshoot, and improve complex applications and services. OpenTelemetry is more than just a set of tools – it is a standard you as an end-user can benefit from a growing community of vendors that support the OpenTelemetry protocol.

It is for these reasons that we have chosen to build OpenTelemetry directly into the Fir platform. In this blog post we will explain what OpenTelemetry is and how you can quickly get started using OpenTelemetry on Heroku.

What is OpenTelemetry

OpenTelemetry is an open-standard framework that provides a standardized way to collect and export telemetry data from applications. It supports three primary signals:

• Logs: Capture discrete events that happen over time. This signal type provides detailed context for events, aiding in debugging and auditing.
• Metrics: Provide quantitative measurements of system behavior captured at runtime. Metrics offer insights into system performance and resource utilization.
• Traces: Record the execution path of requests through a system. These help in understanding the flow of requests and diagnosing latency issues.

In addition to these three signals, two more are under development.

• Events: A specific type of log, an Event is a named occurrence at an instant in time. It signals that “this thing has happened at this time”. Examples of Events might include things like uncaught exceptions, network events, user login/logout, etc.
• Profiles: A mechanism to collect performant and consistent profiling data

OpenTelemetry SDKs and Collectors

The OpenTelemetry SDK and Collector serve distinct purposes in an observability pipeline. The SDK is a library that allows developers to instrument their applications to generate telemetry like traces, metrics and logs. The collector sits downstream of the application and receives, processes and exports that telemetry data to various other backends. The collector acts as a central hub for observability data.

To recap,

An OpenTelemetry SDK:

• Provides language-specific implementations of the OpenTelemetry API.
• Empowers the developers to instrument applications, generating telemetry data.
• Manages the data collection and processing within the application.
• Sends the telemetry data to a Collector or directly to an observability backend.

An OpenTelemetry Collector:

• Is a standalone, vendor-agnostic process.
• Receives telemetry data from multiple sources, including SDKs.
• Processes the telemetry data through pipelines.
• Exports processed telemetry data to observability backends like Prometheus, Jaeger and other vendors.
• Acts as a central hub for managing telemetry pipelines.

At Heroku, our mission is to provide a platform that allows you, the developer, to focus on what matters most; building that app itself. Our platform automatically acts as the central hub for managing your telemetry pipelines.

Getting started

For the purposes of this blog post we are going to use the Getting Started on Heroku Fir with Go tutorial. Zipping through most of the instructions we can bootstrap our application using only a few commands from a terminal.

The first thing we need to do is ensure that we have the latest version of the Heroku CLI installed. If you do not have the Heroku CLI installed or need to perform an update, simply follow the instructions found in the Heroku Dev Center.

$ heroku version
heroku/10.7.0 darwin-arm64 node-v20.19.1

Now we need a Fir space, so let’s create one:

$ heroku spaces:create heroku-otel-demo --generation fir --team demo-team
 ›   Warning: Spend Alert. Each Heroku Standard Private Space costs ~$1.39/hour (max $1000/month), pro-rated to the second.
 ›   Warning: Use heroku spaces:wait to track allocation.
=== heroku-otel-demo

ID:         bdacda5f-a9b5-41a7-a613-58a546ccd645
Team:       heroku-runtime-playground
Region:     virginia
CIDR:       2600:1f18:7a42:c600::/56
Data CIDR:
State:      allocated
Shield:     off
Generation: fir
Created at: 2025-04-23T20:51:39Z

Next we need to clone down the repository and change in our working directory:

$ git clone https://github.com/heroku/go-getting-started.git
Cloning into 'go-getting-started'...
remote: Enumerating objects: 4352, done.
remote: Counting objects: 100% (897/897), done.
remote: Compressing objects: 100% (711/711), done.
remote: Total 4352 (delta 470), reused 162 (delta 162), pack-reused 3455 (from 2)
Receiving objects: 100% (4352/4352), 10.62 MiB | 3.26 MiB/s, done.
Resolving deltas: 100% (1734/1734), done.

$ cd go-getting-started/

Now, we can simply create the application and push the code to Heroku:

$ heroku create --space heroku-otel-demo
Creating app in space heroku-otel-demo... done, ⬢ fathomless-island-10342
https://fathomless-island-10342-6bd6dfa13d9e.aster-virginia.herokuapp.com/ | https://git.heroku.com/fathomless-island-10342.git

$ git push heroku main
Enumerating objects: 3679, done.
Counting objects: 100% (3679/3679), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2033/2033), done.
Writing objects: 100% (3679/3679), 8.35 MiB | 448.00 KiB/s, done.
Total 3679 (delta 1444), reused 3676 (delta 1444), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (1444/1444), done.
remote: Updated 1310 paths from 49f32a9
remote: Compressing source files... done.
remote: Building source:
...

Finally, we can verify that the application is running using one last command:

$ heroku open

This will open your default browser window. You should see something like this:

Great! We’ve got a functioning application running inside a Fir Space. Our next step is to send any platform telemetry to an observability vendor. For this demo, we’re going to use Grafana Cloud. Head over to grafana.com and create a Cloud Free account. Once you have signed up you will be presented with a Welcome to Grafana Cloud page.

At this point, we are going to skip the rest of the “Getting started” steps. The directions provided by the setup guide do not apply to how we are going to send telemetry data. For now, we can simply click “Skip setup”.

The easiest way to establish a Heroku Telemetry Drain to Grafana Cloud is to use a slightly different path. In a new browser tab, we will simply use the Grafana Cloud Portal. From Grafana.com click “My Account”.

From there, click the “Details” button next to your Grafana Cloud stack. Mine is called herokudemo. Next click on the OpenTelemetry “Configure” button.

For now, don’t worry about copying any of the details to your Clipboard. Instead, scroll down to the “Password / API Token” section and click on the “Generate now” link. Give your token a name. Once you are done, make sure you keep a copy of the generated token for future reference. Now that we have a token, scroll down a bit more and copy the contents of the “Environment Variables” section to your clipboard.

Now we can head back to our terminal window and paste environment variables. We can confirm that pasting the environment variables work by using echo quickly:

$ echo $OTEL_EXPORTER_OTLP_ENDPOINT
https://otlp-gateway-prod-ca-east-0.grafana.net/otlp

$ echo $OTEL_EXPORTER_OTLP_HEADERS
Authorization=Basic MTIzOTIwMjpnbGNfZXlKdklqb2lNVFF4TXpFMU15SXNJbTRpT2lKemRHRmpheTB4TWpNNU1qQXlMVzkwYkhBdGQzSnBkR1V0WkdWdGJ5SXNJbXNpT2lKNE5GZFZOa3hDY0RNNU16VkxOR0ptVkVjMGN6ZE9XVGNpTENKdElqcDdJbklpT2lKd2NtOWtMV05oTFdWaGMzUXRNQ0o5ZlE9PQ==

Next, we will convert the headers into a json format that the Heroku CLI command expects.

$ export HEROKU_OTLP_HEADERS="$(echo "$OTEL_EXPORTER_OTLP_HEADERS" | sed 's/^\([^=]*\)=\(.*\)$/{"\1":"\2"}/')"

$ echo $HEROKU_OTLP_HEADERS
{"Authorization":"Basic MTIzOTIwMjpnbGNfZXlKdklqb2lNVFF4TXpFMU15SXNJbTRpT2lKemRHRmpheTB4TWpNNU1qQXlMVzkwYkhBdGQzSnBkR1V0WkdWdGJ5SXNJbXNpT2lKNE5GZFZOa3hDY0RNNU16VkxOR0ptVkVjMGN6ZE9XVGNpTENKdElqcDdJbklpT2lKd2NtOWtMV05oTFdWaGMzUXRNQ0o5ZlE9PQ=="}

Finally, we can add the Heroku Telemetry Drain:

$ heroku telemetry:add --app fathomless-island-10342 $OTEL_EXPORTER_OTLP_ENDPOINT --transport http --headers "$HEROKU_OTLP_HEADERS"
successfully added drain https://otlp-gateway-prod-ca-east-0.grafana.net/otlp

Back from the Grafana Cloud dashboard, after a few minutes you will start to see some application specific metrics flowing into Grafana Cloud.

Now if you navigate back to your application in the browser (Pro Tip, use heroku open), and hit refresh a few times you should also start to see traces and logs flowing into Grafana Cloud as well.

In Conclusion: Fir’s Observability Power – And Where We Go From Here

So, as we’ve shown, Heroku’s Fir platform, with its built-in OpenTelemetry, streamlines the process of setting up observability for your applications. This means you can move quickly from deploying your app to gaining critical insights into its performance, as demonstrated by the walkthrough using Grafana Cloud. But what you’ve seen here is just one of the many benefits of Heroku’s next-generation platform. In the next part of this series, we’ll dive deeper into how to effectively analyze the telemetry data you’re now collecting. We’ll explore techniques for querying, visualizing, and correlating traces, metrics, and logs to unlock powerful insights that will help you optimize your application’s behavior and troubleshoot issues like a pro.

To get the full picture of everything the Fir platform offers, from enhanced observability to a modern developer experience, don’t forget to watch the Fir launch webinar on-demand!

The post OpenTelemetry Basics on Heroku Fir appeared first on Heroku.

The speed and efficiency of the Go programming language make it popular for backend development. Combine Go with the Gin framework—which offers a fast and minimalistic approach to building web applications—and developers can easily create high-performance APIs and web services. Whether you’re working on a personal project or building a production-ready application, Go and Gin make for an attractive stack perfectly suited for lightweight, scalable web development.

Creating a Go/Gin application might seem straightforward: You write a few routes, connect a database, and spin up a local server. But when it comes to deploying your app, things can get tricky. Developers unfamiliar with cloud deployment often struggle with configuring environment variables, managing dependencies, and ensuring their app runs smoothly on a hosting platform.

Fortunately, Heroku makes this process incredibly simple. With its streamlined deployment workflow and built-in support for Go, Heroku lets you deploy your Go/Gin app with minimal configuration.

In this article, we’ll walk through the process of building and deploying a Go/Gin web application on Heroku. We’ll set up a local development environment, prepare an application for deployment, and deploy it to run on Heroku. Along the way, we’ll cover best practices and troubleshooting tips to ensure a smooth deployment.

By the end of this guide, you’ll have a fully functional Go/Gin application running on Heroku—and you’ll gain the knowledge needed to deploy future projects with confidence. Let’s get started!

Setting up your development environment

To get started, you must set up your development environment. Here are the steps to install what you need and test your application locally.

An example project can be found in this GitHub repository.

Download and install Go

Download the Go installer from the official Go website, making sure you choose the correct operating system. For Windows or Linux, follow the respective installation instructions on the website.

If you’re on macOS, you can use Homebrew:

$ brew install go

Once installed, verify your installation by running:

$ go version

You should see your Go version printed in the terminal. For this guide, we’re running version 1.24.0.

Set up your workspace

Create a new directory for your project and initialize a Go module. Open your terminal and execute:

~/project$ go mod init github.com/YOUR-USERNAME/YOUR-REPO-NAME

This neatly organizes your project and its dependencies, ensuring everything is in order. In the examples to follow YOUR-REPO-NAME will be go-gin.

Add the Gin framework

Now it’s time to invite Gin to the party. Gin is a high-performance web framework that will help you build your REST server fast.

Run the following command to add Gin to your project:

~/project$ go get github.com/gin-gonic/gin

This fetches the Gin package and its dependencies.

The server application code goes in a file called main.go. Download that code here.

Finally, run the server:

~/project$ go run main.go

Test your application locally

Before declaring your quest a success, make sure your application runs smoothly on your local machine. As you run the server as described above, you’ll see output indicating that it’s up and running.

~/project$ go run main.go

[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:	export GIN_MODE=release
 - using code:	gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /quotes                   --> main.main.func1 (3 handlers)
[GIN-debug] GET    /quote                    --> main.main.func2 (3 handlers)
[GIN-debug] POST   /quote                    --> main.main.func3 (3 handlers)
[GIN-debug] [WARNING] You trusted all proxies, this is NOT safe. We recommend you to set a value.
Please check https://pkg.go.dev/github.com/gin-gonic/gin#readme-don-t-trust-all-proxies for details.
[GIN-debug] Listening and serving HTTP on :8080

Test your API server endpoints by sending a curl request in a separate terminal window. For example:

$ curl -s -X GET https://localhost:8080/quote | jq
{
  "quote": "The journey of a thousand miles begins with a single step."
}

(We use jq to pretty-print the JSON result.)

Creating a Heroku App

Assuming you have installed the Heroku CLI, you can create a new Heroku app. Run the following commands:

~/project$ heroku login

~/project$ heroku apps:create my-go-gin-api

Creating ⬢ my-go-gin-api... done
https://my-go-gin-api-7f40e19ce771.herokuapp.com/ | https://git.heroku.com/my-go-gin-api.git

This creates your Heroku app, accessible at the app URL (in the above example, that’s https://my-go-gin-api-7f40e19ce771.herokuapp.com/). The command also creates a Git remote so you can push your code repo to Heroku with a single command.

~/project$ git remote show heroku

* remote heroku
  Fetch URL: https://git.heroku.com/my-go-gin-api.git
  Push  URL: https://git.heroku.com/my-go-gin-api.git

You’ll also see your newly created app in your Heroku Dashboard. Clicking the Open app button will take you to your app URL.

Create the Procfile

The Procfile tells Heroku how to run your application. In your project’s root directory, create a file named Procfile (without any extension). For most simple Go applications, your Procfile will consist of a single line, like this:

web: go run main.go

This tells Heroku that your app will be a web process, and Heroku should start the process by running the command go run main.go. Simple enough! Add the file to your repository.

Tidy up your Go project

Finally, use the following command to clean up your go.mod file to ensure all dependencies are properly listed:

$ go mod tidy

Ensure your go.mod and go.sum files have also been added to your repository. This allows Heroku to automatically download and manage dependencies during deployment with the Procfile.

Deploying your application

After completing these simple preparation steps, you’re ready to push your project to Heroku. Commit your changes. Then, push them to your Heroku remote.

~/project$ git add .
~/project$ git commit -m "Prepare app for Heroku deployment"
~/project$ git push heroku main

The git push command will set off a flurry of activity in your terminal, as Heroku begins building your application in preparation to run it:

…
Writing objects: 100% (26/26), 9.52 KiB | 9.52 MiB/s, done.
…
remote: Building source:
remote:
remote: -----> Building on the Heroku-24 stack
remote: -----> Determining which buildpack to use for this app
remote: -----> Go app detected
remote: -----> Fetching jq... done
remote: -----> Fetching stdlib.sh.v8... done
remote: ----->
remote:        Detected go modules via go.mod
remote: ----->
remote:        Detected Module Name: github.com/your-username/go-gin
remote: ----->
remote: -----> New Go Version, clearing old cache
remote: -----> Installing go1.24.0
remote: -----> Fetching go1.24.0.linux-amd64.tar.gz... done
remote: -----> Determining packages to install
remote: go: downloading github.com/gin-gonic/gin v1.10.0
…
remote:        
remote:        Installed the following binaries:
remote:        		./bin/go-gin
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote: 
remote: -----> Compressing...
remote:        Done: 6.6M
remote: -----> Launching...
remote:        Released v3
remote:        https://my-go-gin-api-7f40e19ce771.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done.
To https://git.heroku.com/my-go-gin-api.git
 * [new branch]      main -> main

This output tells you the location of the binary that Heroku built during the deploy process. In this case, it is at: ./bin/go-gin. For some Go applications, if you have trouble reaching your service and see errors in the logs, you might need to edit your Procfile to have Heroku run the binary directly, rather than using go directly with the source file. For example, your modified Procfile might look like this:

web: ./bin/go-gin

Test the live application

With your Go application running on Heroku, you can test it by sending a curl request to your Heroku app URL. For example:

$ curl -s \
    -X GET https://my-go-gin-api-7f40e19ce771.herokuapp.com/quote | jq

{
  "quote": "This too shall pass."
}

To ensure everything is running smoothly after deployment, you can the following command to tail the server’s live logs:

~/project$ heroku logs --tail

…
2025-02-25T15:11:01.922123+00:00 heroku[web.1]: State changed from starting to up
2025-02-25T15:11:22.000000+00:00 app[api]: Build succeeded
2025-02-25T15:16:31.411009+00:00 app[web.1]: [GIN] 2025/02/25 - 15:16:31 | 200 |      29.199µs |   174.17.39.113 | GET      "/quote"
2025-02-25T15:16:31.411487+00:00 heroku[router]: at=info method=GET path="/quote" host=my-go-gin-api-7f40e19ce771.herokuapp.com request_id=7df071ec-9841-499f-b584-61574920e9df fwd="174.17.39.113" dyno=web.1 connect=0ms service=0ms status=200 bytes=186 protocol=https

It’s time for you to Go!

In this article, we walked through each step of creating your Go application that uses the Gin framework, from project setup to Heroku deployment. You can see the power and simplicity of combining Gin’s robust routing capabilities with Heroku’s flexible, cloud-based platform. On top of this, it’s easy to scale your applications as your needs evolve.

Explore the additional features both Heroku and Gin offer. Heroku’s extensive add-on ecosystem can boost your application’s functionality. You can also tap into advanced Gin middleware to optimize performance and strengthen security. To learn more, check out the following resources:

• Getting Started on Heroku with Go
• Heroku Go Support
• Heroku Go Buildpacks
  • Cedar generation (classic)
  • Fir generation (cloud native)
• Heroku Add-ons
• The Gin Web Framework
• External middleware for use with Gin

The post Deploying a Simple Go/Gin Application on Heroku appeared first on Heroku.

SignalR makes it easy to add real-time functionality to .NET web applications—things like live chat, instant notifications, or interactive dashboards. But what happens when your app starts to grow? A single server can only take you so far. At some point, you’ll need to take advantage of SignalR scaling features to scale out your app.
In this post, we’ll walk through what it takes to scale a SignalR app to run across multiple servers. We’ll start with the basics, then show you how to use Redis as a SignalR backplane and enable sticky sessions to keep WebSocket connections stable. And we’ll deploy it all to Heroku. If you’re curious about what it takes to run a real-time app across multiple dynos, this guide is for you.

What is SignalR?

SignalR is a .NET library for real-time communication between servers and clients. It abstracts complex connection management and simplifies the scale-out of real-time apps. Developers use SignalR to build live chat, notifications, dashboards, and other interactive web features with minimal setup.

SignalR vs. WebSockets

Before we dive into the details of SignalR scalability, it’s useful to understand why you’d use SignalR instead of just using WebSockets. WebSockets provide a low-level protocol for persistent, two-way communication between client and server. But scaling out WebSocket connections across multiple servers can be complex. Each server only knows about its own clients, which makes it difficult to coordinate communication.

SignalR abstracts WebSockets and other protocols, simplifies connection management, and provides native integration with a Redis backplane (among other backplane options). It makes real-time communication scalable and reliable. You can implement SignalR scaling across multiple dynos with minimal configuration compared to hand-rolling a WebSockets solution.

Introduction to our app

For my demo application, I started with Microsoft’s tutorial project on building a real-time application using SignalR, found here. Because we’re focusing on how to scale a SignalR application, we won’t spend too much time covering how to build the original application.

You can access the code used for this demo in our GitHub repository. I’ll briefly highlight a few pieces.

I used .NET 9.0 (9.0.203 at the time of writing). To start, I created a new web application:

~$ dotnet new webapp -o SignalRChat

The template "ASP.NET Core Web App (Razor Pages)" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/aspnetcore/9.0-third-party-notices for details.

Processing post-creation actions...
Restoring /home/user/SignalRChat/SignalRChat.csproj:
Restore succeeded

Then, I installed LibMan to get the JavaScript client library for our SignalR project.

~/SignalRChat$ dotnet tool install -g Microsoft.Web.LibraryManager.Cli

~/SignalRChat$ libman install @microsoft/signalr@latest \
  -p unpkg \
  -d wwwroot/js/signalr \
  --files dist/browser/signalr.js

With my dependencies in place, I created the following files:

• hubs/ChatHub.cs: The hub class that serves as a high-level pipeline and handles client-server communication.
• Pages/Index.cshtml: The main Razor file, combining HTML and embedded C# with Razor syntax.
• wwwroot/js/chat.js: The chat logic for the application.

Lastly, I had the main application code in Program.cs:

using SignalRChat.Hubs;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();
app.MapHub("/chatHub");

app.Run();

You’ll notice in this initial version that I’ve added SignalR, but I haven’t configured it to use a Redis backplane yet. We’ll iterate and get there soon.

For a sanity check, I tested my application.

~/SignalRChat$ dotnet build

Restore complete (0.2s)
  SignalRChat succeeded (3.1s) → bin/Debug/net9.0/SignalRChat.dll

Build succeeded in 3.7s

~/SignalRChat$ dotnet run

Using launch settings from /home/user/SignalRChat/Properties/launchSettings.json...
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:5028
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/user/SignalRChat

In one browser, I navigated to https://localhost:5028. Then, with a different browser, I navigated to the same page.

I verified that both browsers had WebSocket connections to my running application, and I posted a message from each browser.

In real time, the messages posted in one browser were displayed in the other. My app was up and running.

Now, it was time to scale.

How to scale SignalR

Scaling a SignalR app isn’t as simple as just adding more servers. Out of the box, each server maintains its own list of connected clients. That means if a user is connected to server A, and a message is sent through server B, that user won’t receive it—unless there’s a mechanism to synchronize messages across all servers. This is where scaling gets tricky.

To pull this off, you need two things:

• Backplane: The backplane handles message coordination between servers. It ensures that when one instance of your app sends a message, all other instances relay that message to their connected clients. A Redis backplane is commonly used for this purpose because it’s fast, lightweight, and supported natively by SignalR.
• Sticky sessions: WebSockets are long-lived connections, and if your app is spread across multiple servers, you can’t have a user’s connection bouncing between them. Sticky sessions make sure all of a user’s requests are routed to the same server, which keeps WebSocket connections stable and prevents dropped connections during scale-out.

By combining these two techniques, you set your SignalR app up to handle real-time communication at scale. Let’s walk through how I did this.

Using Redis as a backplane

The first task in scaling up meant modifying my application to use Redis as a backplane. First, I added the StackExchange.Redis package for .NET.

~/SignalRChat$ dotnet add package \
               Microsoft.AspNetCore.SignalR.StackExchangeRedis

Then, I modified Program.cs, replacing the original builder.Services.AddSignalR(); line with the following:

var redisUrl = Environment.GetEnvironmentVariable("REDIS_URL") ?? "localhost:6379";

if (redisUrl == "localhost:6379") {
    builder.Services.AddSignalR().AddStackExchangeRedis(redisUrl, options =>
    {
        options.Configuration.ChannelPrefix = RedisChannel.Literal("SignalRChat");
        options.Configuration.Ssl = redisUrl.StartsWith("rediss://");
        options.Configuration.AbortOnConnectFail = false;
    });
} else {
    var uri = new Uri(redisUrl);
    var userInfoParts = uri.UserInfo.Split(':');
    if (userInfoParts.Length != 2)
    {
        throw new InvalidOperationException("REDIS_URL is not in the expected format ('redis://user:password@host:port')");
    }

    var configurationOptions = new ConfigurationOptions
    {
        EndPoints = { { uri.Host, uri.Port } },
        Password = userInfoParts[1],
        Ssl = true,
    };
    configurationOptions.CertificateValidation += (sender, cert, chain, errors) => true;

    builder.Services.AddSignalR(options =>
    {
        options.ClientTimeoutInterval = TimeSpan.FromSeconds(60); // default is 30
        options.KeepAliveInterval = TimeSpan.FromSeconds(15);     // default is 15
    }).AddStackExchangeRedis(redisUrl, options => {
        options.Configuration = configurationOptions;
    });
}

The above code configures the SignalR application to use Redis, connecting via a default address (localhost:6379) or through a connection string in the environment variable, REDIS_URL. Using REDIS_URL is an example of me thinking ahead, as I plan to deploy this application to Heroku with the Heroku Key-Value Store add-on.

For how to set up the Redis connection between my .NET application and my Heroku Key-Value Store add-on, I took my cues from here.

With Program.cs modified to use Redis as a backplane, I tested my application locally again.

~/SignalRChat$ dotnet run

This time, with my two browser windows open, I also opened a terminal and connected to my local Redis instance, running on port 6379. I listed the Pub/Sub channels and then subscribed to the main ChatHub channel.

127.0.0.1:6379> pubsub channels

1) "SignalRChat__Booksleeve_MasterChanged"
2) "SignalRChatSignalRChat.Hubs.ChatHub:internal:ack:demo_b3204c22a84c9"
3) "SignalRChatSignalRChat.Hubs.ChatHub:internal:return:demo_b3204c22a84c9"
4) "SignalRChatSignalRChat.Hubs.ChatHub:all"
5) "SignalRChatSignalRChat.Hubs.ChatHub:internal:groups"

127.0.0.1:6379> subscribe SignalRChatSignalRChat.Hubs.ChatHub:all

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "SignalRChatSignalRChat.Hubs.ChatHub:all"
3) (integer) 1

In one browser, I sent a message. Then, in the other, I sent a reply. Here’s what came across in my Redis CLI:

1) "message"
2) "SignalRChatSignalRChat.Hubs.ChatHub:all"
3) "\x92\x90\x81\xa4json\xc4W{\"type\":1,\"target\":\"ReceiveMessage\",\"arguments\":[\"Chrome User\",\"This is my message.\"]}\x1e"
1) "message"
2) "SignalRChatSignalRChat.Hubs.ChatHub:all"
3) "\x92\x90\x81\xa4json\xc4Y{\"type\":1,\"target\":\"ReceiveMessage\",\"arguments\":[\"Firefox User\",\"And this is a reply.\"]}\x1e"

I successfully verified that my SignalR application was using Redis as its backplane. Scaling task one of two was complete!

Moving on to sticky sessions, I would need to scale. For that, I needed to deploy to Heroku.

Deploying to Heroku

Deploying my Redis-backed application to Heroku was straightforward. Here were the steps:

Step #1: Login

~/SignalRChat$ heroku login

Step #2: Create app

~/SignalRChat$ heroku create signalr-chat-demo

Creating ⬢ signalr-chat-demo... done
https://signalr-chat-demo-b49ac4212f6d.herokuapp.com/ | https://git.heroku.com/signalr-chat-demo.git

Step #3: Add the Heroku Key-Value Store add-on

~/SignalRChat$ heroku addons:add heroku-redis

Creating heroku-redis on ⬢ signalr-chat-demo... ~$0.004/hour (max $3/month)
Your add-on should be available in a few minutes.
! WARNING: Data stored in essential plans on Heroku Redis are not persisted.
redis-solid-16630 is being created in the background. The app will restart when complete...
Use heroku addons:info redis-solid-16630 to check creation progress
Use heroku addons:docs heroku-redis to view documentation

I waited a few minutes for Heroku to create my add-on. After this was completed, I had access to REDIS_URL.

~/SignalRChat$ heroku config

=== signalr-chat-demo Config Vars

REDIS_URL: rediss://:pcbcd9558e402ff2615a4484ac5ca9ac373f811e53bcb17f81ada3c243f8a11cc@ec2-52-20-254-181.compute-1.amazonaws.com:8150

Step #4: Add a Procfile

Next, I added a file called Procfile to my root project folder. The Procfile tells Heroku how to start up my app. It has one line:

web: cd bin/publish; ./SignalRChat --urls https://*:$PORT

Step #5: Push code to Heroku

~/SignalRChat$ git push heroku main
…
remote: -----> Building on the Heroku-24 stack
remote: -----> Using buildpack: heroku/dotnet
remote: -----> .NET app detected
remote: -----> SDK version detection
remote:        Detected .NET project: `/tmp/build_ad246347/SignalRChat.csproj`
remote:        Inferring version requirement from `/tmp/build_ad246347/SignalRChat.csproj`
remote:        Detected version requirement: `^9.0`
remote:        Resolved .NET SDK version `9.0.203` (linux-amd64)
remote: -----> SDK installation
remote:        Downloading SDK from https://builds.dotnet.microsoft.com/dotnet/Sdk/9.0.203/dotnet-sdk-9.0.203-linux-x64.tar.gz ... (0.7s)
remote:        Verifying SDK checksum
remote:        Installing SDK
remote: -----> Publish app
…
remote: -----> Launching...
remote:        Released v4
remote:        https://signalr-chat-demo-b49ac4212f6d.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done.

Step #6: Test Heroku app

In my two browser windows, I navigated to my Heroku app URL (in my case, https://signalr-chat-demo-b49ac4212f6d.herokuapp.com/) and tested sending messages to the chat.

I also had a terminal window open, connecting to my Heroku Key-Value Store add-on via heroku redis:cli. Just like I did when testing locally, I subscribed to the main chat channel. As I sent messages, they came across in Redis.

redis:8150> subscribe SignalRChat.Hubs.ChatHub:all
1) subscribe
2) SignalRChat.Hubs.ChatHub:all
3) 2
redis:8150> 1) message
2) SignalRChat.Hubs.ChatHub:all
3) ''''json'R{"type":1,"target":"ReceiveMessage","arguments":["Chrome User","I'm on Heroku!"]}
redis:8150> 1) message
2) SignalRChat.Hubs.ChatHub:all
3) ''''json'M{"type":1,"target":"ReceiveMessage","arguments":["Firefox User","So am I!"]}

As another sanity check, I looked in my developer tools console in my browser. Looking in the Network Inspector, I saw a stable WebSocket connection (wss://) as well as the inbound and outbound connection data.

I had successfully deployed to Heroku, using Redis as my backplane. I hadn’t scaled up to multiple dynos just yet, but everything was looking smooth so far.

Scaling with multiple dynos

Next, I needed to scale up to use multiple dynos. With Heroku, this is simple. However, you can’t scale up with Eco or Basic dynos. So, I needed to change my dyno type to the next level up: standard-1x.

~/SignalRChat$ heroku ps:type web=standard-1x

Scaling dynos on signalr-chat-demo... done
=== Process Types

 Type Size        Qty Cost/hour Max cost/month 
 ──── ─────────── ─── ───────── ────────────── 
 web  Standard-1X 1   ~$0.035   $25            

=== Dyno Totals

 Type        Total 
 ─────────── ───── 
 Standard-1X 1

With my dyno type set, I could scale up to use multiple dynos. I went with three.

~/SignalRChat$ heroku ps:scale web=3
Scaling dynos... done, now running web at 3:Standard-1X

Maintaining WebSocket connections with SignalR sticky sessions

I reloaded the application in my browser. Now, my inspector console showed an issue:

Here’s the error:

Error: Failed to start the transport 'WebSockets': Error: WebSocket failed to connect. The connection could not be found on the server, either the endpoint may not be a SignalR endpoint, the connection ID is not present on the server, or there is a proxy blocking WebSockets. If you have multiple servers check that sticky sessions are enabled.

That’s a pretty helpful error message. Just as we had expected, our real-time SignalR application would run into issues once we scaled up to multiple dynos. What was the solution? Sticky sessions with Heroku’s session affinity feature.

Enabling Heroku session affinity

This feature from Heroku works to keep all HTTP requests coming from a client consistently routed to a single dyno. It’s easy to set up, and it would solve our multi-dyno WebSocket connection issue.

~/SignalRChat$ heroku features:enable http-session-affinity

Enabling http-session-affinity for ⬢ signalr-chat-demo... done

That was it. With sticky sessions enabled, I was ready to test again.

Testing with sticky sessions on multiple dynos

I reloaded the application in both browsers. This time, my network inspector showed no errors. It looked like I had a stable WebSocket connection.

Real-time chat messages were sent and received without any problems.

Success!

Wrapping up

With Redis as a SignalR backplane and sticky sessions enabled, our SignalR app scaled seamlessly across multiple dynos on Heroku. It delivered real-time messages smoothly, and the WebSocket connections remained stable even under a scaled-out setup.

The takeaway? You don’t need a complicated setup to scale SignalR, just the right combination of tooling and configuration. Whether you’re building chat apps, live dashboards, or collaborative tools, you now have a tested approach to scale real-time experiences with confidence.

Ready to build and deploy your own scalable SignalR application? Check out the .NET Getting Started guide for foundational knowledge. For a visual walkthrough of deploying .NET applications to Heroku, watch our Deploying .NET Applications on Heroku video.

The post SignalR Scalability: Scaling Real-Time SignalR Applications on Heroku appeared first on Heroku.

Many of the most exciting experiences we’re beginning to rely on every day are powered by AI; whether it’s conversational assistants, personalized recommendations or code generation, these experiences are powered by inference systems and intelligent agents. Behind the scenes, developers offload complex decisions, automate tasks, and compose intelligent applications using large language models and tool execution flows. Together, these AI-powered primitives are becoming a key complement to traditional application development, enabling a new wave of developer capabilities.

At Salesforce, we are helping our customers bring their agentic strategy to life with Heroku, Agentforce, and Data Cloud. These powerful products allow anyone in the company, from business analysts to developers to build robust, custom agents that can transform their business. Behind the scenes, developers offload complex decisions, automate tasks, and compose intelligent applications using large language models and tool execution flows. Together, these AI-powered primitives are becoming a key complement to traditional application development, enabling a new wave of developer capabilities.

Heroku Managed Inference and Agents bring together a set of powerful primitives that make it simple for developers to build, scale, and operate AI-powered features and applications, without the heavy lifting of managing their own AI infrastructure. With access to leading models from top providers and elegant primitives for building agents that can reason, act, and call tools, developers can focus on delivering differentiated experiences for their users, rather than wrangling inference infrastructure or orchestration logic.

Managed Inference for simplified AI integration

Managed Inference provides ready-to-use access to a curated set of powerful AI models, chosen for their generative power and performance, optimized for ease of use and efficacy in the domains our customers need most. Whether you’re looking to generate text, classify content, summarize documents, or build intelligent workflows, you can now bring AI to your Heroku apps in seconds.

Getting started is as easy as attaching the Heroku Managed Inference and Agents add-on to your app or running: heroku ai:models:create

Agents with Model Context Protocol

Extend Managed Inference with an elegant set of primitives and operations, allowing developers to create agents that can execute code in Heroku’s trusted Dynos, as well as call tools and application logic. These capabilities allow agents to act on behalf of the customer, and to extend both application logic and platform capabilities. Allowing developers to interleave application code, calls to AI, execute logic created by AI, and use of tools, all within the programmatic context. Heroku Managed Inference and Agents can now do more than just generate, it can reason, act, and build by adapting to context, and evolving with your users’ needs.

Heroku Managed Inference and Agents uses the Model Context protocol (MCP) to give your agents new capabilities. MCP helps you build agents and complex workflows by standardizing the way you can provide context and integrate tools. This means you can expose your app’s logic, APIs or custom tools to agents such as Agentforce, Claude or Cursor with custom code.

Heroku Managed Inference and Agents currently supports STDIO MCP servers. Attaching your MCP servers is as simple as attaching your add-on to your Heroku app which contains the MCP server. We are actively developing platform capabilities to support remote MCP servers hosted on heroku, which will feature OAuth integration and buildpack capabilities.

What’s next

Heroku Managed Inference and Agents marks a major milestone on our journey to provide AI-native capabilities on the platform and we’ve designed it with the graceful developer and operator experiences you’ve come to expect. Combined with MCP Server support, AppLink for Agentforce integration, and an evolving selection of curated models and tools, developers will be able to rapidly integrate the latest AI advancements and create next-generation, intelligent user experiences.

Again, to get started, provision Managed Inference and Agents from Heroku Elements or via the command line. We are excited to see what you build with Heroku Managed Inference and Agents! Attend our webinar on May 28 to see a demo and get your questions answered!

To learn more about Heroku AI, check out our Dev Center docs and try it out for yourself.

Interested in unlocking the full potential of your AI agents? Read Heroku AI: Build and Deploy Enterprise Grade MCP Servers.

Stay tuned for more — we’re just getting started.

The post Heroku AI: Managed Inference and Agents is now Generally Available appeared first on Heroku.

Agents hold immense power, but their true potential shines when they connect to the real world, fetching data, triggering actions, or leveraging external tools. The Model Context Protocol (MCP) offers a standardized way for AI agents to do this.

Heroku Managed Inference and Agents dramatically simplifies hosting these MCP servers and making them available, not only to itself, but also to external agents like Claude, Cursor, or Agentforce. These new capabilities accelerate industry standardization towards agent interoperability by reducing the infrastructure, security, and discovery challenges in building and running MCP servers. Heroku Managed Inference and Agents provides:

• Community SDK support: Build your servers using the official MCP SDK, or any other MCP SDK of your choice.
• Effortless Management: Once you have a server running, set up your Procfile and push to Heroku. The Managed Inference and Agents add-on automatically manages server registration with the MCP Toolkit.
• Unified Endpoint: Managed Inference and Agents automatically has access to all registered servers. Additionally, a MCP Toolkit URL is generated, which can be used to access your servers in external clients.
• Only Pay for What You Use: MCP servers managed by the MCP Toolkit are spun up when in use, and are spun down when there are no requests.

This guide walks you through setting up your own MCP server on Heroku and enabling your Agent to securely and efficiently perform real-world tasks.

Before getting started

MCP Servers are just like any other software application, and therefore can be deployed to Heroku as standalone apps. So while you could build your own multi-tenant SSE server and deploy it yourself, Heroku MCP Toolkits help you do things that standalone servers cannot do.

1. First and foremost, they make it seamless to integrate servers with your Heroku Managed Inference and Agents.
2. Secondly, they allow tools to be scaled to 0 by default, and spun up only when needed – making them more cost efficient for infrequent requests.
3. Thirdly, they provide code isolation which enables secure code execution for LLM generated code.
4. Finally, they wrap multiple servers in a single url making it incredibly easy to connect with external clients.

Getting started: Create and deploy your first MCP Server

1. Step 1 – Build your Server
   1. Use an official MCP SDK to create an MCP Server. Note: At this stage, Heroku MCP Toolkits only support STDIO servers. We are working on streamlining platform support for SSE/http servers with authentication.
   2. MCP Servers are normal Heroku Apps built on the language of your choice. For example, if you are using node, you’ll want to follow best practices and ensure your node and npm engines are set in your package.json like you would typically for a node app on Heroku.
2. Step 2 – Add the MCP process type
   1. Define your MCP process via Procfile with a process prefix of mcp*. E.g. mcp-heroku: npm start (example)
3. Step 3 – Deploy your server
   1. Once your app is deployed, all mcp* process types will be ready to be picked up by the Heroku Managed Inference and Agents add-on.

For more examples, take a look at the sample servers listed in our dev center documentation.

Creating an MCP Toolkit

Attach the Heroku Managed Inference and Agents add-on to the app that you just created. This will register any apps defined in the app to the MCP Toolkit. Each new Managed Inference and Agents add-on will correspond to a new MCP Toolkit.

1. Navigate to Your App: Open your application’s dashboard on Heroku.
2. Go to Resources: Select the “Resources” tab.
3. Add Managed Inference and Agents: Search for “Managed Inference and Agents” in the add-ons section and add it to your app.

What plan to select

Each Managed Inference and Agents plan has a corresponding model (ex. Claude 3.5 Haiku or Stable Image Ultra). You should select the model that aligns with your needs. If your goal is to give your model access to MCP tools, then you will need to select one of the Claude chat models. If you have no need for a model, and only want to host MCP tools for external use, that can be done by selecting any plan. Inference usage is metered, so you will incur no cost if there is no usage of Heroku managed models.

As far as the MCP servers are concerned, you will pay for the dyno units consumed by the one-off dynos that are spun up. The cost of tool calls depends on the specific dyno tier selected for your app, but the default eco dynos, that is about .0008 cents/second. Each individual tool call is capped at 300 seconds.

If you decide to host your inference on Heroku, your inference model will have the following default tools free of charge. This includes tools like Code Execution and Document/Web Reader.

Managing and using your MCP Toolkit

The MCP Toolkit configuration can be viewed and managed through a user-friendly tab in the Heroku Managed Inference and Agents add-on. As with all add-ons, navigate to the App Resources page, and click on the Managed Inference and Agents add-on that you provisioned. Navigate to the Tools tab. Here, you will find the following information:

1. The list of registered servers, and their statuses
2. The list of tools per server, along with their request schemas

These tools are all available to your selected Managed Inference model with no extra configuration. Additionally, you will find the MCP Toolkit URL and MCP Toolkit Token on this page, which can be used for integration with external MCP Clients. The MCP Toolkit Token is masked by default for security.

Caution: Your MCP Toolkit Token can be used to trigger actions in your registered MCP servers, so avoid sharing it unless necessary.

For more information, check out the dev center documentation.

Coming soon

We are actively working on simplifying the process of building SSE/HTTP servers with auth endpoints – both for Heroku Managed Inference and Agents, and for external MCP clients. This will make it possible for servers to access user specific resources, while adhering to the recommended security standards. Additionally, we are building an in-dashboard playground for Managed Inference and Agents so you can run quick experiments with your models and tools.

We are excited to see what you build with Heroku Managed Inference and Agents and MCP on Heroku! Attend our webinar on May 28 to see a demo and get your questions answered!

The post Heroku AI: Build and Deploy Enterprise Grade MCP Servers appeared first on Heroku.

Logging is the unsung hero of enterprise operations—quietly saving the day, one log line at a time. Imagine trying to maintain successful applications without knowing what’s happening inside them. This would be like flying a plane blindfolded at night, in a storm, with no instruments. Spoiler alert: Neither scenario would end well!

Today’s distributed systems are massively complex. To develop and maintain them properly, your ability to capture, analyze, and act on log data becomes essential. You need good logging for the critical insights to help you:

• Diagnose and troubleshoot issues
• Rightsize cloud resources
• Ensure security

In this post, we’ll explore the importance of logging in enterprise operations and how Heroku’s advanced logging features meet the needs of modern enterprises. We’ll look specifically into features such as Private Space Logging and data residency. Then, we’ll wrap up by looking at how Heroku offers the core attributes of any robust logging solution—scalability, reliability, security, and control.

Private Space Logging: visibility for enhanced monitoring

Private Space Logging offers centralized visibility into all applications deployed within a specific Private Space. This feature provides a consolidated view of the logs for all resources and services required to run an application at scale—including databases, gateways, backend services, CDNs, and more.

In traditional logging systems, logs are dispersed across different applications and environments. Private Space Logging centralizes all the logs in an application ecosystem, making it easier for operations teams to monitor and troubleshoot issues across multiple points in the whole system. When an enterprise manages multiple applications, each composed of diverse services and stacks, quick issue identification and resolution are vital. Private Space Logging helps enterprises in this, contributing to their efficiency and reducing MTTR (Mean Time To Recovery).

Setting up Private Space Logging in Heroku is straightforward. You can quickly get up and running with Private Space Logging simply by creating a Private Space and providing a log drain URL. For example:

heroku spaces:create acme-space \
  --shield \
  --team my-team \
  --log-drain-url https://somename:[email protected]/logpath

The log drain is the specific location where all the logs of a Private Space will be directed.

Private Space Logging works seamlessly with popular logging and monitoring tools, including Mezmo, SolarWinds, and New Relic. This way, organizations can get the benefits of Heroku’s centralized logging while leveraging their existing toolsets for advanced analytics, alerting, and visualization.

With Private Space Logging, enterprises enjoy simplified monitoring and troubleshooting processes. It’s an essential component for any organization looking to maintain a high level of operational efficiency and security.

Ensuring regulatory compliance with data residency

Data residency refers to the physical or geographical location where an enterprise’s data is stored and processed. For many industries—especially those in finance, healthcare, and government—complying with regional data regulations is a best practice and a legal requirement. Many countries have strict laws regarding how data is stored and processed within their borders. Failure to comply can result in severe penalties, including fines, legal action, and even the prohibition of business operations.

Heroku’s logging and data management capabilities can help enterprises ensure they meet data residency and compliance requirements. For example, when deploying applications within a Private Space, you can choose the region where the space should be located, ensuring that all data—including logs—remains within a specified geographic area. This ability lets you maintain control over where your data is stored and processed. By centralizing logs within a defined region, Heroku helps you maintain a clear and auditable trail of data access and usage. This is a key requirement for many compliance frameworks.

Centralized logging also supports organizations in meeting the transparency and reporting obligations often required by data protection regulations. The visibility and control from Heroku’s logging features simplify your process of identifying or removing logs if required by law. Also, Heroku’s Audit Trails for Enterprise Accounts can provide reports on specific events as they happened in the previous month, another useful capability for regulatory compliance.

Best practices for data residency and compliance include:

1. Choosing the appropriate region for data storage: When setting up a Heroku Private Space, carefully select the region that aligns with your enterprise’s data residency requirements. This ensures that all application data and logs stay within the correct regulatory jurisdiction.
2. Regular auditing of logs: Use Heroku’s logging integrations with third-party tools to review logs for compliance. Automated auditing and monitoring can help detect any anomalies or breaches in compliance.
3. Removing or anonymizing sensitive information: Many regulations prohibit personal identifiable information (PII) from being generally accessible. Just as with credentials or other confidential information, PII should be excluded from logs.
4. Ensuring your organization’s privacy statement includes logs: Do not overlook logs in your organization’s privacy posture.
5. Ensure third-party log applications align with your privacy stance: Heroku provides easy integration with many different log processors, thoroughly vetting these partners for data residency and regulation compliance before integration.

Efficient and secure logging at scale

As applications generate more data, particularly in high-traffic situations, the ability to maintain performance while processing and storing large volumes of logs becomes essential. Heroku’s logging infrastructure leverages autoscaling systems to ensure that it can ingest, process, and store logs efficiently—no matter your scale. What does this mean for your enterprise? Even as the amount of your applications’ log data increases, the performance of the logging system remains robust, with minimal latency or degradation in service.

Maintaining security and control over log data is a fundamental aspect of Heroku’s logging features. Enterprise log data is sensitive data. Ensuring that this data is protected from unauthorized access is crucial. Heroku employs multiple layers of security to safeguard log data, including encryption, access controls, and audit trails.

Heroku’s logging system offers robust access controls, allowing your enterprise to define who can view, manage, and analyze log data. Access can be restricted based on roles, ensuring that only authorized personnel have access to sensitive logs. This is crucial for compliance with regulations that require strict control over data access, such as GDPR or HIPAA.

In addition to access controls, Heroku provides encryption for log data both at rest and in transit. Logs are encrypted using industry-standard protocols. Heroku also provides Customer Managed Keys (CMK) so that organizations have complete control over the encryption protecting their logs.

In a production environment, establishing clear log retention policies and configuring logging appropriately is crucial for both performance and compliance. Here are some recommendations:

Log retention:

• Define Clear Retention Policies: Determine how long logs should be retained based on regulatory requirements, auditing needs, and operational requirements. Different types of logs might have different retention periods. For example, security logs might need to be kept longer than application debug logs.
• Automated Log Archiving and Deletion: Implement automated processes to archive older logs to cost-effective storage and delete logs that have exceeded their retention period. This ensures compliance with data retention policies and prevents storage overload.
• Consider Log Volume and Storage Costs: Be mindful of the volume of logs generated. High-volume logging can lead to significant storage costs. Regularly review and optimize logging levels to balance the need for detailed information with storage efficiency.

Configuration recommendations:

• Log Level Management: In production, set log levels to INFO or WARNING to reduce verbosity and minimize log volume. Avoid DEBUG level logging unless actively troubleshooting a specific issue.
• Structured Logging: Use structured logging formats (e.g., JSON) for easier parsing and analysis. This makes it simpler to query and filter logs.
• Log Rotation: Configure log rotation to prevent individual log files from growing too large. This ensures that logs are manageable and prevents disk space issues.
• Monitoring and Alerting: Set up monitoring and alerting on log data to detect anomalies, errors, and security incidents in real-time. Integrate logging with monitoring tools to trigger alerts based on specific log patterns.
• Regular Log Review: Periodically review logs to identify potential issues, performance bottlenecks, and security threats. This proactive approach can help prevent major incidents and improve overall system stability.

By implementing these log retention policies and configuration recommendations, enterprises can ensure efficient log management, compliance with regulations, and optimal performance in their production environments.

Key benefits of Heroku’s advanced logging features

In your enterprise operations, robust logging cannot be a backburner consideration. It’s vital to your ability to maintain your applications and adhere to data protection laws. Heroku’s advanced logging features make it possible for you to manage these important concerns:

• Centralize your logs for comprehensive visibility
• Integrate seamlessly with third-party solutions for advanced analytics.
• Control where your log data is stored and processed, to maintain compliance and meet data residency requirements.
• Scale your applications confidently, knowing that your enterprise’s applications and logging operations will remain reliable and secure.

To learn more about logging solutions for your organization, check out Heroku Enterprise or contact us today.

The post Optimizing Enterprise Operations with Heroku’s Advanced Logging Features appeared first on Heroku.

Generative AI has been one incredible tool to improve my productivity not only for work but for personal projects too. I use it every day, from generating stories and images for my online role playing games to solving code and engineering problems and building awesome demos. Lately I’ve leaned into Cursor as my go‑to AI coding companion. Its inline suggestions and quick edits keep me moving without context‑switching. Connecting Cursor to my apps through the Heroku MCP Server lets me perform actions like deploying or scaling, without leaving my code editor, making AI a first class citizen in the Heroku AI PaaS developer toolset. Using it along with the Heroku Extension for VS Code is a total win. In this article, I’ll show you how tying Cursor and MCP together saved me time and helped me focus on the parts of development I actually enjoy.

What is Model Context Protocol?

Model Context Protocol (MCP) is an open standard from Anthropic that defines a uniform way for my AI assistant (like Cursor) to talk to external tools and data sources. Instead of juggling custom APIs or integrations, MCP wraps up both the “context” my code assistant needs (code snippets, environment state, database schema) and the “instructions” it should follow (fetch logs, run queries, deploy apps) into a single, predictable format—much like a USB‑C port lets any device plug into any charger without extra adapters, Model Context Protocol is the universal connector for your AI tools and services.

Under the hood, MCP follows a simple client–server model:

• Host: my editor or chat interface (e.g., Cursor) that decides what my assistant can access
• Client: the small bridge component that keeps a live connection open
• Server: a lightweight service exposing specific capabilities (APIs, database calls, shell commands) in MCP’s schema

When I ask Cursor to “scale my Heroku dynos” or “pull the latest customer records,” it sends an MCP request to the right server, gets back a structured response, and I can keep coding without switching contexts or writing new integration code.

AI Dev Tools I Use Everyday

When I’m not on stage presenting or behind a mic recording a podcast, I’m usually in VS Code building JavaScript demos that highlight Heroku’s capabilities and best practices. Backend work is my comfort zone, front-end and design aren’t, so I lean on AI to bridge those gaps. Given a design spec (from Figma for example), I can get a frontend prototype in minutes, instead of writing HTML/CSS at hand, making the interaction with the design team straightforward. I’ve tried Gemini for ideation, and ChatGPT and Claude for debugging and refactoring code.

Lately, though, Cursor has become my go-to IDE. Its inline LLM suggestions and agentic features let me write, test, design, and even deploy code without leaving the editor. Pairing Cursor with different MCPs means that I can remain on the IDE, it keeps me focused, cuts out needless context-switching, and helps me ship demos faster.

Here, I share a list of the MCPs I use and how they improve my productivity:

Heroku MCP Server

All my demos go straight to Heroku. With the Heroku extension for VS Code, I rarely leave my editor to manage apps. And thanks to the Heroku MCP Server, my AI assistant now deploys, scales dynos, fetches logs, and updates config, all without opening the dashboard or terminal.

To install it in your IDE, start by generating a Heroku Authorization token:

heroku authorizations:create --description "Heroku MCP IDE"

Alternatively, you can generate a token in the Heroku Dashboard:

1. Go to Account Settings → Applications → Authorizations and click Create new authorization.
2. Copy the token you receive.

Then open your Cursor mcp.json and add the following JSON configuration with the previously generated Heroku Authorization token:

Note: Make sure you have npx installed a global command in your operative system, npx is part of Node.js.

{
  "mcpServers": {
    "heroku": {
      "command": "npx",
      "args": [
        "-y",
        "@heroku/mcp-server"
      ],
      "env": {
        "HEROKU_API_KEY": ""
      }
    },
  }
}

Check the project README for setup instructions on Claude Desktop, Zed, Cline, Windsurf, and VS Code.

LangChain MCPDoc

Many projects have started to adopt the /llms.txt file, which serves as a website index for LLMs, providing background information, guidance, and links to detailed markdown files. Cursor and other AI IDEs can use the llms.txt file to retrieve context for their tasks. The LangChain MCPDoc offers a convenient way to load llms.txt files, whether they are located remotely or locally, making them available to your agents.

Depending on the project I’m working on, I rely on this MCP to fetch documentation, especially when I’m building other MCPs, I use the recommended https://modelcontextprotocol.io/llms.txt file, or if I’m using LangChain JS to build agentic applications with Node.js, I use https://js.langchain.com/llms.txt.

I have also created my own Heroku llms.txt file, which you can download locally and use for your Heroku-related projects.

Here is how you can setup the LangChain MCPDoc in Cursor:

Note: Make sure you have uvx installed as a global command in your operative system, uvx is part of uv, a Python package manager.

{
  "mcpServers": {
    "heroku-docs-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "mcpdoc",
        "mcpdoc",
        "--urls",
        "HerokuDevCenter:file:///Users/jduque/AI/llmstxt/heroku/llms.txt",
        "--allowed-domains",
        "*",
        "--transport",
        "stdio"
      ]
    },
    "modelcontextprotocol-docs-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "mcpdoc",
        "mcpdoc",
        "--urls",
        "ModelContextProtocol:https://modelcontextprotocol.io/llms.txt",
        "--allowed-domains",
        "*",
        "--transport",
        "stdio"
      ]
    }
  }
}

Figma MCP Server

Another one of my favorites is the Figma MCP Server. It allows Cursor to download design data from Figma. I just copy and paste the link of the frame in Figma that I want to implement into my Cursor chat, and with the right prompt, it does the magic. For example, recently I had to implement our brand guidelines on a demo I’m working on, and I just pasted the frame that contains the Heroku color palette. It created a Tailwind CSS theme with the right styles. Without this tool, I’ll have to copy all the colors from the Figma file and organize them in the JSON structure as expected by Tailwind.

Here is how you can setup the Figma MCP Server in Cursor:

{
  "mcpServers": {
    "figma-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp",
        "--figma-api-key=",
        "--stdio"
      ]
    }
  }
}

Conclusion

Adding the Heroku MCP Server to Cursor transformed my editor into a powerful development tool. I stopped jumping between terminals, dashboards, and code. Instead, I write a prompt, and Cursor handles the rest: running queries, deploying apps, scaling dynos, or pulling logs.

This shift improved my productivity and shaved minutes off every task, cutting down on errors from running commands by memory or context-switching. More importantly, it lets me stay in flow longer, so I can focus on the parts of coding I enjoy the most.

If you’re already using Cursor or another AI coding tool, give MCP a try. Also, take a look at this quick demo where I use the Heroku MCP Server and Cursor to build and deploy a simple web app.

The post How I Improved My Productivity with Cursor and the Heroku MCP Server appeared first on Heroku.

We’re excited to announce the release of Heroku-Streamlit, a template that makes deploying interactive data visualization applications on Heroku simpler than ever before. Streamlit is an open-source app framework built for machine learning and data science projects. This Streamlit App brings together Heroku’s scalable cloud platform and Streamlit’s intuitive Python-based data application framework. Whether you’re a data scientist, educator, or developer, you can now spin up a cloud-based Streamlit environment in minutes.

What is Heroku-Streamlit?

Heroku-Streamlit is a ready-to-deploy template that allows data scientists, analysts, and developers to quickly share their data insights through interactive web applications. With minimal configuration, you can transform your data scripts into engaging web applications that anyone can access.

The repository comes pre-configured with:

• One-click deployment to Heroku
• Streamlit’s powerful visualization capabilities
• Sample Uber NYC pickup data application
• Easy customization options for your own projects

Why Use Heroku-Streamlit?

For Data Scientists

• Focus on Analysis, Not Deployment: Write Python code and let Heroku handle the infrastructure
• Share Your Work Easily: Give stakeholders access to your insights through a web browser
• Interactive Presentations: Create dynamic dashboards instead of static reports

For Developers

• Rapid Prototyping: Build and deploy data applications in minutes, not days
• Simplified Workflow: Streamlined deployment process with pre-configured settings
• Customizable: Easily extend with additional Python packages

Getting Started in Minutes

Deploying your first Streamlit application on Heroku is as simple as:

1. Click the “Deploy to Heroku” button in the repository
2. Wait a few minutes for your app to deploy
3. Access your live, interactive Streamlit application

For those who prefer a more hands-on approach, the repository includes detailed instructions for manual deployment.

Customizing Your Application

While the template comes with a sample Uber pickup visualization, you can easily customize it to showcase your own data:

1. Add your Python dependencies to requirements.txt
2. Update the Procfile to point to your Streamlit script
3. Push your changes to Heroku

Supercharge Streamlit Apps with Heroku AI: MIA

Take your Streamlit applications to the next level by integrating Heroku Managed Inference and Agents today!

• Zero Infrastructure Management: Deploy complex LLM models without the need for servers, GPUs, or scaling
• Production-Ready Performance: Automatic scaling, high availability, and optimized inference
• Cost-Effective: Flexible pricing – only pay for what you use

Build sophisticated AI agents to:

• Create Conversational Interfaces: Add natural language chat to your Streamlit apps
• Enable Autonomous Workflows: Build agents that can process data, make decisions, and take action

The Future of Data Sharing

Heroku-Streamlit represents a step forward in sharing data insights on Heroku. By removing the barriers between data analysis and web deployment, we’re enabling more teams to make data-driven decisions through interactive applications.

We’re excited to see what you build with this template and look forward to your feedback and contributions!

Ready to get started? Visit the repository and deploy your first Streamlit app on Heroku today!

The post Introducing Heroku-Streamlit: Seamless Data Visualization appeared first on Heroku.

With API-driven applications being increasingly common, understanding how your APIs are performing is crucial for success. That’s where the combination of Heroku and Moesif allows developers and their organizations to step up their observability game. In this blog, we will quickly examine how you can integrate Moesif with your Heroku app to begin monetizing and analyzing your API traffic. Let’s kick things off by taking a brief look at both platforms.

What is Heroku?

Heroku is a cloud-based Platform as a Service (PaaS) that enables developers to build, run, and scale applications entirely in the cloud. It abstracts away the complexities of infrastructure management, allowing you to focus on writing code and delivering features. Heroku supports many programming languages and frameworks, making it an excellent application development and deployment tool.

What is Moesif?

Moesif is an API analytics and monetization platform that provides deep insights into how your APIs are used and delivers the capabilities to monetize them easily. It captures detailed information about API calls, including request/response payloads, latency, errors, and user behavior. With Moesif, you can:

• Monitor API Performance: Identify bottlenecks, track error rates, and optimize response times.
• Understand User Behavior: See how users interact with your APIs, which endpoints are most popular, and what features they’re utilizing.
• Debug Issues: Quickly pinpoint the root cause of errors and resolve problems impacting your users.
• Monetize Your API: Implement usage-based billing models and track revenue generated from your API.

Benefits of Heroku and Moesif

By using the Moesif Heroku add-on, you can reduce the time to set up API Observability and ensure a seamless integration with Heroku. Billing and user management is automatically handled by Heroku which further reduces your overhead.

Why Are API Analytics Important?

If your app contains APIs, then a specialized API analytics platform must be used to truly understand how your APIs are used and what value they deliver. API analytics are essential for several reasons:

• Improved Performance: Identify and fix performance issues before they affect your users.
• Enhanced User Experience: Understand how users use your API and tailor it to their needs.
• Data-Driven Decisions: Make informed API development, pricing, and business-level decisions based on usage data.
• Increased Revenue: Monetize your API effectively by understanding usage patterns and identifying growth opportunities.

API analytics allow you to examine not only the engineering side of the puzzle but also derive a large number of business insights.

Adding Moesif to Your Heroku Application (Step-by-Step)

When using Heroku and Moesif together, the process is straightforward and can be done directly through the Heroku CLI and UI. Below, we will go through how to add Moesif to your Heroku instance, including the steps in the UI or Heroku CLI, depending on your preferred approach.

Add Via CLI

First, we will look at installing the Moesif Add-On through the CLI. For this, we assume that you:

• Have a Heroku account and an app running on Heroku
• You have the Heroku CLI installed and logged into the application you want to add Moesif to.

With these prerequisites handled, you can proceed.

Install the Add-on

Moesif can be attached to a Heroku application via the CLI:

heroku addons:create moesif

Once the command is executed, you should see something similar to the following:

-----> Adding moesif to sharp-mountain-4005... done, v18 (free)

A MOESIF_APPLICATION_ID config var is added to your Heroku app’s configuration during provisioning. It contains the write-only API token that identifies your application with Moesif. You can confirm the variable exists via the heroku config:get command:

heroku config:get MOESIF_APPLICATION_ID

This will print out your Moesif Application ID to the console, confirming it is correctly set in the config file.

Add Via UI

Alternatively, you can install the Moesif Add-On through the Heroku Dashboard UI. For this, we assume that you:

• Have a Heroku account and an app running on Heroku
• Are logged into the Heroku Dashboard for the app you’d like to add Moesif to

With these prerequisites handled, you can proceed.

Install the Add-On

While logged into the dashboard for the app you want to add Moesif to, on the Overview page, click the Configure Add-ons button.

This will then bring you to the Resources screen to view your current add-ons. In this instance, we have none. From here, click the Find more add-ons button.

On the next screen, where all available add-ons are listed, click Metrics and Analytics on the left-side menu. Locate the Moesif API Observability entry and click on it.

On the Moesif API Observability and Monetization overview page, click Install Moesif API Observability in the top-right corner.

Next, you’ll be prompted to confirm the installation and submit the order. To confirm and install, click the Submit Order Form button to add Moesif to your Heroku app and activate your subscription.

Once complete, you’ll see that Moesif has been added to your Heroku instance and is ready for further configuration.

Install the server integration

With Moesif installed on our Heroku instance and subscription activated, we need to add Moesif to the application running on Heroku. To do this, go to your Heroku dashboard and open Moesif from under “Installed add-ons”

Once inside the Moesif application, the onboarding flow that appears will walk you through adding the Moesif SDK to your code.

When initializing the SDK, use the environment variable MOESIF_APPLICATION_ID for the application ID. For example, in a Node application, you’d grab the Moesif Application ID by using process.env.MOESIF_APPLICATION_ID. This would be retrieved from the app config variables.

Local setup

After you provision the add-on, you must replicate your config variables locally so your development environment can operate against the service.

Use the Heroku Local command-line tool to configure, run, and manage process types specified in your app’s Procfile. Heroku Local reads configuration variables from a .env file. To view all of your app’s config vars, type heroku config. Use the following command for each value that you want to add to your .env file:

heroku config:get MOESIF_APPLICATION_ID -s  >> .env

Credentials and other sensitive values should not be committed to source control. If you’re using Git, you can exclude the .env file by adding it to the gitignore file with:

echo .env >> .gitignore

For more information, see the Heroku Local article.

Using Moesif Dashboards

Once everything is configured, events should begin to flow into Moesif. These events can be used for analytics and monetization directly within the Moesif platform.

Key Moesif Features to Leverage:

• Live Event Log: See individual API calls in real-time.
• Time Series Metrics: Track API traffic, latency, errors, and more over time.
• Funnels and Retention: Analyze user journeys through your API.
• Alerting: Get notified of critical API issues.
• Monetization: Drive revenue from your API calls using post-paid and pre-paid billing

Check out our docs and tutorials pages for all the ways you can leverage Moesif.

Open Through The Heroku CLI

To open Moesif, you can the following command cia the Heroku CLI:

heroku addons:open moesif

Or, from the Heroku Application Dashboard, select Moesif from the Add-ons menu.

Once logged in, you’ll have full access to the Moesif platform, which includes everything needed for extensive API analytics and monetization.

Try It Out

Want to try out Moesif for yourself? You can do so by following the directions above and creating an account through Heroku or sign-up directly. Powerful API analytics and monetization capabilities are just a few clicks away.

The post How to Add the Moesif API Observability Add-On to Your Heroku Applications appeared first on Heroku.

We’re excited to announce the launch of the Heroku MCP Server, designed to bridge the gap between agent-driven development and Heroku’s AI PaaS. Having defined the platform experience for apps in the cloud, Heroku extends our developer and operator experience to AI capabilities. With the Heroku MCP Server, you can now expose Heroku’s robust platform capabilities as a set of intuitive actions accessible to AI agents through Model Context Protocol (MCP).

The Heroku MCP server enables AI-powered applications like Claude Desktop, Cursor, and Windsurf to directly interface with Heroku, unlocking new levels of automation, efficiency, and intelligence for managing your custom applications.

How Does the Heroku MCP Server Work?

Under the hood, the Heroku MCP Server makes intelligent use of the toolchain developers already trust: the Heroku CLI. It uses the CLI as the primary engine for executing actions, ensuring consistency and benefiting from its existing command orchestration logic.

To maximize performance and responsiveness, especially for sequences of operations, the server runs the Heroku CLI in REPL (Read-Eval-Print Loop) mode. This maintains a persistent CLI process, enabling significantly faster command execution and making multi-tool operations much more efficient compared to launching a new CLI process for every action.

What Can Your Agents Do Today?

The initial release of the Heroku MCP Server focuses on core developer workflows:

• App Lifecycle Management: Empower agents to handle deploying, scaling, restarting, viewing logs, and monitoring your applications.
• Database Operations: Enable actions on your Heroku Postgres databases.
• Add-on Management: Allow agents to discover available add-ons and attach or detach resources to your apps.
• Scaling and Performance: Facilitate intelligent scaling of your application resources.

Access the full list of tools here.

Here’s How to Get Started

Authentication Setup

Generate a Heroku authorization token by using the following CLI command.

heroku authorizations:create

Copy the token and use it as your HEROKU_API_KEY in the following steps.

Configuration with MCP Clients

MCP clients maintain the MCP config file in different locations:

1. Cursor – mcp.json
2. Windsurf – mcp_config.json
3. Claude – claude_desktop_config.json

Add the following to the appropriate config file:

{
  "mcpServers": {
    "heroku": {
      "command": "npx -y @heroku/mcp-server",
      "env": {
        "HEROKU_API_KEY": ""
      }
    }
  }
}

Other Clients

For integration with other MCP compatible clients, please refer to the client specific config documentation.

Turbo Charge Your IDE and Agents

Heroku’s core mission has always been to simplify the complexities of app development and deployment, and a key part of that is meeting developers right where they work: inside their IDE. We’ve championed this with tools like the Heroku VS Code extension, which brings the power of the Heroku Dashboard and the versatility of the CLI directly into your AI editor like Cursor, reducing the need to switch contexts for many common tasks.

As AI-native developer workflows emerge, the friction between coding environments and cloud platforms will disappear entirely. Developers want to stay focused, leveraging AI assistance without interrupting their flow or needing deep platform-specific expertise for routine tasks.

The Heroku MCP Server builds directly on our philosophy of seamless IDE and agent integration. While the VS Code extension provides excellent visual affordances and manual control for developers, the MCP Server addresses the rise of agent-driven development. It provides an intuitive way for your agents to manage your Heroku applications, databases, and infrastructure, making it an essential part of any AI PaaS (AI Platform as a Service) strategy.

What’s Next?

This is just the beginning! We’re actively working on exposing even more of the Heroku platform’s capabilities through the MCP server. Our goal is to continuously enhance the AI-driven developer experience on Heroku, making it richer, more powerful, and even more intuitive. Stay tuned for updates as we expand the range of actions your agents can perform.

Join the Conversation

The Heroku MCP Server is just one piece of Heroku’s plan for providing an excellent AI-driven developer experience, and to provide the primitives necessary to build, manage, and scale AI applications and agents. Stay tuned for next month’s GA of our Managed Inference and Agents product, which comes complete with support for a range of MCP tools, and upcoming enhancements to broad MCP support across the platform.

The post Introducing the Official Heroku MCP Server appeared first on Heroku.

Do you run Rails or pure Ruby applications on Heroku? If so, it’s important to be aware of upcoming end-of-life (EOL) dates for both your stack and your Ruby version. The Heroku-20 stack, built on Ubuntu 20.04 LTS, will reach EOL for standard support in April 2025. Ruby 2.7 has already passed its EOL, meaning it’s no longer receiving critical security updates. Continuing to run your app with either an outdated Ruby version or an unsupported Heroku stack exposes your application to increasing security and stability risks.

In this article, we’ll cover:

What the Heroku-20 EOL means for your application.
Risks of continuing with Ruby 2.7, especially in combination with Heroku-20.
Recommendations and strategies for securely migrating your stack and Ruby version.

But first, here are the commands you can run to determine your current Heroku stack and Ruby version:

$ heroku stack --app <APP NAME>
=== ⬢ your-app-name Available Stacks

  cnb
  container
* heroku-20
  heroku-22
  heroku-24

The above command will list the available stacks and denote the current stack your application is using. If it shows heroku-20, then it’s time to consider an upgrade.

To check your Ruby version, run:

$ heroku run ruby -v --app <APP NAME>

With this information, you’ll be ready to understand your risks clearly and take the recommended migration steps outlined below.

Understanding the Heroku-20 and Ruby 2.7 EOL

Before you plan your migration, it’s crucial to clearly understand what EOL means for both your Heroku stack and your Ruby version.

Heroku-20 Stack

Heroku-20, based on Ubuntu 20.04 LTS, will reach EOL for standard support in April 2025. After this date, Ubuntu 20.04 will stop receiving regular security updates, patches, and technical support. This means any new vulnerabilities discovered after this point will not be officially addressed, significantly increasing security risks and potential compatibility issues with newer software and libraries.

Starting May 1st, 2025, builds will no longer be allowed for Heroku-20 apps.

Ruby 2.7

Ruby 2.7 reached EOL in March 2023. This means Ruby 2.7 no longer receives security patches, bug fixes, or compatibility updates. Applications using Ruby 2.7 are vulnerable to newly discovered security risks and are likely to encounter compatibility problems with other system components, such as newer versions of OpenSSL.

Additionally, Ruby 3.0 reached EOL in April 2024, and Ruby 3.1 is EOL as well. As of this writing, the latest stable Ruby version is Ruby 3.4.2.

Understanding your options and risks

Before jumping straight into a migration, you might have some questions about the implications and potential risks associated with your current stack and Ruby version. Let’s cover the common questions.

Can I continue using Ruby 2.7 on Heroku?

While it’s technically possible to run Ruby 2.7 on Heroku‑20, doing so carries significant risks. Ruby 2.7 no longer receives bug fixes or security updates, making applications vulnerable to emerging threats.

What are the risks of staying on the Heroku‑20 stack?

If you remain on Heroku-20 past its EOL in April 2025, your application environment will become increasingly insecure. You’ll no longer receive critical patches for security vulnerabilities, potentially leading to exploitation. Additionally, dependencies and libraries may become incompatible or fail to build correctly.

Can I just move off of Heroku while keeping my current Ruby version?

Even if you migrate away from Heroku, using Ruby 2.7 on an unsupported or self-managed environment still carries significant risks. Older Ruby versions that no longer receive updates may face mounting compatibility challenges with newer system components. For example, newer Ubuntu releases run OpenSSL 3.x. This will conflict with Ruby 2.7’s expectations of OpenSSL 1.1.x.

While migrating off Heroku might seem like a quick fix, the underlying issue—EOL for Ruby 2.7—remains. Even if you self-manage your infrastructure or move to another platform, you’ll still face security vulnerabilities and compatibility issues. In the long term, maintenance challenges will increase. Modern Ubuntu versions (22.04+) use OpenSSL 3.x, incompatible with Ruby 2.7, making your application more difficult and costly to maintain.

Migration Recommendations

A structured migration plan ensures a smooth transition with minimal disruption. Here are some key pointers for how to approach upgrading your Ruby and Heroku stack.

#1: Embrace Rails LTS

If you’re using Rails with Ruby 2.7, consider migrating to a Rails LTS release. This move requires upgrading both Rails and Ruby and transitioning to a supported Heroku stack (such as Heroku‑22 or Heroku‑24) that continues to receive security updates.

#2: Upgrade incrementally

Rather than overhauling your entire system at once, upgrade Rails one major version at a time—deploy and resolve issues after each change—and handle Ruby upgrades as a separate process. This approach isolates problems and helps you gradually transition toward running at least Ruby 3.2.6.

#3: Adopt the latest versions

Ultimately, your goal should be to run your application on the latest Ruby version and Heroku‑24. Newer releases offer improved performance, enhanced security, and native support for modern libraries like OpenSSL 3, reducing the risk of future compatibility issues.

#4: Consider professional upgrade services

Professional upgrade services are specialized consultants who analyze your codebase and infrastructure to create a tailored migration plan that minimizes downtime and disruption. Their expertise is especially valuable for legacy projects running on significantly outdated versions. Options include:

• FastRuby.io
• Test Double’s Upgrade Rails Service
• Saeloun’s Ruby on Rails Upgrade Service

Keep in mind that older Rails and Ruby versions can be more challenging and costly to upgrade.

#5: Understand the ecosystem constraints

Upgrading your application stack isn’t just about Heroku—it’s about ensuring that your entire environment remains secure and maintainable. Even if you migrate off Heroku, you remain subject to the same challenges regarding security patches, build pipelines, and compatibility. It’s essential to plan so that your overall stack (Ruby, Rails, OS) stays within a supported lifecycle.

Conclusion

Given the upcoming EOL for the Heroku-20 stack and the already-passed EOL of Ruby 2.7, proactive migration is essential to maintain your application’s security, stability, and compatibility. Start your migration plan early and consider incremental upgrades to avoid disruption. Taking these steps now can prevent a last-minute scramble and ensure your application continues to benefit from the latest security and performance enhancements.

Resources

• Ubuntu lifecycle and release cadence
• Ruby 2.7.8 (Last) Release Announcement
• Heroku-20 Stack Documentation
• Heroku Guidance on “Upgrading to the Latest Stack”
• Heroku-20 End-of-Life FAQ

The post Migrating Your Ruby Apps to the Latest Stack appeared first on Heroku.

In a short amount of time, AI has transformed life, work, and how we think about the future. These rapid advancements have left many of us wondering how to integrate AI into our existing workflows and what it means for the future of app development. The apps we’re building today are more than lines of code; they’re becoming dynamic, intelligent, and increasingly autonomous. To navigate this new landscape, we need to bring our current skills and technology into this AI-driven future.

As part of the Salesforce portfolio, Heroku has always been a trusted platform for building apps in any language. Our mission remains focused on helping you deliver value faster, greater reliability, and improved efficiently—all while simplifying the complexities of an ever-changing ecosystem. Our latest innovations empower developers to build custom AI apps faster, enhance existing apps with AI capabilities, and create specialized actions and experiences for AI agents in any language.

To date over 65 million apps in Ruby, .NET, Java, Python, Go, and more have launched to serve billions of requests a day that provide healthcare, sell clothing, detect bank fraud, and order car parts. The next generation of Heroku brings AI capabilities into the platform and with developer tools like Cursor, all in service of helping organizations accelerate their agentic initiatives to improve customer experience and focus on creating unique value.

What’s New: Streamlining AI and Cloud-Native Development

Heroku AppLink

Dramatically streamlines the ability to add custom actions and logic written in any language to Agentforce agents through Salesforce Flows, Apex, and Data Cloud. Agentforce is the agentic layer of the Salesforce Platform for deploying autonomous AI agents across any business function. This capability brings the ecosystem of programming languages and custom code to augment and enhance Salesforce implementations. AppLink is available today in pilot.

Heroku Eventing

Delivers a robust solution to simplify the development of event-based app architectures with a centralized hub for managing, subscribing to, and publishing events, streamlining the development process. Eventing can be used to subscribe and publish to any system including the Salesforce platform. Eventing is available in pilot.

Heroku Fir Generation

This latest version of the Heroku Platform delivers an integrated and automated experience that is resilient, secure, and performant at global scale. Built on open, cloud-native standards like Kubernetes, Open Container Initiative (OCI), and Open Telemetry; the platform now leverages AWS services including Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Container Registry (ECR), AWS Global Accelerator, and AWS Graviton. Generally available later this month.

VS Code Extension

Delivers an all-in-one experience with the essential developer tools to create and manage apps within the IDE. Developers are able to be more productive in building apps and can eliminate the context switching between multiple tools. VS Code Extension is available here.

.NET Support

Enhances and expands the developer experience to include C#, Visual Basic, and F# apps using the .NET and ASP.NET Core frameworks. .NET is available here.

Heroku-Jupyter

Delivers an open-source, production-ready solution to easily spin up cloud-based Jupyter environments in minutes without the challenges of storage or complex configurations. Available open source here.

Heroku Managed Inference and Agents

Delivers a streamlined developer and operator experience in building and managing custom AI apps in any language alongside your data and AI models in one trusted environment. Heroku provides safe execution of AI generated code during agentic workflows, plus secure access to tools and resources like databases and add-ons. Heroku Managed Inference and Agents is available here.

Get Ready to Dig in

We started Heroku before Docker, Kubernetes, and in the early days of cloud to help developers deploy cloud-native apps faster and easier. Fast forward to today and AI has flipped the ecosystem on its head and the landscape is almost unrecognizable. We’re excited to introduce the next generation of the platform to accelerate the needs of cloud-native and AI app delivery at scale with the delightful developer and operator experiences you’ve come to expect from Heroku.

Learn more about Heroku – Register today to join us online Wednesday, April 30 at 1:00pm ET, to learn more about the next generation of Heroku, the platform for AI apps in any language.

The post Heroku: Powering the Next Wave of Apps with AI appeared first on Heroku.

For years, Heroku has been empowering developers to deploy and scale their applications with ease. Now, we’re thrilled to introduce the general availability of the next generation of the Heroku platform, codenamed Fir, launching later this month April 2025. Built on open source standards and cloud-native technologies, Fir accelerates your development like never before.

A change of this scale is not something that we take lightly. Replatforming decisions can represent a massive shift in user experience and operational processes for a single company; we need to consider the needs of the millions of apps for the thousands of companies running on Heroku. With Fir, we are delivering the foundation for the Next Generation of Heroku which brings the power and breadth of the cloud native ecosystem, without the complexity, and a simple, elegant user experience. Helping our customers do more with minimal disruption.

“The deployment environment was very simple and comfortable. And it was similar to the cedar generation environment.”

Team Manager, ICAN Management, Inc

If you’re looking for enhanced flexibility, scalability, and robust observability, check out what’s new with this next generation and where Heroku is headed. To explore what Fir means for you and get a firsthand look at the new platform, register for the Fir GA Webinar on April 30th 10:00AM PST / 1:00PM EST, where we’ll walk through the new capabilities and what’s coming next.

See our Demo video to see all the capabilities discussed below in action!

Build Smarter, Not Harder with Cloud Native Buildpacks

A core part of the Heroku experience has long been its ability to take idiomatic code written in nearly any major language and seamlessly turn it into a running application. The Fir generation delivers on that experience using Cloud Native Buildpacks (CNBs) as its standard build system. CNBs analyze your code and automatically build it into secure, efficient, and portable Open Container Initiative (OCI) container images, ready for deployment.

Focus on your code, not container configuration: Instead of grappling with the complexities of writing and maintaining production-ready Dockerfiles, CNBs automate the process of turning your source code into secure, optimized container images. Heroku provides and maintains open source CNBs infused with expertise for your favorite languages, handling dependencies, compilation, and optimization automatically. Leveraging CNBs means deploying to Heroku Fir remains as simple as git push heroku main, freeing you to concentrate on building great features.

Build Once, Run Anywhere: Portability is inherent with CNBs, as they create standard OCI container images. This means you can build your application once on Heroku Fir and confidently run the identical artifact anywhere OCI images are supported: on Heroku Fir, on other OCI-compliant cloud platforms, or locally with Docker. This adherence to open standards gives you deployment flexibility and minimizes vendor lock-in.

Extensible Build Primitive: While Heroku’s CNBs cover many scenarios out-of-the-box, the buildpack standard provides a powerful, safe, and composable way to extend the build process. Need support for a niche language or custom build logic? You can create your own CNB or utilize community/third-party buildpacks. These integrate with Heroku’s official buildpacks and the standard buildpack lifecycle, offering controlled customization without the pitfalls of managing complex, monolithic Dockerfiles. This standardized extensibility fosters innovation, allowing customers to tailor the platform to their unique needs.

With Cloud Native Buildpacks, Heroku Fir brings containerization within reach for every developer by combining simplicity, security, and portability, all while ensuring compatibility with the OCI ecosystem and tooling.

Deeper Insights with Integrated OpenTelemetry

Observability is paramount for maintaining the health and performance of modern applications. That’s why we’re providing OpenTelemetry (OTel) data natively on all Fir-Generation Heroku apps. This widely-adopted framework provides a standardized way to collect and export telemetry data from your applications.

Fir streamlines the process of collecting and exporting telemetry data without extensive configuration. For an immediate, out-of-the-box view, this data automatically populates the familiar Heroku Metrics tab, providing essential insights with zero setup.

When you need to go deeper, Fir’s native support for OpenTelemetry allows you to fully utilize its core signals (traces, metrics, and logs) with upstream SDKs in your language.

Comprehensive Telemetry Signals

Comprehensive telemetry signals are fundamental to understanding, optimizing, and maintaining the health of your applications. By leveraging a combination of traces, metrics, and logs, you gain a holistic view of system behavior, enabling faster issue resolution and more informed decision-making.

Traces provide visibility into the execution path of individual requests, allowing you to pinpoint where latency occurs and identify performance bottlenecks across distributed systems. This insight is invaluable for troubleshooting complex issues, across different application architectures. From monoliths to microservices, understanding the full request path via traces is crucial for isolating problems that degrade the user experience.

Metrics offer quantitative measurements of your system’s performance and resource utilization, such as CPU load, memory usage, and request rates. These continuous data streams help you monitor overall system health, detect anomalies, and plan for scalability by forecasting capacity needs.

Logs, on the other hand, capture discrete events that reflect the inner workings of your application. They offer detailed context for debugging errors, auditing user actions, and tracking security events. OpenTelemetry embraces your existing logging solutions by automatically correlating logs with traces using injected context (like trace IDs) for easier troubleshooting across systems, and providing capabilities to standardize and enrich logs from different sources into a more unified format.

When combined, these telemetry signals provide a powerful toolkit for maintaining application reliability, enhancing security, and optimizing performance — ensuring that your systems can scale to meet evolving business demands.

Telemetry Export with Heroku Telemetry Drains

Extending Heroku’s hallmark simplicity to modern observability, Fir embraces native OpenTelemetry. Fir’s native OpenTelemetry integration makes comprehensive observability straightforward. Crucially, Heroku automatically collects platform and application telemetry (traces, metrics, logs) and seamlessly combines it with any custom instrumentation you add using standard OTel SDKs in your code. This unified stream provides a complete picture of your application’s health and performance, all in one place.

Heroku has always prioritized simplicity and ease of use for developers, and the new Heroku Telemetry tools build upon this foundation. Previously, Heroku’s log drains allowed developers to effortlessly set up and manage log streams, ensuring that critical application data was easily accessible. Now, you can see from the command below that it’s just as easy to configure app or space level telemetry drains and enable seamless transmission of all this data to your preferred observability backend and tools.

heroku telemetry:add https://telemetry.example.com --app myapp --signals traces,metrics --transport http --headers '{"x-sample-header":"sample-value"}'

Greater Flexibility with Expanded Dyno Options

One of the most significant advancements in the Fir generation is the dramatically expanded range of dyno options. Moving beyond the offerings available in previous generations, Fir provides 18 dyno options across various specifications to match resources exactly to your application’s needs.

This isn’t just about having more choices; it’s about having the right choices for your applications. You can see the full list of new dyno options in the table below or review the Technical Specifications by Dyno Size.

Precise Resource Allocation: Fir enables precise resource allocation, eliminating over-provisioning or the need to fit applications into mismatched dynos. These new granular options facilitate the fine-tuning of CPU and memory resources for applications, resulting in more efficient and cost-effective deployments.

Greater Optionality: We’ve listened to your feedback and introduced more intermediate sizes, as well as smaller options like dyno-1c-0.5gb (0.5GB RAM, 1 vCPU) and dyno-2c-1gb (1GB RAM, 2 vCPU). These brand new offerings bring greater optionality to balance your compute, memory, and cost needs.

Optimized for Diverse Workloads: Whether you’re running memory-intensive applications, compute-heavy tasks, or general-purpose web services, Fir’s diverse dyno families provide optimized configurations to meet your specific performance requirements. By offering this increased granularity, Fir empowers you to optimize your application’s performance and costs with unparalleled precision.

Enhanced Platform Data Residency

With this next generation of Heroku, our new architecture allows us to keep all data and services in the same region where our customers are running and storing their data.

All Telemetry data generated by your apps and Heroku’s infrastructure stays within your Fir Space’s region, bolstering Heroku’s data residency capabilities for our customers.

With OpenTelemetry deeply integrated into Fir, you gain valuable insights into your application’s performance with built-in support, allowing for more effective monitoring, debugging, and optimization and it all stays local to where your application is running.

Also, now that Cloud Native Buildpacks are the standard build system for our newest platform, that means that all builds are also created within the same space as where the apps and dynos will be run, and therefore will stay in the same region.

With Fir, you have granular control over how your data is stored and where it runs. In addition, you likely boost application performance by using geographical proximity to optimize data access.

Conclusion

The next generation of Heroku is here, designed with you, the developer, in mind. By offering significantly expanded dyno options, embracing the power of Cloud Native Buildpacks, and integrating robust observability with OpenTelemetry, Heroku Fir empowers you to build, deploy, scale, and monitor your applications with greater flexibility, efficiency, and confidence.

While we’re excited the next generation of Heroku is now generally available, we’re just getting started. Fir is the foundation for delivering the most highly requested Heroku features, and it will enable us to ship faster than ever before. We’re delighted to share the direction we’re heading in, starting with these roadmap items:

• Heroku AppLink for Salesforce
• Enhanced networking features including exposing apps through AWS VPC PrivateLink and AWS Transit Gateway
• Expanded isolation & sandboxing use cases, such as Fir for Multi-Tenancy
• Software supply chain security, including Software Bill of Materials (SBOMs) generation and cryptographically signed build provenance

Want to dive deeper into Fir? Join our team of experts for the Fir GA webinar on April 30th at 10:00AM PST / 1:00PM EST, where we’ll walk through the new platform and give you a sneak peek at what’s ahead.

We’re excited for you to experience the platform and see what you build with it.

The post Heroku Fir: Dive into the New Platform Capabilities appeared first on Heroku.

It’s never been a more exciting time to be a .NET developer. With .NET (formerly known as .NET Core) approaching its 10-year anniversary this November, the platform has evolved into a powerful, cross-platform ecosystem, embracing modern development practices and powering a vast array of applications.

Today, we’re thrilled to announce that .NET support on Heroku, previously in beta, is now Generally Available (GA), marking a significant milestone for .NET developers on our platform. We want to thank our beta users for their invaluable feedback, which has helped us to refine and enhance the .NET experience on Heroku.

Key Benefits of .NET GA

With General Availability, .NET applications on Heroku are fully supported in production environments. This represents our long-term commitment to the .NET ecosystem, meaning you can rely on Heroku’s robust infrastructure and support services for your critical .NET workloads.

.NET joins as our 7th runtime ecosystem on the Heroku platform. Like all of our other ecosystems, what this means for .NET developers:

• You’ll have access to the latest stable version of the .NET runtime the day it’s released.
• Comprehensive documentation is available on the Heroku Dev Center, tailored specifically for .NET developers.
• Our support team is here to help with your .NET deployments, and you’re covered by Heroku’s support policy.
• You’ll have a developer experience that feels native and follows idioms familiar to .NET developers.

General Availability signifies that .NET on Heroku is production-ready, fully supported, and seamlessly integrated into the Heroku ecosystem, providing .NET developers with a first-class experience.

Built for .NET

Heroku now supports .NET, including languages like C#, F#, and Visual Basic. Heroku automatically understands, builds, and deploys your .NET applications, applying smart defaults to simplify your workflow. However, if you need more control, you can easily override these defaults to tailor the environment to your specific requirements, ensuring you can focus on coding and innovation.

.NET on Heroku includes:

• The most recent .NET SDK and runtimes are installed automatically based on your project’s TargetFramework. You can override that using a global.json file if needed.
• ASP.NET Core apps are configured to listen on the right port by default. All executable project types, including Console and Worker Services, are detected during build. The build log shows helpful output that can easily be adapted to your own process types with Procfile for more control.
• Heroku supports framework-dependent apps by default, allowing a solution with many projects to be efficiently supported. Other deployment models, such as self-contained, ReadyToRun, and highly optimized Native AOT, are also supported out of the box.

Whether you’re working with a single project or a solution that includes multiple apps, Heroku adapts to your setup in a way that feels intuitive and natural for .NET developers.

Stay in the Flow

Beyond the core support, .NET apps plug right into the developer workflow you expect.

• Use Heroku Pipelines to manage staging and production environments.
• Run tests automatically with Heroku CI, supporting any major .NET testing framework.
• Preview pull requests with Review Apps – complete, disposable Heroku apps that spin up automatically for each GitHub PR.
• Automate tasks like database migrations with Release Phase, scale dynos instantly as demand grows, and roll back to any previously released version if something goes wrong.

With Heroku, you get a smooth, automated, and collaborative .NET development experience, allowing you to release with confidence from coding to production.

Getting Started with .NET on Heroku

Wherever you are in your .NET journey, Heroku offers a smooth path to deployment:

• New to Heroku? Head over to our .NET sign up page for more information.
• Ready to Deploy? Start with our Getting Started with .NET tutorial for a step-by-step guide.
• Already using the heroku/dotnet buildpack from the beta? You’re already on the GA version – no changes needed.
• Need More Info? Check out the .NET Support Reference on Dev Center.
• Using a Community Buildpack? Continue to use it, or migrate to the official buildpack – migration guides are coming soon.
• Migrating from Another Platform? Reach out to Heroku Support – we’re ready to help.

The Heroku platform now offers .NET developers the performance, reliability, scalability, and ease of use they expect. Share your feedback with us on GitHub and help shape the future of .NET on Heroku!

We’re thrilled to support the .NET community and can’t wait to see what you build next.

The post .NET on Heroku: Now Generally Available appeared first on Heroku.

We’re excited to introduce Heroku-Jupyter, an open-source, production-ready solution for running Jupyter Notebooks on Heroku with persistent storage, seamless deployment, and built-in security. Whether you’re a data scientist, educator, or developer, you can now spin up a cloud-based Jupyter environment in minutes.

Why Jupyter on Heroku?

Jupyter Notebooks provide an interactive computing environment ideal for data analysis, visualization, and machine learning. However, cloud-based Jupyter deployments often face challenges like ephemeral storage and complex server configurations. Heroku-Jupyter solves these issues by providing a streamlined cloud-based experience.

Persistent Storage for reliable, up-to-date models

• Reliable Data Management: Your notebooks are safely stored in PostgreSQL, ensuring they remain accessible and secure across sessions.
• Data Integrity: With persistent storage, you can trust that your data and models are always up-to-date and backed up, reducing the risk of data loss.

Security First Dev Environment

• Built-in Password Protection: Protect your work with robust password authentication, ensuring that only authorized users can access your notebooks.
• Compliance and Privacy: Heroku’s security features help you meet compliance requirements and maintain data privacy, making it suitable for enterprise-level applications.

Scalability and Flexibility

• One-Click Deployment: No manual setup or infrastructure management—just deploy and start coding.
• Auto-Scaling: Heroku automatically scales your Jupyter environment to handle increased loads, ensuring your applications perform optimally under varying conditions.
• Customizable Environment: While Heroku-Jupyter comes with smart defaults, you can easily override settings to tailor the environment to your specific needs, whether you’re working on a small project or a large-scale application.

Advance AI Capabilities

By leveraging Heroku’s developer-friendly platform, Jupyter users can focus on innovation without worrying about infrastructure.

You can now supercharge your Retrieval-Augmented Generation (RAG) applications on Heroku by combining Heroku-Jupyter, pgvector, and Heroku Managed Inference and Agents.

You can use an embedding model in Heroku Managed Inference and Agents (cohere-embed-multilingual) to convert text into vector representations stored in pgvector for fast retrieval. Then, leverage an inference model in Heroku Managed Inference and Agents (claude-3-5-sonnet) to generate intelligent responses using the retrieved context.

With Heroku-Jupyter, you can easily experiment, fine-tune, and optimize your pipeline—all within Heroku’s ecosystem

A Production-Ready Jupyter Notebook Environment

A delightful developer experience is at the heart of what we do at Heroku. Heroku-Jupyter enhances your workflow through One-Click Deployment buttons. This makes it easy to get started in minutes. No need for complex configuration—just deploy and start working instantly. Once logged into your Heroku account, after clicking the Deploy to Heroku button your Jupiter Notebook will be live in minutes.

Conclusion

We’re committed to bringing Heroku, the beloved developer platform into the AI era by integrating with tools like pgvector and Heroku Managed Inference and Agents. Whether you’re a data scientist, educator, or developer, Heroku-Jupyter is designed to meet your needs and help you achieve your goals with a production-ready Jupyter Notebook environment.

We’d love your feedback! Join the open-source community on GitHub, contribute to the project, and help shape the future of Heroku-Jupyter.

The post Jupyter Notebooks on Heroku with Persistent Storage appeared first on Heroku.

Many advanced users want to use GitHub Actions with their applications on Heroku. Now there’s a straightforward way to use these great systems together, and to meet strong security and compliance requirements at the same time.

A Solution for GitHub IP Range Restrictions

Heroku is a powerful platform that offers robust CI/CD capabilities and secure, scalable environments for deploying applications. However, GitHub Orgs cannot be configured with Heroku IP ranges, which can be a requirement for some organizations’ security rules. While this is under consideration, we want to share an alternative that leverages GitHub Actions, Heroku’s ability to run arbitrary workloads and its powerful Platform API. If you’re looking to integrate private repositories with Heroku CI/CD, need strict control over source code sharing in regulated environments, or want to explore why running a GitHub Action Runner on Heroku might be more efficient, this blog post is for you!

In this post, we will share and describe a set of repositories and configuration instructions that enable you to leverage GitHub Actions—its features, dashboard reporting, and the ability to host the GitHub Runner on Heroku—for optimal execution and secure access to your private application code, all while still within the Heroku Pipeline dashboard experience.

Keep in mind, while aspects of this solution are part of the core Heroku offering, the pattern explained in this article is provided as a sample only and the final configuration will be your responsibility. Additionally, while we have tried hard to ensure all aspects of the Heroku Flow feature work in this mode – there are some considerations to keep in mind we will share later in this blog and in the accompanying code.

What are GitHub Actions?

In short, GitHub Actions are small code snippets—typically shell scripts or Node.js—that run in response to events like commits or PR creation. You define which events trigger your actions, which can perform various tasks, primarily integrating with CI/CD systems or automating testing, scanning, and code health checks. For secure access to your deployment platform and source code, GitHub requires you to host a Docker image of their Runner component. They also require that you routinely update your runner instances within 30 days of a new release. You can read more about GitHub Actions.

Using GitHub Actions with Heroku

Heroku supports these requirements in two key ways: hosting the runner and providing access to the build and deployment platform. First, Heroku can host official Docker images just as easily as application code, eliminating the need to manage infrastructure provisioning or scaling. Second, the Heroku Platform API enables GitHub Actions to automate managing Review Apps through an existing pipeline, move code through the pipeline, and trigger deployments—all while storing source code briefly on ephemeral storage. Additionally, this setup includes automation for the mandatory 30-day upgrade window for the GitHub Runner component, reusing the above mentioned features to schedule a weekly workflow that rebuilds its Docker image and autodeploy as a Heroku app, which removes the burden of having to update it manually. The following diagram outlines the location of application source repositories, the two GitHub actions required and within Heroku the configuration to run the GitHub runner and of course application deployments created by the actions – all within a Heroku Private space.

There are two repositories we are sharing that help you accomplish the above:

• Heroku-hosted runner for GitHub Actions – This project defines a Dockerfile to run a custom Heroku-hosted runner for Github Actions (see also self-hosted runners). The runner is hosted on Heroku as a docker image via heroku.yml. Once the self-hosted runner is running on Heroku you can start adding workflows to your private GitHub repositories to automate Heroku Review Apps creation and Heroku Apps deploy using the following action (that includes workflow examples).
• Heroku Flow Action – GitHub Action to upload the source code to Heroku from a private GitHub repository using the Heroku Source Endpoint API. The uploaded code is then built to either deploy an app (on push, workflow_dispatch, and schedule events) or create/update a review app (on pull_request events such as opened, reopened, and synchronize). Whenever a PR branch is updated, the latest commit is deployed to the review app if existing, otherwise a new review app is created. The Review App is automatically removed when the pull request is closed (on pull_request events when the action is ‘closed‘). The action handles only the above mentioned events to prevent unexpected behavior, handling event-specific requirements and improving action reliability.

The README files in the above repos go into more details – but at a high level what is involved is the following steps to setup GitHub Runner in Heroku and configure the GitHub Actions:

1. Identify a Private Space to run your the GitHub Runner in and resulting pipeline apps.
2. Identify outbound IPs from the Private Space to be shared in your GitHub configuration.
3. Deploy the GitHub Runner to the Private Space with your GitHub access token and Organization Name.
4. Configure one or more private repos with the Heroku Flow Action and test by creating some PRs.

What you should see from step 4 is the following:

1. A new GitHub Action is started.
2. A Review App within the configured Pipeline is automatically created upon the creation of a PR.
3. From the Pipeline you can follow the application build as soon as it progresses.

Advantages to using GitHub Actions with Heroku Flow

Using this approach you are able to fully leverage your Heroku investment and reuse the features that the platform already offers, such as build and deploy capabilities and compute power, without needing to use external tools or platforms. In this way, your CI/CD is fully integrated where your apps are, a close integration that allows you to unlock scenarios where you can connect your Heroku-hosted runners to resources within or attached to your Private Space (e.g. secret managers, package registries, Heroku apps …) via Private Space peering or VPN connections.

Using a Private Space is not mandatory, but it adds a layer of security and provides a static set of public IP addresses that can be configured in your GitHub Org. Moreover, Private Spaces are now available for online customers too, so both verified Heroku Teams and Heroku Enterprises can leverage such an option.

Your Heroku Flow can be improved and customized with ad-hoc steps and provide additional features such as manual and scheduled app builds and deploys via GitHub Actions “Run Workflow” and cron/scheduler.

Last, but not least, your Heroku-hosted runners’ consumption is pro-rated to the second.

This solution complements your current Heroku development environments and can be used even for non-Heroku projects, a complete and enhanced delivery workflow is at your fingertips that in the future can open to other integration scenarios (e.g. on-premise GitHub Server, GitLab, Bitbucket …), while remaining on the platform you love!

Considerations for Using GitHub Actions with Heroku Flow

Please keep the following considerations in mind as you explore this pattern and read the README files within the above repositories in detail to fully understand their value and implications. In summary, some key aspects to be aware of are as follows:

• From the Review App UI in the Heroku Pipeline, the URL used to allow easy access to the instance of the actual GitHub repository is not available in this configuration. You will instead need to relay the correct GitHub repository URL to your stakeholders in a different way.
• Heroku CI has a feature that automatically runs tests before creating Review Applications, among other features described here. In this configuration, the standard Heroku-managed Git repository is explicitly not used, and as such, tests are not run in the conventional way. If you need this capability, you could consider extending the action code to run your tests before every subsequent push to your GitHub repository.
• Currently, this configuration is not compatible with Fir, our next-generation platform version.
• While we are using the core GitHub Runner software, we are not using the standard GitHub docker images: Rather, we create a custom image for you. It is up to you to test whether other GitHub actions you have created work as expected.

Please continue to review more detailed consideration information in the README’s here and here.

Conclusion: Heroku + Github Actions Streamlines your CI/CD

GitHub Actions is a powerful tool for automating deployment pipeline tasks. Given the ability to reduce the toil of managing your own GitHub Runner instance along with the ease with which you can monitor the pipeline and let stakeholders test builds through Heroku Review Apps, we’re excited to share this pattern with our customers. As mentioned earlier, out-of-the-box support for this capability is under consideration by our product team. We invite you to share your thoughts on this roadmap item directly via commenting on the github issue. Meanwhile please feel free to fork and/or make suggestions on the above GitHub repos. We welcome your feedback, whether or not you’ve explored this approach. Finally, at Heroku, we consider feedback a gift. If you have broader ideas or suggestions, please connect with us via the Heroku GitHub roadmap.

The post Using GitHub Actions with Heroku Flow for additional Security Control appeared first on Heroku.

Heroku’s commitment to developer productivity shines through in its powerful buildpack system. They handle the heavy lifting of building your app, letting you focus on what matters most: writing code. A prime example is the Heroku Java buildpack, a versatile tool that simplifies deploying Java applications, especially those built with popular frameworks like Spring Boot, Quarkus, and Micronaut.

One of the core strengths of Heroku buildpacks is their automatic nature. They intelligently detect your application’s language and framework, fetching the necessary build tools and configuring the Heroku platform to run your app seamlessly. This means no more wrestling with server configurations or deployment scripts – Heroku handles it all.

Beyond just building your application, our Java Buildpacks go a step further by understanding the nuances of different Java frameworks and tools. They automatically inject framework-specific configurations, such as database connection details for Postgres, eliminating the need for manual setup. This deep integration significantly reduces the friction of deploying complex Java applications. You don’t have to teach Heroku how to run your Spring Boot, Quarkus, or Micronaut app, and in some cases you don’t have to teach these frameworks how to interact with Heroku services either. In many cases, even a Procfile becomes optional! Let’s take a closer look at how the Java Buildpack supports these popular development frameworks.

Spring Boot Development Framework

The Maven or Gradle buildpack recognizes your Spring Boot project by inspecting your build definition, for example your pom.xml file. It automatically packages your app into an executable JAR, and configures the environment to run it using the embedded web server. It also helps out with Spring specific environment variables, ensuring your Spring Boot app behaves as expected when working with databases. Database connections are automatically configured using SPRING_ (such as SPRING_DATASOURCE_URL), so Spring automatically detects your use of the Heroku Postgres add-on. This is also true for our Heroku Key Value Store add-on, whereby the SPRING_REDIS_URL environment variable is automatically set. In many cases, a Procfile isn’t necessary since the buildpack can determine the main JAR file automatically and adds a default process for your application such as: web: java -Dserver.port=$PORT $JAVA_OPTS -jar $jarFile.

Quarkus Development Framework

We recently added support for Quarkus, known for its focus on developer joy. The Java (Maven) or Java (Gradle) buildpacks recognize your Quarkus project by inspecting your build definition. You can omit the usual Procfile and Heroku will default to Quarkus’ runner JAR automatically: java -Dquarkus.http.port=$PORT $JAVA_OPTS -jar build/quarkus-app/quarkus-run.jar.

Micronaut Development Framework

Micronaut, another framework designed for speed and efficiency, also benefits from the Java Buildpack’s intelligent automation. Just like with Spring Boot and Quarkus, database connections via DATABASE_URL and JDBC_DATABASE_URL and other environment-specific settings are handled automatically. You can omit the usual Procfile and Heroku will default to this automatically: java -Dmicronaut.server.port=$PORT $JAVA_OPTS -jar build/libs/*.jar.

Enhance Java Virtual Machine (JVM) Apps with Runtime Metrics

Heroku’s Language Runtime Metrics provide JVM metrics for your application, displayed in the Heroku Dashboard. This feature complements our existing system-level metrics by offering insights specific to your application’s execution, such as memory usage and garbage collection. These more granular metrics offer a clearer picture of your code’s behavior.

Heroku automatically configures your application to collect these metrics via a light-weight JVM agent. No configuration necessary.

Beyond Java: Heroku’s JVM Language Support

Apart from offering excellent support for building Java applications, Heroku offers support for additional JVM languages in Scala and Clojure. The buildpacks for those languages offer a similar suite of features backed by the sbt and Leiningen build tools.

Building great apps with Heroku and Java

Looking through our Heroku customer stories we can see that our customers are enjoying our Java support, building engagement apps, helping with cloud adoption and driving growth by leveraging Heroku’s ability to elastically scale compute intensive workloads.

• eCommerce Site & business platform: Improve user or employee engagement, and retention.
  Customer Story: Goodshuffle Pro
• Cloud Adoption: Replatforming legacy back-end services.
  Customer Story: Dovetail
• Engines & APIs: Project customer growth.
  Customer Story: PensionBee

Extend Salesforce with Java: Heroku AppLink & Eventing

Yes, and in fact, with any language supported by Heroku, it’s possible to extend your Flow, Apex, and Agentforce experiences with code, frameworks, and tools you’re familiar with from the Java ecosystem. Even if you haven’t used Java before, you’ll find its syntax similar to that of Apex. Check out our latest Heroku Eventing and AppLink pilot samples written in Java to find out more!

Heroku Java Buildpacks: Simplifying Deployment and Configuration

Heroku’s Java buildpacks are powerful tools that significantly simplify deploying JVM applications. By automating the build process, injecting framework-specific configurations, and handling runtime setup, it lets developers focus on writing code, not managing framework configuration. Here are some useful articles the Heroku DevCenter site:

• Getting started with Java and Maven
• Getting started with Java and Gradle
• Working with Spring Boot
• Connecting to Relational Databases on Heroku with Java

To submit feedback on your favorite JVM language, framework, or packaging tool, please connect with us via the Heroku GitHub roadmap. We welcome your ideas and suggestions.

The post Simplifying JVM App Development with Heroku’s Buildpack Magic appeared first on Heroku.

Developers love Heroku for its elegance and simplicity to easily build and deploy any type of app or service in the languages they love. This flexibility enables developers to build robust custom applications or specialized capabilities like agent actions, complex pricing calculations, or real-time transformations and processing. These are often capabilities where Salesforce Admins and Developers on Heroku come together to design and implement robust workflows and agents to support business processes.

The process of bringing their custom apps on Heroku to their Salesforce implementations has historically been a complex and time-consuming process. To address this, we’ve introduced Heroku AppLink, a powerful new tool designed to streamline the integration process.

Taming the Complexity of Salesforce <-> Heroku Connections

Without a native integration solution, developers and admins face several key challenges:

• Lack of visibility – No centralized place for admin/developer to view and manage all existing connections.
• Limited discoverability – Salesforce Admins and Developers struggle to discover Heroku resources in their implementations.
• Fragmented management – No centralized way for Heroku admins to manage access and connection settings.
• Security & compliance challenges – Ensuring that Heroku services meet Salesforce’s security requirements.

These challenges slowed down development, created inefficiencies between teams, and made it harder to design solutions that fully leveraged the combined power of the Heroku platform and Salesforce Clouds.

That’s why we built Heroku AppLink.

Simplifying Integration with Heroku AppLink

Heroku AppLink, now available in pilot, makes it effortless to securely connect your Heroku applications to Agentforce, Data Cloud, and any Salesforce Cloud. AppLink is designed with long term manageability, visibility, and ease of use in mind.

Now, with a single command, teams can:

• Accelerate development by eliminating manual setup and integration tasks.
• Enhance security with a standardized integration approach and managed connections that meet Salesforce security standards.
• Boost operational efficiency with more granular environment and connection definitions.
• Enhance visibility & governance by providing a single source of truth for Heroku – Salesforce integrations and single UX for managing credentials and connections.

Key Features of Heroku AppLink

• Seamless integration: Automatically connect Heroku apps with Agentforce, Salesforce Clouds, and Data Cloud for near real-time interactions.
• Managed security: Supports three interaction modes while enforcing Salesforce user permissions for data access, and while maintaining user context.
• Flows and Apex-based invocation: Call Heroku-hosted services directly from Salesforce Flows and Apex.
• SDK templates: Use predefined SDK templates to perform DML operations on Salesforce and Data Cloud data.
• Built-in discoverability: Centralized access to Heroku services and resources.

To see Heroku AppLink in action, check out our Heroku AppLink and Eventing Demo video.

Join the Heroku AppLink Pilot

The Heroku AppLink pilot is now complete. We’ve gathered great feedback to help shape the future of Heroku integrations tools. Thank you to all the developers who participated!

Heroku AppLink and Eventing: Better Together, Like Pair Programing

We’re also piloting Heroku Eventing, which works alongside AppLink to provide real-time event streaming between Heroku and Salesforce.

• Heroku AppLink -> Best for secure, managed integrations.
• Heroku Eventing -> Best for event-driven architectures, allowing real time data flow across systems.

Together, these two new capabilities can allow developers to build more responsive and interactive applications and collaborate effectively with their Salesforce Admins.

We’re excited to bring a more connected Heroku experience to developers.

The post Heroku AppLink Pilot: The Shortest Path to Bring Your Code to Agentforce appeared first on Heroku.

Managing event-driven architecture can be challenging. For many organizations, this includes a diverse set of eventing services and buses, often across multiple organizations. Developers must manage authentication and pub/sub services across teams and applications.

We’re thrilled to introduce Heroku Eventing, a powerful tool designed to help teams manage events more efficiently and securely. This new feature simplifies the process of integrating and monitoring events from various sources, ensuring a seamless and secure experience.

Simplifying Monitoring and Observability

One of the most common challenges our customers face is the need for comprehensive monitoring and observability. Traditionally, this involves manually gathering data from multiple systems or setting up complex, potentially insecure connections. Heroku Eventing offers a streamlined and secure solution to this problem.

With Heroku Eventing, teams can aggregate data from sources such as Salesforce, ServiceNow, New Relic, and Splunk, and view them in a unified, user-friendly interface. This integration provides a clear and accessible overview of platform performance and health metrics, making it easier to monitor and manage your applications.

What is Heroku Eventing?

Heroku Eventing is a robust tool that simplifies event-based application development on the Heroku platform. It offers a centralized hub for managing, subscribing to, and publishing events, streamlining the development process:

• Centralized Management: Manage all subscriptions and publications related to an app from a single, intuitive interface.
• Seamless Integration: Connect directly with Heroku Kafka and Postgres Database.
• Flexible Event Distribution: Push Kafka and Postgres events to subscribers, including data cloud and Salesforce Platform Events.
• Unified API: Use a single API to subscribe and publish to all events and webhooks.
• Secure Authentication: Securely store authentication credentials for all connected services.
• Compliance: Compliant with industry standards, including Cloud Events and Bloblang.

To see Heroku Eventing in action and better understand how it functions, check out this demo video.

Join the Pilot

Heroku Eventing is now available as a pilot. We’re looking for developers to try it out and give us feedback. By joining the pilot, you’ll get early access to Heroku Eventing, and your input will help shape the future of Heroku tools.

Sign up for the pilot today

Heroku Eventing and AppLink: Better Together, Like Pair Programing

We’ve recently completed a pilot of Heroku AppLink, which works alongside Eventing to expose Heroku apps as APIs in Salesforce, so you can more easily integrate your custom apps with Salesforce.

• Heroku AppLink -> Best for secure, managed integrations.
• Heroku Eventing -> Best for event-driven architectures, allowing real time data flow across systems.

Together, these two features allow developers to build more responsive and interactive applications.

Stay tuned for more updates as we continue improving the Heroku AppLink and Eventing experience based on pilot feedback.

We’re excited to bring a more connected Heroku experience to developers.

The post Heroku Eventing: A Router for All Your Events appeared first on Heroku.

The Heroku Extension for Visual Studio Code (VS Code) is now generally available for all customers—VS Code is an all-in-one tool that brings Heroku’s cloud management directly to your favorite IDE. In today’s fast-paced, AI-assisted development environment, switching between code editors and deployment tools can slow innovation and product delivery. ‌This extension lets you focus on building great applications by streamlining cloud resource monitoring, one-click deployments, and add-on management, all within VS Code.

Why Visual Studio Code?

Visual Studio Code (VS Code) is one of the most popular code editors, loved by developers for its extensibility, lightweight design, and robust ecosystem of extensions. Given its widespread adoption, we built the Heroku Extension to integrate seamlessly with VS Code, enabling developers to manage their Heroku apps without interrupting their flow.

Many modern AI-powered code editors, such as Windsurf and Cursor, are forks of VS Code, leveraging its powerful architecture while incorporating AI-driven capabilities. Because our extension is built for VS Code, it’s automatically compatible with these AI code editors, allowing developers to use Heroku’s platform insights and management tools in their preferred environments.

For Salesforce developers, this extension is fully compatible with Salesforce Code Builder, making it easier than ever to extend Salesforce applications with Heroku’s cloud services. Whether you’re working in VS Code, an AI-powered fork, or Code Builder, the Heroku extension enhances your development workflow by providing seamless cloud integration.

Streamline Cloud Development with Heroku and VS Code

A delightful developer experience is at the heart of what we do at Heroku. Heroku’s VS Code Extension enhances the DevEx through…

• Easy Installation: install the extension from many providers. Including the VS Code Marketplace or OpenVSX Registry. The Heroku VS Code extension is compatible with VS Code, Salesforce Code Builder and VS Code forks (Eg: Cursor, Windsurf, Trae, Google IDX)
• Real-time Resource Insights: Access to a dedicated Resource Explorer to monitor dyno statuses, manage add-ons like Heroku Postgres and Heroku Key-Value Store, and view logs directly in your IDE.
• One-click Deployment: Deploy your apps with one click, view live deployment logs, and run shell commands—all within VS Code.
• Simple Onboarding: Existing Heroku users can quickly authenticate and import apps, while newcomers can choose from curated starter templates to kickstart their journey.
• Community-Driven: Our developer community asked for Heroku’s VS Code Extension and we heard you! Your continued feedback is key. Join our GitHub community to share suggestions and track upcoming features.

The Future of Cloud Development is Here with Heroku

Heroku Extension for VS Code seamlessly bridges AI-powered coding with efficient cloud deployment, transforming your development workflow. By integrating all essential Heroku functionalities into one environment, you can build, deploy, and manage applications faster and smarter.

Try it today and experience a streamlined, modern approach to cloud development.

The post Heroku Extension for Visual Studio Code (VS Code) Now Generally Available appeared first on Heroku.

Heroku has announced exciting updates that will help Salesforce Consulting Partners expand their offerings, deepen their expertise, and deliver pro-code solutions to their customers. The updates are designed to accelerate the adoption and successful implementation of Heroku for our customers. These changes make it easy for customers to identify Consultants with Heroku expertise who can bring value to their business.

New Heroku Partner resources

Heroku introduces new resources designed to help Partners build their expertise and collaborate with the Heroku team.

• Heroku Partner Readiness Guide: A curated summary of resources to accelerate their journey to becoming a Heroku Consulting Partner.
• Heroku Technical Learning Journey: A clear path from beginner to advanced proficiency, guiding Consultants through their technical development with Heroku.
• Heroku Partner Trailblazer Community: A place to ask challenging questions, get real-time feedback, network and share ideas with fellow Partners, and access valuable resources.

Coming in 2025 – Heroku Expert Area for Partners and more

The Heroku Expert Area will be a game-changer for Salesforce Consulting Partners aiming to expand their portfolio with pro-code solutions. Becoming a Heroku Expert allows Partners to gain a trusted status and be recognized as a recommended implementation Partner for customers purchasing Heroku.

This level of expertise is also reflected in the Salesforce Partner Finder portal where customers go to look for Partners with trusted Heroku knowledge and validated experience with successful Heroku implementations. This provides customers with credible recommendations for their Heroku projects and ensures high-quality service delivery.

Requirements to become a Heroku Expert

To become a Heroku Expert, Salesforce Consulting Partners must meet specific criteria based on their expertise in implementing and delivering Heroku projects.

There are three levels of expertise for Partners:

These certifications are designed for Partners who have demonstrated a deep understanding and proven track record with Heroku solutions. To help Partners earn these certifications, Heroku will distribute exam vouchers for the Heroku Architect and Developer exams at no cost, helping lay a solid foundation for growth within the Partner Navigator program.

This Expert Area will launch later in 2025 – stay tuned!

Coming in 2025 – free products to fuel your success

Salesforce Consulting Partners will soon be able to access exclusive Heroku product benefits. These free products will enable Partners to explore Heroku’s capabilities and offer enhanced solutions to their customers.

These benefits will launch later in 2025 – stay tuned!

Looking ahead

These updates represent a major shift in how Salesforce Consulting Partners can leverage Heroku to accelerate their business growth and expand their service offerings. The Heroku Expert Area, combined with the new benefits and resources, will help Partners stay ahead of the curve in an increasingly complex digital landscape.

If you’re a Salesforce Consultant looking to expand your expertise, now is the time to dive deeper into Heroku; explore new Partners resources and stay tuned for more information on becoming a Heroku Expert. The future of cloud app development is here—make sure you’re ready to lead the way.

Interested in learning more? Check out https://www.heroku.com/partnering/

The post Heroku Introduces New Partner Resources to Empower Salesforce Consultants appeared first on Heroku.

TDX25 comes to San Francisco this March 5-6. Heroku, a Salesforce company, has a packed schedule with a variety of sessions and activities designed to enhance your knowledge of our platform and integrations with Agentforce and Salesforce technologies. Whether you’re new to Heroku or a seasoned pro, there’s something for everyone at this year’s event.

Breakout & Theater Sessions You Won’t Want to Miss

TDX is not just a conference—it’s an opportunity to learn from experts, connect with the community, and discover tools and resources that make building on the Salesforce Platform even easier. Here’s a sneak peek at some of the key sessions you can expect from Heroku:

Supercharge your Agentforce Actions with Heroku

Also available on Salesforce+

• Andrew Fawcett, VP of Developer Relations at Heroku

Learn how Salesforce’s Heroku complements Flow and Apex to extend Agentforce capabilities for complex use cases, with elastic compute and the new Heroku integration add-on.

 Add to Agenda

Monitor Real-Time Engagement via Heroku Connect & Agentforce

Also available on Salesforce+

• Errol Schmidt, CEO at reinteractive
• Chris Peterson, Sr. Director of Product Management at Heroku

Learn how Heroku and Heroku Connect can be used to rapidly build a website and connect it to Salesforce, and how to use the connected objects in Agentforce to monitor real-time customer engagement.

 Add to Agenda

Build Scalable APIs for Agentforce with MuleSoft and Heroku

Also available on Salesforce+

• Jonathan Jenkins, Senior Success Architect at Heroku
• Julián Duque, Principal Developer Advocate at Heroku

Learn how to configure and test MuleSoft Flex Gateway on Heroku to run services on multiple dynos and handle ever-increasing workloads. Discover how these services can be leveraged in Agentforce.

 Add to Agenda

How Salesforce Runs Slack Apps at Scale with Heroku

Also available on Salesforce+

• Phi Tran, Software Engineering PMTS
• Yadin Porter de León, Director of Product Marketing at Heroku

Learn how Salesforce’s Business Technology team uses Heroku to build and run custom Slack apps at scale, delighting and enabling 85,000 employees.

 Add to Agenda

Improve Apex Performance with Heroku

• Rushi Choudhury, Senior Manager at Workday
• Vivek Viswanathan, Director of Product Management at Heroku

See how Workday improved its Salesforce org by leveraging the Heroku Integration add-on to optimize Apex processes.

 Add to Agenda

Extend Your Code with Heroku and Agentforce

• Vivek Viswanathan, Director of Product Management at Heroku

Learn how to use custom code hosted on Heroku with the Heroku Integration add-on to enhance Agentforce capabilities.

 Add to Agenda

Hands on Learning with Heroku

For a more interactive learning experience, Workshops, Demos and Mini Hacks are the place to be.

Workshop: Get Started with Heroku and Slack App Integration

• Ken Alger, Heroku Developer Advocate

Learn how to integrate Heroku and Slack apps to deliver instant updates, automate tasks, and streamline user interactions.

 Add to Agenda

Demos & Mini Hacks

• Camp Mini Hacks, Level 2 Moscone West

Join the Heroku team at our Demo Booth or Camp Mini Hacks for an interactive experience. Our experts will show you how Heroku seamlessly integrates with Salesforce, Agentforce, and Slack, leveraging popular programming languages to enhance your business impact. Don’t miss this chance to explore powerful solutions and get hands-on guidance from the pros!

Heroku at TDX25 Happy Hour

TDX is a great opportunity to connect with fellow developers, product managers, and innovators who are pushing the boundaries of what’s possible. Register to join us! Our team will be on hand to answer questions, offer advice, and help you get the most out of Heroku.

See You at TDX 2025!

We’re incredibly excited to join you at TDX 2025, and we hope you’ll take advantage of all the Heroku sessions, resources, and opportunities available. Whether you’re looking to improve your app development skills, dive deeper into Agentforce and Heroku or discover the latest Heroku features, there’s no better place to be this year.

Visit TDX 2025 to register and explore the full list of sessions.

The post Heroku at TDX 2025: Empowering Developers for the Future appeared first on Heroku.

The Heroku CLI is a vital tool for developers, providing a simple, extensible way to interact with the powerful features Heroku offers. We understand the importance of keeping the CLI updated to enhance user experience and ensure stability. With the release of Heroku CLI v10, we’re excited to introduce key changes that enhance the user experience and improve compatibility with the next-generation Heroku platform.

What’s New in Version 10.0.0?

Heroku CLI v10 introduces several breaking changes, updates for Fir (the next-generation Heroku platform), and overall performance improvements. Here’s a breakdown of the key features:

Breaking Changes

• Node.js 20 Upgrade:
  The CLI has been upgraded to Node.js 20, which brings performance improvements, security fixes, and better compatibility with modern development environments.
• Changes to heroku logs Command:
  • The --dyno flag for specifying the process type and dyno name is now deprecated.
  • Cedar apps: The –dyno flag will continue to work but will be deprecated.
  • Fir apps: Users will need to use the new --process-type or --dyno-name flags instead.
• Changes to ps:stop and ps:restart Commands:
  • Positional arguments for process type and dyno name are deprecated in ps:stop and ps:restart.
  • Cedar apps: Positional arguments will still work with a deprecation warning.
  • Fir apps: Users must use the --process-type or --dyno-name flags.
• Compatibility with Fir Apps:
  Several commands no longer work with Fir apps, including heroku run, heroku ps:exec, heroku ps:copy, heroku ps:forward, and heroku ps:socks.
  • Users should now use heroku run:inside, which is designed to work with Fir apps but not with Cedar apps.

Support for Next-Generation Heroku Platform (Fir)

• OpenTelemetry Support:
  A new suite of commands under heroku telemetry allows seamless integration with OpenTelemetry for Fir apps, enabling better observability. Check out our DevCenter documentation on telemetry drains for setup instructions.
• Spaces Updates:
  • The heroku spaces:create command now supports a new --generation flag, allowing users to specify whether they are creating a Cedar or Fir space.
  • A pilot warning message will appear when Fir is selected.
  • heroku spaces, heroku spaces:info and heroku spaces:wait now display the generation of the space.
• Pipelines and Buildpacks:
  • heroku pipelines:diff has been updated to support Fir generation apps.
  • The heroku buildpacks command now lists buildpacks specific to Fir apps, based on the latest release.
• Improved Logs for Fir Apps:
  • heroku logs now includes a --tail flag for Fir apps to stream logs in real time.
  • A new “Fetching logs” message is displayed as logs are being retrieved.
  • Color rendering issues have been fixed to ensure consistent log output.

Other Updates

• oclif Upgrade: The CLI has been upgraded to oclif v4.14.36, providing a more stable and modular architecture.
• GitHub Workflows: Updated GitHub workflows and actions now run on Node 20

Why These Updates Matter

The upgrade to Node.js 20 sets a solid foundation for future improvements and feature releases. These changes also help ensure that your Heroku CLI experience stays smooth and reliable as we continue to innovate.

The CLI is now ready for the next-generation Fir platform, making it easier to manage and deploy modern apps with enhanced observability, performance, and flexibility.

Ready to upgrade? Update to CLI version 10.0.0 by running heroku update. For more installation options, visit our Dev Center. We encourage you to try it and share your feedback for enhancing the Heroku CLI and for our full Heroku product via the Heroku GitHub roadmap.

The post Heroku CLI v10: Support for Next Generation Heroku Platform appeared first on Heroku.

Over the past year, Heroku has been on a journey of reflection as we rebase the platform to address the changing needs of app teams toward the future without disrupting your business. In the Heroku way, we want to be thoughtful about your experience as we evolve.

When we started Heroku, it was the early days of cloud computing, before Docker and Kubernetes were household names in IT. We launched Heroku (and the platform-as-a-service category) to help teams get to the cloud easily with an elegant user experience in front of a powerful platform that automated a lot of the manual work that slowed teams down. To do that then, we had to build a lot of the tooling ourselves, like orchestration and self-hosting the databases in AWS. ‌The platform delivered customers the outcomes they needed to deploy apps quickly and scale effortlessly in the cloud‌—all without having to worry about how the platform worked.

Fast forward and so much has changed. The landscape of infrastructure, application, and developer tools ecosystem is unrecognizable. Cloud is now the default mode. Cloud-native is a massive movement; the cloud is built on open source, and Kubernetes is the operating system of the cloud. And in an even shorter amount of time, we have seen AI become pervasive in every facet of life, business, and technology–specifically in the software delivery lifecycle.

The challenges facing technology teams have only grown in complexity and risk while increasing the cognitive load on developers and constraining their productivity. While it seems that everything has changed, what hasn’t changed is our mission—to help teams build, deploy, and scale apps and services effortlessly in the cloud.

We’re excited to announce Heroku’s Next Generation Platform-as-a-Service that continues to deliver on this mission, addressing the needs of cloud-native and AI app delivery at scale with a delightful developer experience and a streamlined operator experience.

Heroku changed how the world deployed apps with git push heroku main. That seamless deployment experience is at the core of what developers love about Heroku. Now, we’re bringing that same magic to .NET. Learn more in this post and get started with the beta today.

Kubernetes is the operating system of the cloud, and its ecosystem is vast and innovative. While powerful, it is a part of a platform, not the platform itself. CNCF’s annual survey shows that lack of expertise and concerns about security and observability prevent teams from adopting or scaling Kubernetes. In this release, Heroku brings AWS EKS, ECR, OpenTelemetry, AWS Global Accelerator, Cloud Native Buildpacks, Open Container Initiative (OCI) and AWS Graviton into the platform. Integrating, automating, and scaling with our platform and its opinions help you get started faster and grow safely. One difference now is that some opinions will be “loosely held” and you’ll be able to adjust those configurations to your business requirements. Learn more about the platform updates in this blog.

The impact of AI—on all aspects of our digital lives—continues to grow. However, the ability for organizations to deliver value to their customers and recognize a return on their investments with AI is presenting an increasing challenge. For most companies complexity and security are the largest impediments to integrating AI into their applications and services. By providing managed inference and AI development with AWS Bedrock into the Heroku experience—empowering developers through opinionated simplification—we take care of all the setup, so that you can focus on delivering value. Learn more about Heroku AI in this blog.

We’re excited about this release and are looking forward to hearing from you. Together you’ve built over 65 million apps and created over 38 million data stores on Heroku since 2007, and your critical business apps are serving over 65 billion requests per day. From students learning how to code to processing insurance claims to curating luxury brand experiences—thank you for building your business on Heroku.

The Heroku Next Generation Platform is available in pilot today and will be generally available in early 2025. Sign-up here for pilot access and to stay informed and check out our public roadmap.

The post The Next Generation of the Heroku Platform appeared first on Heroku.

We’re excited to announce that official support for .NET on Heroku is entering public beta starting today. Developers can now build and deploy applications in C#, F#, and Visual Basic, using frameworks like ASP.NET Core and Blazor, all with the simplicity and flexibility of the Heroku platform.

.NET has long been one of the most requested frameworks to join Heroku’s lineup, and for good reason. Known for its power and versatility .NET enables developers to build everything from high-performance APIs to complex, full-stack web applications and scalable microservices. Now, developers can combine .NET’s capabilities with Heroku’s streamlined platform for a first-class developer experience.

Why Now?

Over the last decade .NET has evolved from a Windows-only framework into a cross-platform and open-source ecosystem. Shaped by lessons learned and inspired by best practices from other technologies, .NET elegantly emphasizes simplicity, maintainability, and performance – qualities that naturally align with Heroku’s mission to help developers focus on building great apps without unnecessary complexity.

For years, developers have relied on community-built buildpacks to run .NET apps on Heroku, from the early buildpacks to the popular .NET Core buildpack. These solutions not only showed the demand, but also demonstrated what was possible. With official support for .NET, we’re building on that foundation to deliver a cohesive and reliable experience. Developers can expect consistent updates, rigorous testing and quality assurance to confidently build and scale their applications.

Want to Get Started?

Our buildpack makes deploying .NET applications a breeze, offering seamless functionality out of the box with the flexibility to customize as needed. Deploying is simple:

heroku create --buildpack heroku/dotnet
git push heroku main

Note: Setting the buildpack with --buildpack heroku/dotnet is only required during the beta.

Whether you’re a seasoned .NET developer or new to the framework, it’s easy to get started. Check out our Getting Started tutorial walking through steps to deploy a Blazor app using a fully managed Heroku Postgres database, running migrations, and more. Our .NET support reference has more detailed documentation.

There’s no better time to use .NET for your apps — and no better place to deploy them than Heroku. Share your feedback via our public roadmap and help shape the future of .NET on Heroku!

We can’t wait to see what you’ll build, and we’re here to help every step of the way.

The post .NET Support on Heroku appeared first on Heroku.

Cloud platforms have come a long way since Heroku first set out to empower developers. Today’s cloud native development demands even greater flexibility, openness, and scalability. A fun fact about Heroku is that we use trees to denote the generation of the platform technology stack (aka version). In the tradition of Aspen, Bamboo, and Cedar, we are introducing Fir, the latest Heroku technology stack built on open source standards and cloud native technologies.

When we launched Cedar, we introduced a new way of thinking about application development and popularized principles like stateless applications, automated builds, and other twelve-factor principles; encouraging developers to build applications that were portable, horizontally scalable, and resilient. This work extended beyond our own user base and shaped how the industry builds and deploys applications. These principles were adopted by ecosystems like the Spring community and would ultimately become core principles of the cloud-native movement, laying the foundation for the technologies that define the Cloud Native Landscape today.

Embracing and Creating Open Source Standards

Fir is built on a foundation of cloud native technologies and open source standards, ensuring portability, interoperability, and a vibrant ecosystem for your applications. By embracing technologies like the Open Container Initiative (OCI), Cloud Native Buildpacks (CNBs), OpenTelemetry, and Kubernetes (K8s), we're providing a platform that's not only powerful but also incredibly flexible.

By building on these open source foundations, Heroku avoids reinventing the wheel and aligns with open source standards. We can focus our energy on what we do best: creating a smooth and productive developer experience and bringing that attention to the cloud native ecosystem and enabling end user adoption.

Open Container Initiative & Cloud Native Buildpacks

Today, OCI images are the new cloud executables. By moving to OCI artifacts, all Fir apps will be using images with compatibility across different environments. This means you can build your application once, run it locally, and deploy it anywhere, without worrying about vendor lock-in or compatibility issues.

Building container images can be complex and difficult to manage especially at scale. This is why we created Cloud Native Buildpacks with Pivotal. To ensure its broad adoption and ongoing development, we donated the project to the Cloud Native Computing Foundation, establishing it as a standardized way to build container images directly from source code without needing Dockerfiles. Earlier this year, we open sourced CNBs for all of our supported languages. We built these CNBs on years of experience with our existing buildpacks and running them at scale in production. With our language experts, you can focus on your code, and not the intricacies of containerization.

OpenTelemetry

Observability is crucial for modern applications, and OpenTelemetry provides a standardized way to collect and analyze telemetry data. Fir integrates with OpenTelemetry, not only allowing you to instrument your applications with upstream SDKs but also powering our own Heroku Metrics product. These runtime and network telemetry signals can also be easily integrated with your preferred OpenTelemetry-compatible monitoring and analysis tools. Whether you're using an open-source solution or a commercial provider, you can effortlessly integrate your observability pipeline with Fir.

Kubernetes

Fir is built on Kubernetes, the industry-standard container orchestration system. This allows us to offer more flexible dyno types and increased scaling limits to many hundreds of dynos per space, giving you greater control over your application’s resources and performance. We've abstracted away the complexities of Kubernetes, so you can enjoy its benefits without ever having to touch it directly. You get the same simple Heroku experience, now with the added power and scalability of Kubernetes.

By embracing these open source standards, Fir ensures your applications are future-proof, portable, and ready to integrate with the broader cloud-native ecosystem.

A Platform for the Full Stack Developer

At Heroku, we believe in empowering developers, which means the best choices are the ones you don't have to make. The modern day developer is overwhelmed with choices. It’s not good enough to be a full stack developer, it’s common to also be responsible for containerization, base image updates, and potentially operating the cluster the app runs in. Like Cedar, Fir is built on a core principle: maximize developer productivity by minimizing distractions.

What does this mean? Fir is still the Heroku you know and love. It’s rooted in the world renowned developer experience while built on a bedrock of security and stability. We achieve this by offering seamless functionality out of the box with the flexibility to customize as needed. In today's complex development landscape, minimizing cognitive load is crucial. This allows you to focus on what truly matters: delivering value to your customers.

Here are a few examples of how this principle comes to life in Fir:

• Streamlined deployments: Deploy your code with a single command, using Cloud Native Buildpacks to automatically handle the complexities of containerization.
• Simplified scaling: Scale your applications effortlessly with intuitive controls and intelligent defaults, powered by Kubernetes behind the scenes.
• Integrated observability: Gain valuable insights into your application's performance with OpenTelemetry, fully integrated into Fir and our Heroku Metrics product.

By embracing open source standards and adhering to this design principle, we create a platform that is both powerful and predictable. Fir gives you the freedom and flexibility you need to build modern, cloud-native applications, using the developer experience that Heroku is known for.

Looking Ahead

Fir is a platform about bringing Cloud Native to everyone and is built to be the foundation for the next decade and beyond.

This is just the beginning. Today, we’re starting with a pilot for Fir Private Spaces, analogous to our Cedar Generation Private Spaces offering. We have an exciting roadmap ahead, with plans to introduce:

• Enhanced networking features including exposing apps through AWS VPC PrivateLink and AWS Transit Gateway
• Expand Isolation & sandboxing use cases such as Fir for Multi-Tenancy
• Software supply chain security including Software Bill of Materials (SBOMs) generation and cryptographically signed build provenance

Open source technologies form many of the underpinnings of Fir, bringing increased innovation and reliability to the platform, and we’re committed to actively participating in those communities. Your feedback and contributions are invaluable as we continue to evolve and improve Fir, directly shaping the future of the platform. Please join in the conversation on our public roadmap.

Ready to experience the next generation of Heroku? Sign up for the Heroku Fir pilot today and start building your next application on a platform built for the future.

The post Planting New Platform Roots in Cloud Native with Fir appeared first on Heroku.

Over the last couple of years, we’ve repeatedly heard the question “who will build the Heroku of AI?”. The answer to that question is that Heroku will, of course.

We are excited to bring AI to the Heroku platform with the pilot of Managed Inference and Agents, delivered with the graceful developer and operational experience and composability that are the heart of Heroku.

Heroku’s Managed Inference and Agents provide access to leading AI models from the world's top AI providers. These solutions optimize the developer and operator experience to easily extend applications on Heroku with AI. Heroku customers can benefit from this high performance and high trust AI service to focus on their core business needs, while avoiding the complexity and overhead of trying to run their own AI infrastructure and systems.

Heroku AI

At its creation, Heroku took something desirable but complicated—deploying and scaling Rails applications—and made it simple and accessible, so that developers could focus on the value of their applications rather than all the complexity of deploying, scaling, and operating them.

Today, Heroku is doing the same with AI. We’re delivering a set of capabilities that enable developers to focus on the value of their applications augmented with AI, rather than taking on the complexity of operating this rapidly evolving technology. Managed Inference and Agents is the initial offering of Heroku AI, and the cornerstone of our strategic approach to AI on Heroku.

Managed Inference and Agents

Developing applications that leverage AI often means interoperating with large language models (LLMs), embedding models (to power retrieval augmented generation or RAG), and various image or multi-modal models that support content beyond text. The range of model types is vast, their value in different domains are quite variable, and their APIs and configurations are often divergent and complex.

Heroku Managed Inference provides access to an opinionated set of models, chosen for their generative power and performance, optimized for ease of use and efficacy in the domains our customers need most.

Adding access to an AI model in your Heroku application is as easy as heroku ai:models:create in the Heroku CLI. This provides the environment variables for the selected model, making it seamless to call from within your application.

To facilitate model testing and evaluation, the Heroku CLI also provides heroku ai:models:call, allowing users to interact with a model from the command line, simplifying the process of optimizing prompts and context, and debugging interactions with AI models.

Heroku Agents extend Managed Inference with an elegant set of primitives and operations, allowing developers to create AI agents that can execute code in Heroku’s trusted Dynos, as well as call tools and application logic. These capabilities allow agents to act on behalf of the customer, and to extend both application logic and platform capabilities in developer-centric ways. Allowing developers to interleave application code, calls to AI, execute logic created by AI, and use of AI tools, all within the programmatic context.

Join the Pilot Today

Heroku Managed Inference and Agents is now in Pilot, and we invite you to join this exciting phase of the product to push the boundaries of AI applications. Apply to join the Managed Inference and Agents Pilot here, and please send any questions, comments, or requests our way.

Check out this blog for more details about how Heroku, a Salesforce company, supercharges Agentforce.

The post Heroku AI | Managed Inference and Agents appeared first on Heroku.

Back in September 2023, we announced our Public Beta for our new Common Runtime router: Router 2.0.

Now generally available, Router 2.0 will replace the legacy Common Runtime router in the coming months, and bring new networking capabilities and performance to our customers.

The beta launch of Router 2.0 also enabled us to deliver HTTP/2 to our customers. And now, because Router 2.0 has become generally available, HTTP/2 is also generally available for all common runtime customers and even Private Spaces customers too.

We’re excited to have Router 2.0 be the foundation for Heroku to deliver new cutting edge networking features and performance improvements for years to come.

Why a New Router?

Why build a new router instead of improving the existing one? Our primary motivator has been faster and safer delivery of new routing features for our customers. You can see the full rationale behind the change in our Public Beta post.

Lessons Learned from Public Beta

Over the past months, Router 2.0 has been available in public beta, allowing us to gather valuable insights and iterate on its design. Because of early adopter customers and a wealth of feedback through our public roadmap, we were able to make dozens of improvements to the Router and ensure it was fully vetted before promoting it to a GA state.

We made all sorts of improvements during that time, and all of them were fairly straight-forward with one exception involving Puma-based applications. Through our investigations, we actually discovered a bug in Puma itself, and were able to contribute back to the community to get it resolved.

The in-depth analysis below showcases the engineering investigation that took place during the Beta period and the amount of rigorous testing that was done to ensure our new platform met the level of performance and trust that our customers expect.

Pumas, Routers, and Keepalives-Oh My!

Tips and Tricks for Leveraging Router 2.0

Ready to try Router 2.0? Well here are some helpful tips & tricks from the folks that know it best:

Tips & Tricks for Migration to Router 2.0

The Power of HTTP/2

Starting today, HTTP/2 support is now generally available for both Common Runtime customers and Private Spaces customers.

HTTP/2 support is one of the most requested and desired improvements for the Heroku platform. HTTP/2 can be significantly faster than HTTP 1.1 by introducing features like multiplexing and header compression to reduce latency and therefore improve the end-user experience of Heroku apps. We were excited to bring the benefits of HTTP/2 to all Heroku customers.

You can find even more information about the benefits of HTTP/2 and how it works on Heroku from our Public Beta Launch Blog.

Stay tuned for an upcoming blog post and demo showcasing the observable performance improvements when enabling HTTP/2 for your web application!

Get Started Today

Enable Router 2.0

To start routing web requests through Router 2.0 for your Common Runtime app simply run the command:

$ heroku features:enable http-routing-2-dot-0 -a <app name>

Enable HTTP/2

Common Runtime:

HTTP/2 is now enabled by default on Router 2.0. If you follow the same command above, your application will begin to handle HTTP/2 traffic.

A valid TLS certificate is required for HTTP/2. We recommend using Heroku Automated Certificate Management.

In the Common Runtime, we support HTTP/2 on custom domains, but not on the built-in <app-name-cff7f1443a49>.herokuapp.com domain.

To disable HTTP/2, while still using Router 2.0, you can use the command:

heroku labs:enable http-disable-http2 -a <app name>

Private Spaces:

To enable HTTP/2 for a Private Spaces app, you can use the command:

$ heroku features:enable spaces-http2 -a <app name>

In Private Spaces, we support HTTP/2 on both custom domains and the built-in default app domain.

To disable HTTP/2, simply disable the Heroku feature spaces-http2 flag on your app.

The Exciting Future of Heroku Networking

We’re really excited to have brought this entire new routing platform online through a rigorously tested beta period. We appreciate all of the patience and support from our customers as we built out Router 2.0 and its associated features.

This is only the beginning. Now that Router 2.0 is GA, we can start on the next aspects of our roadmap to bring even more innovative and modern features online like enhanced Network Error Logging, HTTP/2 all the way to the dyno, HTTP/3, mTLS, and others.

We'll continue monitoring the public roadmap and your feedback as we explore future networking and routing enhancements, especially our continued research on expanding our networking capabilities.

The post Router 2.0 and HTTP/2 Now Generally Available appeared first on Heroku.

Update: Puma 7.0 was released with a fix for the bug described in this article. We recommend Ruby applications upgrade to Puma 7.0.4 or higher.

This week, Heroku made Router 2.0 generally available, bringing features like HTTP/2, performance improvements and reliability enhancements out of the beta program!

Throughout the Router 2.0 beta, our engineering team has addressed several bugs, all fairly straight-forward with one exception involving Puma-based applications. A small subset of Puma applications would experience increased response times upon enabling the Router 2.0 flag, reflected in customers’ Heroku dashboards and router logs. After thorough router investigation and peeling back Puma’s server code, we realized what we had stumbled upon was not actually a Router 2.0 performance issue. The root cause was a bug in Puma! This blog takes a deep dive into that investigation, including some tips for avoiding the bug on the Heroku platform while a fix in Puma is being developed. If you’d like a shorter ride (aka. the TL;DR), skip to The Solution section of this blog. For the full story and all the technical nitty gritty, read on.

Reproduction

The long response times issue was reported by Heroku add-on partner Judoscale who noticed large performance differences between Router 2.0 and the legacy router in high load scenarios. We greatly appreciate Judoscale’s detailed report. As Judoscale reported, in high load scenarios, the performance differences between Router 2.0 and the legacy router were disturbingly stark. An application scaled to 2 Standard-1X dynos would handle 30 requests per second just fine through the legacy router. Through Router 2.0, the same traffic would produce very long tail response times (95th and 99th percentiles). Under enough load, throughput would drop and requests would fail with H12: Request Timeout. The impact was immediate upon enabling the http-routing-2-dot-0 feature flag:

At first, our team of engineers had difficulty reproducing the above, despite running a similarly configured Puma + Rails app on the same framework and language versions. We consistently saw good response times from our app.

Then we tried varying the Rails application’s internal response time. We injected some artificial server lag of 200 milliseconds and that’s when things really took off:

This was quite the realization! In staging environments, Router 2.0 is subject to automatic load tests that run continuously, at varied request rates, body sizes, protocol versions. etc.. These request rates routinely reach much higher levels than 30 requests per second. However, the target applications of these load tests did not include a Heroku app running Puma + Rails with any significant server-side lag.

Investigation

With a reproduction in-hand, we were now in a position to investigate the high response times. We spun up our test app in a staging environment and started injecting a steady load of 30 requests per second.

Our first thought was that perhaps the legacy router is faster at forwarding requests to the dyno because its underlying TCP client manages connections in a way that plays nicer with the Puma server. We hopped on a router instance and began dumping netstat connection states for one of our Puma app’s web dynos :

Connections from legacy router → dyno

[email protected] | # netstat | grep ip-10-1-38-72.ec2:11059
tcp 0 0 ip-10-1-87-57.ec2:28631 ip-10-1-38-72.ec2:11059 ESTABLISHED
tcp 0 0 ip-10-1-87-57.ec2:30717 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:15205 ip-10-1-38-72.ec2:11059 ESTABLISHED
tcp 0 0 ip-10-1-87-57.ec2:17919 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:24521 ip-10-1-38-72.ec2:11059 TIME_WAIT

Connections from Router 2.0 → dyno

[email protected] | # netstat | grep ip-10-1-38-72.ec2:11059
tcp 0 0 ip-10-1-87-57.ec2:24630 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:22476 ip-10-1-38-72.ec2:11059 ESTABLISHED
tcp 0 0 ip-10-1-87-57.ec2:38438 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:38444 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:31034 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:38448 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:41882 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:23622 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:31060 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:31042 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:23648 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:31054 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:23638 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:38436 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:31064 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:22492 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:38414 ip-10-1-38-72.ec2:11059 TIME_WAIT
tcp 0 0 ip-10-1-87-57.ec2:42218 ip-10-1-38-72.ec2:11059 ESTABLISHED
tcp 0 0 ip-10-1-87-57.ec2:41880 ip-10-1-38-72.ec2:11059 TIME_WAIT

In the legacy router case, it seemed like there were fewer connections sitting in TIME_WAIT. This TCP state is a normal stop point along the lifecycle of a connection. It means the remote host (dyno) has sent a FIN indicating the connection should be closed. The local host (router) has sent back an ACK, acknowledging the connection is closed.

The connection hangs out for some time in TIME_WAIT, with the value varying among operating systems. The Linux default is 2 minutes. Once that timeout is hit, the socket is reclaimed and the router is free to re-use the address + port combination for a new connection.

With this understanding, we formed a hypothesis that the Router 2.0 HTTP client was churning through connections really quickly. Perhaps the new router was opening connections and forwarding requests at a faster rate than the legacy router, thus overwhelming the dyno.

Router 2.0 is written in Go and relies upon the language’s standard HTTP package. Some research turned up various tips for configuring Go’s http.Transport to avoid connection churn. The main recommendation involved tuning MaxIdleConnsPerHost . Without explicitly setting this configuration, the default value of 2 is used.

type Transport struct {
    // MaxIdleConnsPerHost, if non-zero, controls the maximum idle
    // (keep-alive) connections to keep per-host. If zero,
    // DefaultMaxIdleConnsPerHost is used.
    MaxIdleConnsPerHost int
    ...
}

const DefaultMaxIdleConnsPerHost = 2

The problem with a low cap on idle connections per host is that it forces Go to close connections more often. For example, if this value is set to a higher value, like 10, our HTTP transport will keep up to 10 idle connections for this dyno in the pool. Only when the 11th connection goes idle does the transport start closing connections. With the number limited to 2, the transport will close more connections which also means opening more connections to our dyno. This could put strain on the dyno as it requires Puma to spend more time handling connections and less time answering requests.

We wanted to test our hypothesis, so we set DefaultMaxIdleConnsPerHost: 100 on the Router 2.0 transport in staging. The connection distribution did change and now Router 2.0 connections were more stable than before:

[email protected] | # netstat | grep 'ip-10-1-2-62.ec2.:37183'
tcp 0 0 ip-10-1-34-185.ec:36350 ip-10-1-2-62.ec2.:37183 ESTABLISHED
tcp 0 0 ip-10-1-34-185.ec:11956 ip-10-1-2-62.ec2.:37183 ESTABLISHED
tcp 0 0 ip-10-1-34-185.ec:51088 ip-10-1-2-62.ec2.:37183 ESTABLISHED
tcp 0 0 ip-10-1-34-185.ec:60876 ip-10-1-2-62.ec2.:37183 ESTABLISHED

To our dismay, this had zero positive effect on our tail response times. We were still seeing the 99th percentile at well over 2 seconds for a Rails endpoint that should only take about 200 milliseconds to respond.

We tried changing some other configurations on the Go HTTP transport, but saw no improvement. After several rounds of updating a config, waiting for the router artifact to build, and then waiting for the deployment to our staging environment, we began to wonder—can we reproduce this issue locally?

Going local

Fortunately, we already had a local integration test set-up for running requests through Router 2.0 to a dyno. We typically utilize this set-up for verifying features and fixes, rarely for assessing performance. We subbed out our locally running “dyno” for a Puma server with a built-in 200ms lag on the /fixed endpoint. We then fired off 200 requests over 10 different connections with hey:

❯ hey -q 200 -c 10 -host 'purple-local-staging.herokuapp.com' https://localhost:80/fixed

Summary:
  Total:    8.5804 secs
  Slowest:    2.5706 secs
  Fastest:    0.2019 secs
  Average:    0.3582 secs
  Requests/sec:    23.3090

  Total data:    600 bytes
  Size/request:    3 bytes

Response time histogram:
  0.202 [1]    |
  0.439 [185]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.676 [0]    |
  0.912 [0]    |
  1.149 [0]    |
  1.386 [0]    |
  1.623 [0]    |
  1.860 [0]    |
  2.097 [1]    |
  2.334 [6]    |■
  2.571 [7]    |■■


Latency distribution:
  10% in 0.2029 secs
  25% in 0.2038 secs
  50% in 0.2046 secs
  75% in 0.2086 secs
  90% in 0.2388 secs
  95% in 2.2764 secs
  99% in 2.5351 secs

Details (average, fastest, slowest):
  DNS+dialup:    0.0003 secs, 0.2019 secs, 2.5706 secs
  DNS-lookup:    0.0002 secs, 0.0000 secs, 0.0034 secs
  req write:    0.0003 secs, 0.0000 secs, 0.0280 secs
  resp wait:    0.3570 secs, 0.2018 secs, 2.5705 secs
  resp read:    0.0002 secs, 0.0000 secs, 0.0175 secs

Status code distribution:
  [200]    200 responses

As you can see, the 95th percentile of response times is over 2 seconds, just as we had seen while running this experiment on the platform. We were now starting to worry that the router itself was inflating the response times. We tried targeting Puma directly at localhost:3000, bypassing the router altogether:

❯ hey -q 200 -c 10 https://localhost:3000/fixed

Summary:
  Total:    8.3314 secs
  Slowest:    2.4579 secs
  Fastest:    0.2010 secs
  Average:    0.3483 secs
  Requests/sec:    24.0055

  Total data:    600 bytes
  Size/request:    3 bytes

Response time histogram:
  0.201 [1]    |
  0.427 [185]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.652 [0]    |
  0.878 [0]    |
  1.104 [0]    |
  1.329 [0]    |
  1.555 [0]    |
  1.781 [0]    |
  2.007 [0]    |
  2.232 [2]    |
  2.458 [12]    |■■■


Latency distribution:
  10% in 0.2017 secs
  25% in 0.2019 secs
  50% in 0.2021 secs
  75% in 0.2026 secs
  90% in 0.2042 secs
  95% in 2.2377 secs
  99% in 2.4433 secs

Details (average, fastest, slowest):
  DNS+dialup:    0.0002 secs, 0.2010 secs, 2.4579 secs
  DNS-lookup:    0.0001 secs, 0.0000 secs, 0.0016 secs
  req write:    0.0001 secs, 0.0000 secs, 0.0012 secs
  resp wait:    0.3479 secs, 0.2010 secs, 2.4518 secs
  resp read:    0.0000 secs, 0.0000 secs, 0.0003 secs

Status code distribution:
  [200]    200 responses

Wow! These results suggested the issue is reproducible with any ‘ole Go HTTP client and a Puma server. We next wanted to test out a different client. The load injection tool, hey is also written in Go, just like Router 2.0. We next tried ab which is written in C:

❯ ab -c 10 -n 200 https://127.0.0.1:3000/fixed
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests


Server Software:
Server Hostname:        127.0.0.1
Server Port:            3000

Document Path:          /fixed
Document Length:        3 bytes

Concurrency Level:      10
Time taken for tests:   8.538 seconds
Complete requests:      200
Failed requests:        0
Total transferred:      35000 bytes
HTML transferred:       600 bytes
Requests per second:    23.42 [#/sec] (mean)
Time per request:       426.911 [ms] (mean)
Time per request:       42.691 [ms] (mean, across all concurrent requests)
Transfer rate:          4.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       2
Processing:   204  409  34.6    415     434
Waiting:      204  409  34.7    415     434
Total:        205  410  34.5    415     435

Percentage of the requests served within a certain time (ms)
  50%    415
  66%    416
  75%    416
  80%    417
  90%    417
  95%    418
  98%    420
  99%    429
 100%    435 (longest request)

Another wow! The longest request took about 400 milliseconds, much lower than the 2 seconds above. Had we just stumbled upon some fundamental incompatibility between Go’s standard HTTP client and Puma? Not so fast.

A deeper dive into the ab documentation surfaced this option:

❯ ab -h
Usage: ab [options] [http[s]://]hostname[:port]/path
Options are:
    ...
    -k              Use HTTP KeepAlive feature

That’s different than hey’s default of enabling keepalive by default. Could that be significant? We re-ran ab with -k:

❯ ab -k -c 10 -n 200 https://127.0.0.1:3000/fixed
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests


Server Software:
Server Hostname:        127.0.0.1
Server Port:            3000

Document Path:          /fixed
Document Length:        3 bytes

Concurrency Level:      10
Time taken for tests:   8.564 seconds
Complete requests:      200
Failed requests:        0
Keep-Alive requests:    184
Total transferred:      39416 bytes
HTML transferred:       600 bytes
Requests per second:    23.35 [#/sec] (mean)
Time per request:       428.184 [ms] (mean)
Time per request:       42.818 [ms] (mean, across all concurrent requests)
Transfer rate:          4.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       6
Processing:   201  405 609.0    202    2453
Waiting:      201  405 609.0    202    2453
Total:        201  406 609.2    202    2453

Percentage of the requests served within a certain time (ms)
  50%    202
  66%    203
  75%    203
  80%    204
  90%   2030
  95%   2242
  98%   2267
  99%   2451
 100%   2453 (longest request)

Now the output looked just like the hey output. Next, we ran hey with keepalives disabled:

❯ hey -disable-keepalive -q 200 -c 10 https://localhost:3000/fixed

Summary:
  Total:    8.3588 secs
  Slowest:    0.4412 secs
  Fastest:    0.2091 secs
  Average:    0.4115 secs
  Requests/sec:    23.9269

  Total data:    600 bytes
  Size/request:    3 bytes

Response time histogram:
  0.209 [1]    |
  0.232 [3]    |■
  0.255 [1]    |
  0.279 [0]    |
  0.302 [0]    |
  0.325 [0]    |
  0.348 [0]    |
  0.372 [0]    |
  0.395 [0]    |
  0.418 [172]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.441 [23]    |■■■■■


Latency distribution:
  10% in 0.4140 secs
  25% in 0.4152 secs
  50% in 0.4160 secs
  75% in 0.4171 secs
  90% in 0.4181 secs
  95% in 0.4187 secs
  99% in 0.4344 secs

Details (average, fastest, slowest):
  DNS+dialup:    0.0011 secs, 0.2091 secs, 0.4412 secs
  DNS-lookup:    0.0006 secs, 0.0003 secs, 0.0017 secs
  req write:    0.0001 secs, 0.0000 secs, 0.0011 secs
  resp wait:    0.4102 secs, 0.2035 secs, 0.4343 secs
  resp read:    0.0001 secs, 0.0000 secs, 0.0002 secs

Status code distribution:
  [200]    200 responses

Again, no long tail response times and the median values comparable to the first run with ab.

Even better, this neatly explained the performance difference between Router 2.0 and the legacy router. Router 2.0 adds support for HTTP keepalives by default, in line with HTTP/1.1 spec. In contrast, the legacy router closes connections to dynos after each request. Keepalives usually improve performance, reducing time spent in TCP operations for both the router and the dyno. Yet, the opposite was true for a dyno running Puma.

Diving deep into Puma

Note that we suggest reviewing this brief Puma architecture document if you’re unfamiliar with the framework and want to get the most out of this section. To skip the code review, you may fast-forward to The Solution.

This finding was enough of a smoking gun to send us deep into the the Puma server code, where we homed in on the process_client method. Let’s take a look at that code with a few details in mind:

1. Each Puma thread can only handle a single connection at at time. A client is a wrapper around a connection.
2. The handle_request method handles exactly 1 request. It returns false when the connection should be closed and true when it should be kept open. A client with keepalive enabled will end up in the true condition on line 470.
3. fast_check is only false once we’ve processed @max_fast_inline requests serially off the connection and when there are more connections waiting to be handled.
4. For some reason, even when the number of connections exceeds the max number of threads, @thread_pool.backlog > 0 is often times false.
5. Altogether, this means the below loop usually executes indefinitely until we’re able to bail out when handle_request returns false.

Code snippet from puma/lib/puma/server.rb in Puma 6.4.2.

When does handle_request actually return false? That is also based on a bunch of conditional logic, the core of it is in the prepare_response method. Basically, if force_keep_alive is false, handle_request will return false. (This is not exactly true. It’s more complicated, but that’s not important for this discussion.)

Code snippet from puma/lib/puma/request.rb in Puma 6.4.2.

The last thing to put the puzzle together: max_fast_inline defaults to 10. That means Puma will process at least 10 requests serially off a single connection before handing the connection back to the reactor class. Requests that may have come in a full second ago are just sitting in the queue, waiting for their turn. This directly explains our 10*200ms = 2 seconds of added response time for our longest requests!

We figured setting max_fast_inline=1 might fix this issue, and it does sometimes. However, under sufficient load, even with this setting, response times will climb. The problem is the other two OR’ed conditions circled in blue and red above. Sometimes the number of busy threads is less than the max and sometimes, there are no new connections to accept on the socket. However, these decisions are made at a point in time and the state of the server is constantly changing. They are subject to race conditions since other threads are concurrently accessing these variables and taking actions that modify their values.

The Solution

After reviewing the Puma server code, we came to the conclusion that the simplest and safest way to bail out of processing requests serially would be to flat-out disable keepalives. Explicitly disabling keepalives in the Puma server means handing the client back to the reactor after each request. This is how we ensure requests are served in order.

Once confirming these results with the Heroku Ruby language owners, we opened a Github issue on the Puma project and a pull request to add an enable_keep_alives option to the Puma DSL. When set to false, keepalives are completely disabled. The option will be released soon, likely in Puma 6.5.0.

We then re-ran our load tests with enable_keep_alives disabled in Puma and Router 2.0 enabled on the app:

// config/puma.rb
...
enable_keep_alives false

The response times and throughput improved, as expected. Additionally, once disabling Router 2.0, the response times stayed the same:

Moving forward

Keeping keepalives

Keeping connections alive reduces time spent in TCP operations. Under sufficient load and scale, avoiding this overhead cost can positively impact apps’ response times. Additionally, keepalives are the de facto standard in HTTP/1.1 and HTTP/2. Because of this, Heroku has chosen to move forward with keepalives as the default behavior for Router 2.0.

Through raising this issue on the Puma project, there has already been movement to fix the bad keepalive behavior in the Puma server. Heroku engineers remain active participants in discussions arounds these efforts and are committed to solving this problem. Once a full fix is available, customers will be able to upgrade their Puma versions and use keepalives safely, without risk of long response times.

Disabling keepalives as a stopgap

In the meantime, we have provided another option for disabling keepalives when using Router 2.0. The following labs flag may be used in conjunction with Router 2.0 to disable keepalives between the router and your web dynos:

heroku labs:enable http-disable-keepalive-to-dyno -a my-app

Note that this flag has no effect when using the legacy router as keepalives between the legacy router and dyno are not supported. For more information, see Heroku Labs: Disabling Keepalives to Dyno for Router 2.0.

Other options for Puma

You may find that your Puma app does not need keepalives disabled in order to perform well while using Router 2.0. We recommend testing and tuning other configuration options, so that your app can still benefit from persistent connections between the new router and your dyno:

• Increase the number of threads. More threads means Puma is better able to handle concurrent connections.
• Increase the number of workers. This is similar to increasing the number of threads.
• Decrease the max_fast_inline number. This will limit the number of requests served serially off a connection before handling queued requests.

Other languages & frameworks

Our team also wanted to see if this same issue would present in other languages or frameworks. We ran load tests, injecting 200 milliseconds of server-side lag over the top languages and frameworks on the Heroku platform. Here are those results.

These results indicate the issue is unique to Puma, with Router 2.0 performance comparable to the legacy router in other cases.

Conclusion

We were initially surprised by this keepalive behavior in the Puma server. Funny enough, we believe Heroku’s significance in the Puma/Rails world and the fact that the legacy router does not support keepalives may have been factors in this bug persisting for so long. Reports of it had popped up in the past (see Issue 3443, Issue 2625 and Issue 2331), but none of these prompted a fool-proof fix. Setting enable_keep_alives false does completely eliminate the problem, but this is not the default option. Now, Puma maintainers are taking a closer look at the problem and benchmarking potential fixes in a fork of the project. The intention is to fix the balancing of requests without closing TCP connections to the Puma server.

Our Heroku team is thrilled that we were able to contribute in this way and help move the Puma/Rails community forward. We’re also excited to release Router 2.0 as GA, unlocking new features like HTTP/2 and keepalives to your dynos. We encourage our users to try out this new router! For advice on how to go about that, see Tips & Tricks for Migrating to Router 2.0.

The post Pumas, Routers & Keepalives—Oh my! appeared first on Heroku.

Heroku Router 2.0 is now generally available, marking a significant step forward in our infrastructure modernization efforts. The new router delivers enhanced performance and introduces new features to improve your applications’ functionality. There are, of course, nuances to be aware of with any new system, and with Router 2.0 set to become the default router soon, we’d like to share some tips and tricks to ensure a smooth and seamless transition.

Start with a Staging Application

We recommend exploring the new router’s features and validating your specific use cases in a controlled environment. If you haven’t already, spin up a staging version of your app that mirrors your production set-up as closely as possible. Heroku provides helpful tools, like pipelines and review apps, for creating separate environments for your app. Once you have an application that you can test with, you can opt-in to Router 2.0 by running:

$ heroku features:enable http-routing-2-dot-0 -a <staging app name>

You may see a temporary rise in response times after migrating to the new router, due to the presence of connections on both routers. Using the Heroku CLI, run heroku ps:restart to restart all web dynos. You can also accomplish this using the Heroku Dashboard, see Restart Dynos for details. This will force the closing of any connections from the legacy router. You can monitor your individual request response times via the service field in your application’s logs or see accumulated response time metrics in the Heroku dashboard.

How to Determine if Your Traffic is Going Through Router 2.0

Once your staging app is live and you have enabled the http-routing-2-dot-0 Heroku Feature, you’ll want to confirm that traffic is actually being routed through Router 2.0. There are two easy ways to determine the router your app is using.

HTTP Headers

You can identify which router your application is using by inspecting the HTTP Headers. The Via header, present in all HTTP responses from Heroku applications, is a code name for the Heroku router handling the request. Use the curl command to display the response headers of a request or your preferred browser’s developer tool.

To see the headers using curl, run:

curl --head https://your-domain.com

In Router 2.0 the Via header value will be one of the following (depending on whether the protocol used is HTTP/2 or HTTP/1.1):

< server: Heroku
< via: 2.0 heroku-router

< Server: Heroku
< Via: 1.1 heroku-router

The Heroku legacy router code name for comparison, is:

< Server: Cowboy
< Via: 1.1 vegur

Note that per the HTTP/2 spec, RFC 7540 Section 8.1.2, headers are converted to lowercase prior to their encoding in HTTP/2.

To read more about Heroku Headers, see this article.

Logs

You will also see some subtle differences in your application’s system logs after migrating to Router 2.0. To fetch your app’s most recent system logs, use the heroku logs --source heroku command:

2024-10-03T08:20:09.580640+00:00 heroku[router]: at=info method=GET path="/" 
host=example-app-1234567890ab.heroku.com 
request_id=2eab2d12-0b0b-c951-8e08-1e88f44f096b fwd="204.204.204.204" 
dyno=web.1 connect=0ms service=0ms status=200 bytes=6742 
protocol=http2.0 tls=true tls_version=tls1.3

2024-10-03T08:35:18.147192+00:00 heroku[router]: at=info method=GET path="/" 
host=example-app-1234567890ab.heroku.com 
request_id=edbea7f4-1c07-a533-93d3-99809b06a2be fwd="204.204.204.204" 
dyno=web.1 connect=0ms service=0ms status=200 bytes=6742 protocol=http1.1 tls=false

In this example, the output shows two log lines for requests sent to an app’s custom domain, handled by Router 2.0 over both HTTPS and HTTP protocols. You can compare these to the equivalent router log lines handled by the legacy routing system:

2024-10-03T08:22:25.126581+00:00 heroku[router]: at=info method=GET path="/" 
host=example-app-1234567890ab.heroku.com 
request_id=1b77c2d3-6542-4c7a-b3db-0170d8c652b6 fwd="204.204.204.204" 
dyno=web.1 connect=0ms service=1ms status=200 bytes=6911 
protocol=https

2024-10-03T08:33:49.139436+00:00 heroku[router]: at=info method=GET path="/" 
host=example-app-1234567890ab.heroku.com 
request_id=057d3a4b-2f16-4375-ba74-f6b168b2fe3d fwd="204.204.204.204" 
dyno=web.1 connect=1ms service=1ms status=200 bytes=6911 protocol=http

The key differences in the router logs are:

• In Router 2.0, the protocol field will display values like http2.0 or http1.1, unlike the legacy router which identifies the protocol with https or http.
• In Router 2.0, you will see new fields tls and tls_version (the latter will only be present if a request is sent over a TLS connection).

Here are some alternative ways to view your application's logs.

HTTP/2 is Now the Default

One of the most exciting changes in Router 2.0 is that HTTP/2 is now enabled by default. This new version of the protocol brings improvements in performance, especially for apps handling concurrent requests, as it allows multiplexing over a single connection and prioritizes resources efficiently.

Here are some considerations when using HTTP/2 on Router 2.0:

• HTTP/2 terminates at the Heroku router and we forward HTTP/1.1 from the router to your app.
• Router 2.0 supports HTTP/2 on custom domains, but not on the built-in <app-name-cff7f1443a49>.herokuapp.com> default domain.
• A valid TLS certificate is required for HTTP/2. We recommend using Heroku Automated Certificate Management.

You can verify your app is receiving HTTP/2 requests by referencing the protocol value in your application’s logs or looking at the HTTP response headers for your request.

That said, not all applications are ready for HTTP/2 out-of-the-box. If you notice any issues during testing or if the older protocol is simply more suitable for your needs, you can disable HTTP/2 in Router 2.0, reverting to HTTP/1.1. Run the following command:

heroku labs:enable http-disable-http2 -a <app name>

Keepalives Always On