Maintain Your Heroku Architect Certification for Summer ’25
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the transition from Heroku’s Legacy Router to Router 2.0.
- Use the Heroku VS Code Extension to streamline development workflows.
- Navigate the rebranding of Heroku Data for Redis to Heroku Key-Value Store.
- Deploy and manage .NET applications on Heroku, leveraging the new buildpack.
- Migrate applications to Heroku Fir, the next-generation platform.
- Implement Heroku Inference (MIA) and MCP for AI-driven applications.
- Use the Heroku CLI to manage SSL/TLS certificates for your applications.
- Understand recent updates to Automated Certificate Management (ACM) and supported features.
Maintain Your Certification
If you hold the Heroku Architect certification, keep in mind that you need to complete this module by the due date to maintain your certification.
Interested in learning more about getting certified? Check out the Heroku Architect certification.
Protect the Integrity of Your Certification
The quality of our certification exams and the value that they provide are our highest priority. Protecting the security and confidentiality of our exams is essential to providing our customers with certifications that are respected and industry-leading.
As a participant of the Salesforce Certification Program, you’re required to accept the terms of the Salesforce Certification Program Agreement. Please review the Salesforce certification exam-taking policies in the Salesforce Certification Program Agreement and Code of Conduct Trailhead Help article for more details.
Salesforce has introduced great feature enhancements over the past year. Take a look at some of the more important ones.
Router 2.0 and Legacy Router EOL
Heroku’s HTTP routing architecture has undergone a major change with the introduction of Router 2.0, replacing the long-standing legacy router as part of the move toward the Cedar framework. This update represents one of the most significant back-end infrastructure shifts in Heroku’s Common Runtime environment in recent years, delivering improvements in performance, reliability, observability, and long-term maintainability.
The legacy router was deprecated and completed end-of-life (EOL) in Spring 2025. That means any apps that relied on it are no longer supported.
Router 2.0 introduces enhanced request queuing, better load-balancing behavior, and improved metrics for debugging and monitoring traffic. It also lays the groundwork for future network-related enhancements, such as better support for regional routing and faster TLS termination, and supports these features.
Feature | Legacy Router | Router 2.0 | Notes |
---|---|---|---|
x | x | Basic routing, including TLS termination, is supported. | |
x | x | Per-request router logs appear in your app’s log stream. | |
x | x | Most H codes are supported and reported in router logs. Currently, the only exceptions are H23 and H26. | |
x | x | Dyno sleeping (idling) is supported for Eco dynos. | |
x | x | Each router maintains an internal per-app request counter and limits the number of concurrent requests per app. | |
x | x | Heroku headers are a set of headers that Heroku adds to HTTP responses. | |
x | x | WebSockets protocol is supported by both routers. | |
x | x | The Expect: 100-continue header is supported by both routers. | |
x | x | The router quarantines unreachable dynos. | |
x | x | Preboot release behavior works with both routers. | |
x | x | Associates all HTTP requests coming from an enduser with a web dyno. | |
x | HTTP/2 is available for Router 2.0 only. | ||
x | Only Router 2.0 supports HTTP keepalives between routers and dynos. | ||
IPV6 | This is coming soon for Router 2.0 only. |
It’s essential for Heroku Architects to understand this change from both a technical and operational standpoint. Applications might experience different behavior due to how Router 2.0 handles connection reuse and request queuing. That means regression testing after migration is recommended, especially for applications with high request volume or time-sensitive traffic patterns.
For more information, review the Router EOL FAQ and the Router 2.0 documentation.
Heroku VS Code Extension
The Heroku Extension for Visual Studio Code represents a major step forward in developer productivity on the Heroku platform. It provides an integrated experience directly within the VS Code environment, enabling developers and architects to manage applications, deploy changes, and monitor performance without leaving their editor.
That means you can:
- Manage Heroku apps, dynos, and add-ons directly within VS Code.
- Run Heroku CLI commands from the terminal or Command Palette in VS Code.
- View, add, and remove Heroku add-ons without switching contexts.
- Deploy apps with one click from VS Code.
- Use supported IDEs, including VS Code and forks like Salesforce Code Builder, Cursor, and Windsurf.
Visit the Heroku Extension for VS Code documentation for installation instructions and a full feature breakdown.
Heroku Key-Value Store (Formerly Heroku Data for Redis)
Heroku Data for Redis is now called Heroku Key-Value Store (KVS). This is a name change only—your existing KVS instances and applications aren’t impacted. The commands for provisioning and managing KVS remain unchanged. Functionally, Heroku Key-Value Store remains the same managed Redis offering that developers have used for years.
One benefit of the new name is clearer communication—especially for Salesforce Architects explaining Heroku capabilities to business stakeholders. “Key-Value Store” more transparently describes what the service offers and how it fits into scalable application design patterns.
For more details, refer to the Heroku Key-Value Store changelog entry.
Heroku Fir: Next-Generation Platform
Heroku Fir is the most significant evolution of the Heroku platform since the introduction of Private Spaces. Fir represents the next generation of Heroku’s infrastructure, offering a rearchitected runtime that improves performance, reliability, observability, and enterprise readiness. It’s now generally available and ready for production use.
Fir provides feature parity with Heroku’s Cedar stack while introducing key enhancements. Applications running on Fir benefit from faster startup times, modern build and deploy pipelines, and support for Cloud Native Buildpacks (CNB). CNBs replace traditional buildpacks, offering standardized and composable build workflows that align with modern DevOps practices.
Additionally, Fir enhances support for OpenTelemetry and advanced observability tooling, making it easier to instrument and monitor complex distributed systems. This is particularly useful for architects building multiservice applications with deep integrations into Salesforce and third-party APIs.
Fir also introduces improved support for regional networking and data residency, a growing requirement for compliance-driven organizations. With Fir, Heroku enables more granular control over app deployment environments, including network policies and infrastructure scaling.
A dedicated migration guide is available to help architects move apps from Cedar to Fir with minimal disruption. While most existing apps can be ported directly, testing and environment validation are strongly encouraged.
.NET Support on Heroku
Heroku has officially announced general availability (GA) for .NET support, marking a major milestone in the platform’s language support ecosystem. That means developers can now build and deploy .NET apps using an officially supported and integrated workflow.
The .NET Buildpack enables smooth deployment of ASP.NET Core and .NET 8+ applications. It also automatically detects and installs the correct .NET SDK. For teams using C#, F#, or Visual Basic, this means faster ramp-up time and better alignment with Heroku’s managed runtime model.
Additionally, .NET SDK versions 8.0.115, 8.0.311, 8.0.408, 9.0.105, and 9.0.203 are now available for builds on Heroku. The .NET 8.0 SDKs include .NET Runtime and ASP.NET Core Runtime version 8.0.15, while the .NET 9.0 SDKs include version 9.0.4 of both runtimes.
Heroku has also updated its naming conventions for process types in the buildpack. The .NET buildpack now uses a new naming format for default process types. When no Procfile is present, automatically detected process types are lowercased, and spaces, dots, and underscores are replaced with hyphens.
Apps that use a Procfile to define process types are not affected. Apps deployed on Heroku’s Fir generation already follow this new format.
However, apps on the Cedar generation may see non-web worker dynos removed if their process type names change. Here are examples of how process types derived from .NET project file names are now formatted.
Project File | Previous Process Type | New Process Type | Notes |
---|---|---|---|
EmailWorker.csproj | EmailWorker | emailworker | All letters are lowercased |
Email.Worker.csproj | Email.Worker | email-worker | Dots replaced with hyphens |
Email Worker.csproj | EmailWorker | email-worker | Spaces replaced with hyphens |
Email_Worker.csproj | Email_Worker | email-worker | Underscores replaced with hyphens |
For SDK version updates and buildpack changes, see the .NET GA changelog entry and .NET SDK version changelog.
Heroku Managed Inference and Agents and Managed Compute Platform
Heroku was founded on a simple idea: Take the complexity out of deploying and scaling apps so developers could focus on building great software, not managing infrastructure.
Now, we’re bringing that same philosophy to AI. With Heroku AI, we’re making it easier for developers to capture the power of artificial intelligence without getting bogged down in its operational complexity. Our first offering—Managed Inference and Agents (MIA)—lays the foundation for a strategic, developer-friendly approach to AI on Heroku.
Heroku MIA
Heroku MIA is designed to handle real-time model inference, enabling applications to serve predictions and classifications via API endpoints. Whether you’re using models for personalization, recommendation engines, or natural language processing, MIA lets teams deploy and scale inference agents with minimal configuration.
Heroku Managed Inference gives you streamlined access to a curated set of powerful, high-performing generative AI models—handpicked for their effectiveness in the domains our customers care about most. These models are optimized for both usability and impact.
Integrating an AI model into your Heroku app is simple. With a single command—heroku ai:models:create
—you can provision a model via the Heroku CLI. This automatically sets the necessary environment variables, so your app can easily connect and interact with the model.
To help with testing and refinement, the CLI also supports the heroku ai:models:call
command. This lets you invoke a model directly from your terminal, making it easier to fine-tune prompts, experiment with different inputs, and troubleshoot your AI integrations.
Heroku Agents build on top of Managed Inference, offering a clean set of primitives and operations that make it easy for developers to create AI agents capable of executing code within Heroku’s trusted Dynos. These agents can also call tools and application logic, enabling them to take meaningful action on behalf of users. With these capabilities, developers can seamlessly interweave application code, AI calls, AI-generated logic, and external tools—all within a unified, programmatic workflow that fits naturally into the Heroku developer experience.
Heroku MCP
We’re thrilled to launch the Heroku MCP Server—a key step in connecting agent-driven development with Heroku’s AI-powered platform. Just as Heroku redefined the cloud app experience, we’re now extending that same simplicity and power to AI. With the MCP Server, Heroku’s robust platform capabilities become accessible as a set of intuitive, structured actions that AI agents can call via the Model Context Protocol (MCP).
How It Works
At its core, the Heroku MCP Server uses the same trusted foundation developers already rely on: the Heroku CLI. It acts as the execution engine behind the scenes, ensuring compatibility and consistency by using the CLI’s built-in command orchestration.
To optimize speed and responsiveness—especially for complex workflows—the MCP Server runs the CLI in REPL mode (read-eval-print loop). This persistent process enables faster command execution and smooth multistep operations without the overhead of repeatedly starting new CLI instances.
What Can Your Agents Do?
The initial release focuses on high-impact developer workflows:
- App lifecycle management: Deploy, scale, restart, monitor, and access logs for your applications.
- Database operations: Perform actions on Heroku Postgres databases.
- Add-on management: Discover, attach, and detach add-ons for your apps.
- Scaling and performance: Dynamically adjust resources based on app needs.
The Heroku MCP Server powers intelligent integrations with tools like Claude Desktop, Cursor, and Windsurf, enabling a new era of automation, efficiency, and AI-enhanced app management.
For more, see the Heroku Managed Inference and Agents launch post and the Heroku MCP announcement.
Heroku CLI Updates
The Heroku command-line interface (CLI) continues to evolve to support modern development workflows, streamline deployment processes, and increase developer productivity. In the past year, two major releases—Heroku CLI v10 and Plugin Enterprise v5.0.0—have introduced meaningful changes that architects and developers should be aware of.
Heroku CLI v10 introduces official support for the Fir generation of the Heroku platform. While most commands continue to work as before, several breaking changes and enhancements are important to understand, especially when working with Fir apps.
Breaking Changes | |
---|---|
Node.js Version |
|
Process and Dyno Flags |
|
Process Management Commands |
|
Command Compatibility |
|
OpenTelemetry Integration |
|
Spaces Enhancements |
|
Command Enhancements for Fir |
|
Additionally, version 5.0.0 of the Heroku CLI Plugin Enterprise is primarily an architectural update that modernizes the plug-in’s foundation by migrating all CLI commands to the oclif platform (Open CLI Framework). Previously, the plug-in used a legacy, pre-oclif architecture.
Functionality remains unchanged—commands behave the same as in prior versions. The CLI and its plugins update automatically unless installed via the Debian/Ubuntu package or npm install.
- Node.js 20: The plug-in now runs on Node.js 20, aligning with the core Heroku CLI. This change may affect environments or custom tooling still relying on older Node.js versions.
- oclif v4.14.36: The plug-in now uses the latest stable version of oclif for improved performance and compatibility.
- Security Enhancements: Updated dependencies remove known vulnerabilities found in previous versions.
Automated Certificate Management (ACM)
ACM now supports wildcard domains for apps running in the Common Runtime. Previously, if your app used a wildcard domain (such as*.example.com), you had to manually manage your own TLS certificate. With this update, you can now rely on ACM to automatically manage certificates for those wildcard domains—saving time and reducing complexity.
ACM Now Available for Eco Dynos
In the past, only apps on Basic dynos or higher could use ACM. Now, ACM is also available for apps running on Eco dynos, making secure HTTPS connections more accessible to all users.
To Enable ACM, Use this CLI command: $ heroku certs:auto:enable
.
Once enabled, ACM automatically renews certificates before they expire and generates new certificates when you add or remove custom domains.
Changes to ACM Enablement Behavior
Previously, upgrading from an Eco dyno to a higher-tier dyno automatically enabled ACM.
Now, you must manually enable ACM for each app, regardless of dyno type. Additionally, existing apps retain their current ACM status, even when changing dyno types.
Wrap Up
As the Heroku platform continues to evolve, it’s essential for Salesforce architects to stay current with changes that impact app development, deployment, and operations. Now you know about significant platform updates—from foundational infrastructure shifts like Router 2.0 and Fir to new capabilities in .NET support, AI inference, and CLI enhancements.
By understanding and applying these changes, you can ensure your applications remain scalable, secure, and aligned with modern best practices. Stay proactive, keep learning, and continue building with confidence on Heroku.
Resources
- Heroku Blog: HTTP Routing: Legacy Router and Router 2.0
- Heroku
- Heroku Blog: Eco-Tier Applications Now Require Router 2.0
- Heroku Blog: Heroku Extension for VS Code is Now Available
- Heroku Blog: Heroku Extension for VS Documentation
- Heroku Blog: Heroku Key Value Store is the New Name for Heroku Data for Redis
- Heroku Blog: Heroku Key-Value Store
- Heroku Blog:.NET support on Heroku is now generally available
- Heroku Blog: Heroku .NET Support
- Heroku Blog:.NET SDK 8.0.115, 8.0.311, 8.0.408, 9.0.105 and 9.0.203 are now available
- Heroku Blog: .NET buildpack process type naming convention updated
- Heroku Blog: Fir: Heroku’s Next Generation Platform is Now Generally Available
- Heroku Blog: Heroku Fir: Dive into the New Platform Capabilities
- Heroku Blog: Get Started with Fir
- Heroku Blog: Migrating Apps From a Cedar Private Space to a Fir Private Space
- Heroku Blog: Generations: Fir
- Heroku Blog: Heroku Cloud Native Buildpacks: Bringing Heroku Magic to Container Images
- Heroku Blog: Creating Cloud Native Buildpacks from Classic Buildpacks
- Heroku Blog: Heroku AI: Managed Inference and Agents
- Heroku Blog: Introducing the Official Heroku MCP Server
- Heroku Blog: Heroku CLI Plugin Enterprise v5.0.0
- Heroku Blog: Heroku CLI v10 production release
- Heroku Blog: Automated Certificate Management (ACM) for Eco dynos
- Heroku Blog: Automated Certificate Management (ACM) support for wildcard domains for Common Runtime apps