Loading…
Heroku
Heroku is a cloud platform as a service where you can deploy projects and websites. It supports several programming languages, so it’s no surprise that Heroku’s really popular.
- 143 posts summarised
- latest
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
From their blog
Latest articles
AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications
AppLink Fundamentals I describes four integration patterns for connecting Salesforce orgs with Heroku applications, focusing on API access and Salesforce extension. Pattern 1 uses run-as-user authentication for automated or customer-facing applications, with the AppLink add-on, CLI plugin, optional SDK, named authorizations, and SOQL queries through the Data API; the SDK manages authentication, session management, and connection pooling for single- or multi-org access. Pattern 2 lets Salesforce users invoke published Heroku services through Flow, Apex, or Agentforce, using User Mode or elevated “user mode plus” permissions controlled by Permission Sets, an OpenAPI description, and a service-mesh buildpack that blocks external access. The post also positions batch processing and real-time eventing as extensions of these patterns, and describes Data Cloud querying and Data Action Targets for applications to receive Data Cloud events.
Heroku AppLink: Extend Salesforce with Any Programming Language
Heroku AppLink is now generally available from the Salesforce Setup menu, extending Salesforce with Heroku applications and code written in virtually any programming language. The initial release provides SDK support for Node.js and Python, while Java examples and direct AppLink API access demonstrate how other languages can integrate; the APIs provide authentication, authorization, connection pooling, and access to Salesforce and Data Cloud data. AppLink combines an add-on, service-mesh buildpack, dashboard, CLI, API, SDK, OpenAPI integration, and Salesforce API integration to provision connections, restrict and authenticate requests, publish services, and monitor org integrations. The add-on is free, with normal Heroku billing for compute and data resources, and published applications can extend Flow, Apex, and Agentforce while user mode is enabled by default.
OpenTelemetry, Kubernetes, and Fir: Putting it All Together
Modern cloud-native applications span distributed microservices and dynamic environments, making performance diagnosis and failure analysis dependent on observability. The post explains how Fir, Heroku’s next-generation platform, combines Kubernetes infrastructure with OpenTelemetry to provide standardized visibility while hiding Kubernetes complexity behind Heroku’s interface. Fir runs on AWS EKS, uses OCI images and Cloud Native Buildpacks, and includes a Heroku OpenTelemetry Collector that gathers telemetry from applications, the Heroku router, and the Heroku API. OpenTelemetry’s APIs, SDKs, Collector, and OTLP support logs, metrics, and traces, with drains routing data to dashboards, CLI logs, or external observability platforms. The text also distinguishes OTLP gRPC and HTTP transports, noting gRPC efficiency and features versus HTTP’s firewall compatibility, and presents Fir’s open standards as a way to support scaling, hybrid environments, and reduce lock-in.
Local Speed, Smooth Deploys: Heroku Adds Support for uv
Heroku now natively supports uv, a Rust-written Python package manager presented as a faster alternative to pip for dependency resolution, installation, and virtual-environment management. The post connects this support to recurring problems in modern Python projects, including slow installs, complex dependency trees, version pinning, and tooling that may struggle to keep pace with current standards. It walks through installing uv, running uv init, adding Flask and Gunicorn with uv add, and deploying a basic Flask application using a Procfile, pyproject.toml, uv.lock, and .python-version. Heroku detects the Python app, installs dependencies from these project files, and starts it with gunicorn main:app after a Git push. The stated outcome is faster local development, more consistent environments, reduced onboarding time, fewer flaky builds, and improved pipeline performance, while uv remains relatively new.
Heroku Postgres Upgrade Guide: Simplify Your Move to Version 17
Heroku Postgres 17 is now available, and the platform introduces a simplified, self-service path for upgrading managed databases. The new heroku pg:upgrade:* commands cover preparation, manual execution, cancellation, dry runs, and progress tracking, while email notifications report major stages and detected issues. Essential-tier databases can be upgraded directly with pg:upgrade:run; Standard-tier and higher databases can use a dry run, schedule an upgrade for the next maintenance window, or run it manually, with followers upgraded automatically. The in-place workflow uses an internal replica, leaves DATABASE_URL and other config vars unchanged, and typically reduces downtime to about five to ten minutes. The legacy heroku pg:upgrade command will be deprecated soon, although the traditional follower approach remains available.
OpenTelemetry Basics on Heroku Fir
Heroku Fir includes OpenTelemetry as a built-in observability capability, addressing the need to monitor increasingly distributed and complex applications. The post introduces OpenTelemetry’s logs, metrics, and traces, while noting that events and profiles are under development. It distinguishes application-embedded SDKs, which generate and process telemetry, from standalone collectors that receive, process, and export data, although Fir acts as the central hub for telemetry pipelines. The walkthrough uses the Go getting-started app in a Fir space, creates Grafana Cloud credentials and environment variables, converts OTLP headers to JSON, and adds an HTTP Heroku Telemetry Drain with the CLI. After deployment and browser refreshes, application metrics appear in Grafana Cloud, followed by traces and logs.
Deploying a Simple Go/Gin Application on Heroku
Deploying a Go/Gin application can be simple locally but requires explicit preparation for cloud deployment, including dependency management, environment configuration, and a process definition. The guide initializes a Go module, adds Gin with go get, runs main.go locally, and verifies the API with curl, using Go 1.24.0 in its example. It then creates a Heroku app, adds a Procfile with web: go run main.go, runs go mod tidy, commits the project, and pushes the main branch to the Heroku remote. Heroku detects the Go app through go.mod, installs Go 1.24.0 and dependencies, builds ./bin/go-gin, and launches the web process; the deployed /quote endpoint returns JSON, while heroku logs --tail confirms a successful request.
SignalR Scalability: Scaling Real-Time SignalR Applications on Heroku
Scaling a SignalR application beyond one server requires coordination because each server maintains its own connected-client list. The guide builds a .NET 9.0 chat application, adds the Microsoft.AspNetCore.SignalR.StackExchangeRedis package, and configures Redis as a backplane with a SignalRChat channel prefix and environment-specific connection settings. It deploys the application to Heroku, changes the dyno type to standard-1x, and runs three web dynos; without session affinity, WebSocket startup fails because the connection may be routed to a different dyno. Enabling Heroku’s http-session-affinity feature keeps requests on one dyno, after which both browsers establish stable WebSocket connections and exchange chat messages successfully across the scaled deployment.
How I Improved My Productivity with Cursor and the Heroku MCP Server
Cursor is presented as the author’s primary AI coding companion, with inline suggestions, quick edits, and agentic features supporting coding, testing, design, and deployment from one editor. Connecting it to Heroku through the Model Context Protocol (MCP) enables an assistant to deploy apps, scale dynos, fetch logs, and update configuration without opening the Heroku dashboard or terminal. The article explains MCP’s host–client–server model and gives Cursor setup configurations for the Heroku MCP Server, LangChain MCPDoc, and Figma MCP Server, including required Heroku authorization and tool commands. It reports that this workflow reduced context-switching, saved minutes on tasks, reduced errors from recalling commands, and helped the author stay focused while building and deploying demos.
How to Add the Moesif API Observability Add-On to Your Heroku Applications
Heroku applications can add the Moesif API Observability add-on to analyze API traffic and support monetization. The setup uses either the Heroku CLI or Dashboard: the CLI command is heroku addons:create moesif, while the UI path goes through Resources, Find more add-ons, and Metrics and Analytics. Provisioning creates a MOESIF_APPLICATION_ID config variable, and the application then requires the Moesif SDK initialized with that value. The guide also covers copying the variable into a local .env file with Heroku Local and excluding that file from Git through .gitignore. Once configured, API events should flow into Moesif for live logs, time-series metrics, funnels, retention, alerting, and billing features, while Heroku handles add-on billing and user management.
Using GitHub Actions with Heroku Flow for additional Security Control
The pattern combines GitHub Actions with Heroku Flow for private repositories and stricter security requirements when GitHub organization IP restrictions cannot use Heroku IP ranges. A custom self-hosted GitHub Runner runs as a Docker image on Heroku, while the Platform API and Source Endpoint API upload source code to ephemeral storage, build and deploy apps, and manage Review Apps. Event-specific workflows handle pushes, manual runs, schedules, and pull requests; a weekly workflow rebuilds and autodeploys the runner image within GitHub’s 30-day update window. Setup uses a Heroku Private Space, its outbound IPs, a GitHub access token, and organization name, but omits the repository URL in the Review App UI, does not run conventional Heroku CI tests, and is incompatible with Fir.
Simplifying JVM App Development with Heroku’s Buildpack Magic
Heroku’s Java buildpacks simplify JVM application deployment by detecting project languages and frameworks, fetching build tools, and configuring runtime settings automatically. They support Spring Boot, Quarkus, and Micronaut by inspecting Maven or Gradle build definitions, packaging applications, selecting framework-specific runner commands, and mapping service variables such as SPRING_DATASOURCE_URL, SPRING_REDIS_URL, DATABASE_URL, and JDBC_DATABASE_URL. In many cases, a Procfile is unnecessary because the buildpack can identify the executable JAR and provide a default web process, while Quarkus and Micronaut receive their respective runner JAR and port settings. Heroku also automatically attaches a lightweight JVM agent for runtime metrics, including memory usage and garbage collection, and offers similar buildpack support for Scala and Clojure through sbt and Leiningen.
Heroku CLI v10: Support for Next Generation Heroku Platform
Heroku CLI v10.0.0 updates the command-line tool for the next-generation Fir platform while introducing breaking changes and a Node.js 20 runtime. Fir users must replace several legacy command forms, including logs and ps:stop/ps:restart arguments, and use heroku run:inside because heroku run, ps:exec, ps:copy, ps:forward, and ps:socks do not work with Fir apps. New Fir support includes heroku telemetry commands for OpenTelemetry, a generation selector for spaces:create, generation details in space commands, Fir-aware pipeline and buildpack output, and real-time log streaming with --tail. The release also upgrades oclif to v4.14.36, updates GitHub workflows to Node 20, fixes log color rendering, and is available through heroku update.
Pumas, Routers & Keepalives—Oh my!
Heroku’s Router 2.0 beta exposed elevated tail response times and request failures in a subset of Puma applications, especially under 200 milliseconds of server-side lag and 30 requests per second. Investigation compared legacy and Router 2.0 connections, examined TIME_WAIT behavior, and tested Go’s http.Transport idle-connection limit; raising MaxIdleConnsPerHost from the default of 2 to 100 stabilized connection states but did not improve latency. The underlying issue was Puma’s handling of persistent connections, where request balancing could leave work queued behind busy connections; disabling keepalives eliminated the problem, while thread, worker, and max_fast_inline tuning were offered as alternatives. Load tests found the issue unique to Puma, and the update reports that Puma 7.0 fixed the bug, recommending version 7.0.4 or higher.
Tips & Tricks for Migrating to Router 2.0
Heroku Router 2.0 is generally available and is expected to become the default, making migration planning important before rollout. The guidance recommends creating a staging application, enabling the http-routing-2-dot-0 feature, restarting web dynos when needed, and checking response headers and system logs to confirm routing. Router 2.0 identifies requests with Via values such as “2.0 heroku-router” or “1.1 heroku-router,” and its logs add protocol, tls, and tls_version fields. HTTP/2 is enabled by default on custom domains with valid TLS certificates, while HTTP/2 can be disabled through a Labs feature. Keepalives are also enabled between the router and web dynos, but applications using recent Puma versions may need the keepalive opt-out because of a connection-handling bug.
How to Create an AI Agent With Heroku and Agentforce
The post shows how to extend Salesforce Agentforce with a Heroku-hosted custom action when customer information remains in older, unstructured cloud archives and requires scalable, real-time processing. It explains that Agentforce selects discrete actions, while Heroku exposes code through External Services using an OpenAPI description of the request and response. The sample uses Java and Spring Boot, an H2 in-memory database, springdoc.org for OpenAPI generation, and Spring AI to convert natural-language questions into SQL before returning results for an Agentforce response. The integration is identified as pilot-only and not intended for production, while the post also points to Heroku Postgres, Heroku Connect, Data Cloud, and pgvector as extensions for other agent use cases.
Testing a React App in Chrome with Heroku CI
The article presents a walkthrough for automating end-to-end browser tests for a React application in Heroku CI rather than relying on manual local testing. The sample app uses Jest and Puppeteer to check navigation to Puppeteer Documentation, retention of text entered into a form, and the greeting shown after submission, with headless Chrome supplied by the Chrome for Testing Heroku Buildpack. Local execution initially exposes a mismatch between the expected and received greeting, then passes after the application is fixed; a streamlined command starts the server and runs the suite. Heroku CI is configured with an app.json file containing Chrome for Testing and Node.js buildpacks, plus a test script that runs start-server-and-test and the Jest/Puppeteer tests. Pushes to the connected GitHub repository trigger the suite.
What is Data Residency? Data Residency Concerns for Global Applications
Global applications can move customer data across borders, making data residency a compliance concern for organizations serving multinational users. The post defines data residency as legal requirements governing where data may be stored and processed, then distinguishes it from data sovereignty’s jurisdictional reach and data localization’s requirement that storage and processing remain within a jurisdiction. It notes that GDPR and CCPA focus on compliant handling and individual rights rather than necessarily mandating storage locations, while China’s Personal Information Protection Law requires certain Chinese citizens’ PII to be stored within China. The proposed approach uses cloud regions to align storage with local requirements, citing Heroku Enterprise Private Dynos across ten regions and Heroku Shield Private Spaces’ PCI, HIPAA, ISO, and SOC certifications; the post concludes that these features can make compliance more achievable while improving control and potentially application performance.
Building an Event-Driven Architecture with Managed Data Services
Event-driven architecture (EDA) addresses the need to process and respond to continuous streams of real-time activity from applications, e-commerce systems, wearables, and other IoT sensors. Using Apache Kafka, independent producers publish events to topics while consumers subscribe and trigger downstream processes, keeping services decoupled and independently scalable. Kafka also distributes large data streams in real time and replicates data across synchronized broker nodes, so a node failure does not lose data or interrupt operation. Apache Kafka on Heroku is presented as a fully managed service, with multi-tenant basic and single-tenant private plans, automatic broker scaling, and Standard-tier-and-above configurations starting with three brokers and extending to eight. Recommended integration practices include mapping producer-consumer flows, using transactions, topic and schema management, and delivery guarantees, plus monitoring performance and logging Kafka operations.
Mastering API Gateway Integration: Salesforce, Heroku, and MuleSoft Anypoint Flex Gateway
MuleSoft Anypoint Flex Gateway provides a pattern for exposing APIs and microservices running in Heroku Private Spaces while adding API management and security controls. The tutorial deploys an internal Heroku application, creates or imports an OpenAPI 3.0 specification in Anypoint Design Center, publishes it to Exchange, registers the gateway through Runtime Manager, and deploys it in the same Private Space. That placement lets internal-routing applications receive public traffic through the gateway while routing access through a centrally configured layer managed with MuleSoft and Heroku. It then applies a Client ID Enforcement policy in API Manager, showing that requests with incorrect credentials fail and requests using the issued Client ID and Client Secret can authenticate. The pattern is presented as a foundation for Heroku and Salesforce multi-cloud integrations.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.