Language Support

Heroku provides official, first-class support for a wide range of modern programming languages. The officially supported languages are:

• Python
• .NET
• Java
• Node.js
• Go
• PHP
• Ruby
• Scala
• Clojure

Official support means that the buildpacks and runtimes for these languages are actively built and maintained by Heroku’s engineering teams. This ensures optimal performance, security, and a seamless deployment experience on the platform.

Yes, absolutely. Heroku’s platform is designed to be extensible through Buildpacks. If your language isn’t on the officially supported list, you can use a third-party buildpack from the Heroku Elements Marketplace or even create your own. This allows you to deploy applications written in almost any language.

A Heroku Buildpack is an automated script that transforms your application’s source code into a runnable asset on the Heroku platform. It handles tasks like detecting your language, installing dependencies, and compiling your code. Heroku utilizes two types of buildpacks:

• Classic Buildpacks: These are used with Heroku’s traditional Cedar generation. They create an optimized package of your app called a slug.
• Cloud Native Buildpacks (CNBs): Used with Heroku’s modern Fir generation, these are open-standard buildpacks that create OCI-compliant container images. This approach offers greater flexibility and compatibility with the broader cloud-native ecosystem.

Essentially, Buildpacks are what make Heroku’s git push heroku main deployment model possible for so many languages and frameworks.

Yes. You can use multiple languages within a single project by using more than one buildpack for your application. This is a common practice for applications with distinct front-end and back-end components written in different languages (e.g., a React front-end and a Python API). To get started, choose between the officially supported buildpacks and the community supported buildpacks.

Once you’ve found the languages you need you can add them to your app using the heroku buildpacks:add command.

Yes. Heroku’s language support is designed to work seamlessly with all major web frameworks. Because Heroku provides robust support for the underlying language (e.g., Ruby, Python, Node.js), it inherently supports the frameworks built upon them. In fact, many official buildpacks are “framework-aware,” meaning they automatically detect your framework and perform specific optimizations for faster, more reliable deployments.

No. For the standard buildpack workflow, you should push your source code directly to Heroku, not compiled artifacts. Heroku’s buildpack system is designed to handle the entire compilation for you, setting up the correct toolchain (like Maven or the .NET SDK) to build a runnable production asset. This ensures a clean, consistent, and repeatable build environment every time. For more details visit the getting started docs of the language of your choice.

This approach is the best practice for buildpack deployments. The main exception is if you are using Heroku’s advanced use-case Container Registry workflow, where you would build a Docker image locally (including the compilation step) and then push the completed image to Heroku to be deployed.

Yes, Heroku supports Docker-based deployments via the Container Registry, which is a powerful workflow for teams with existing container-based processes. This is distinct from the default, buildpack-based deployments. The primary difference between the two comes down to ease of use and security, which is why Heroku recommends buildpacks for most use cases.

• Ease of use: Building an image with a Dockerfile requires you to manually define all the steps and software your app needs to run. Buildpacks automate this by inspecting your application code for community standards (like a go.mod or uv.lock file) to determine what is needed, often requiring zero configuration.
• Security: Buildpack-based deploys product composable containers, which allows Heroku to automatically manage your operating system packages through a process called “rebasing.” This lets Heroku apply security patches to system libraries, like Open SSL, for you. Images built with a Dockerfile and deployed via the Container Registry cannot be rebased; you are responsible for rebuilding the image from scratch to pull in OS updates and keep your app secure.