Heroku

What Is Heroku?

Heroku is a platform-as-a-service (PaaS) that lets developers deploy, run, and scale web applications without managing the underlying servers, operating systems, or networking. Instead of provisioning virtual machines and configuring them by hand, you push your code to Heroku and the platform builds it, runs it in lightweight containers, and serves it on the public internet. Heroku is owned by Salesforce, which acquired the company in 2011, and it remains one of the most recognizable developer-focused application platforms in the industry.

Heroku rose to prominence by making deployment feel almost trivial: a single git push could take a Ruby, Node.js, Python, Java, PHP, Go, or Scala application from a laptop to a live URL. That developer-experience-first philosophy shaped an entire generation of cloud tooling, and many platforms that followed borrowed Heroku's vocabulary of "dynos," "buildpacks," and "slugs." For startups, side projects, and prototypes, Heroku has long been a default choice precisely because it removes almost all of the operational burden of running an app.

It is important to be clear about what Heroku is and is not. Heroku is application hosting, not website hosting in the shared-cPanel sense, and not a static-site host. You do not upload HTML files to it; you deploy a running program that responds to web requests. That program might render a marketing site, power an API, or serve a full single-page application, but there is always a process running your code behind the scenes. This makes Heroku fundamentally different from a traditional shared host and closer in spirit to a managed container platform.

Heroku is also not a browser extension, a plugin, or anything you install into another product. It is a hosted cloud environment that runs on top of major underlying infrastructure, with its own routing layer, build system, and add-on marketplace. When you detect Heroku behind a site, you are identifying where and how an application is being run, which is exactly the kind of stack insight that a server-side URL analysis surfaces. For background on the broader topic, our guide on how to find out where a website is hosted explains the general approach that applies to PaaS platforms like this one.

How Heroku Works

Heroku's core abstraction is the dyno, a lightweight, isolated container that runs a single command defined in your application. Web dynos handle incoming HTTP traffic, while worker dynos run background jobs. You scale an app horizontally by running more dynos and vertically by choosing larger dyno types with more memory and CPU. Because dynos are ephemeral, they are restarted regularly and have no persistent local disk, which pushes developers toward stateless application design and external storage for anything that must survive a restart.

Deployment revolves around buildpacks and slugs. When you push code, Heroku detects the language, runs the appropriate buildpack to install dependencies and compile assets, and packages the result into a compressed "slug" that is distributed to dynos. This build pipeline is what turns a raw git push into a running application without any manual server configuration. Heroku also supports container-based deploys, letting teams ship Docker images directly when they need more control over the runtime.

In front of the dynos sits Heroku's routing layer. Incoming requests hit Heroku's routers, which terminate TLS and forward traffic to a healthy web dyno. This router is the part of Heroku most visible from the outside, because it adds and modifies HTTP response headers in recognizable ways. Apps are reachable by default at a herokuapp.com subdomain, and custom domains are mapped through Heroku's DNS targets.

Beyond running code, Heroku offers a large add-on marketplace. Managed PostgreSQL (Heroku Postgres), Redis, logging, monitoring, email, and dozens of third-party services attach to an app with a single command and inject their credentials as configuration variables. Configuration itself is handled through config vars (environment variables), keeping secrets and settings out of the codebase. This combination of dynos, buildpacks, a routing layer, and add-ons is what makes Heroku a complete application platform rather than just a place to park a server.

A useful way to picture the workflow is to follow an app from commit to production. A developer writes code locally, commits it to Git, and pushes to Heroku. The platform detects the language, runs the buildpack, compiles a slug, and boots web dynos running that slug. The router begins sending live traffic to those dynos, a managed Postgres add-on supplies the database, and config vars feed in the API keys and settings. When traffic grows, the team scales out by adding dynos; when they need a new capability, they attach an add-on. At no point do they patch an operating system or configure a web server by hand, and that is the entire value proposition.

How to Tell if a Website Uses Heroku

Heroku leaves several recognizable fingerprints. Because StackOptic analyzes a URL from the server side, it inspects the same signals you can check manually with curl, dig, and browser DevTools. The strongest tells come from Heroku's routing layer and DNS configuration.

The herokuapp.com domain. The most direct signal is the app being reachable at a *.herokuapp.com address, or a custom domain whose DNS ultimately points at Heroku. If you see herokuapp.com anywhere in the URL, redirects, or asset references, the app runs on Heroku.

The Via: ... vegur response header. Heroku's router has historically identified itself through a Via header referencing vegur, Heroku's open-source HTTP proxy. Seeing vegur in the Via header is a classic Heroku fingerprint. The router also tends to send a Server header consistent with its proxy layer.

DNS and CNAME targets. Custom domains on Heroku are pointed at Heroku DNS targets (such as *.herokudns.com) rather than a fixed IP, because dyno infrastructure is dynamic. Running dig on a domain and seeing a CNAME chain that resolves toward Heroku's DNS endpoints is a reliable indicator.

Heroku error pages. When an app is down, crashed, or misconfigured, Heroku serves distinctive branded error pages with codes like H10 (app crashed), H12 (request timeout), or H14 (no web dynos running). Encountering one of these pages is unambiguous proof of Heroku.

Here is how to check each signal yourself:

Method	What to do	What Heroku reveals
curl -I	Run curl -I https://example.com	Via header referencing vegur, router-style Server header
dig / nslookup	Run dig example.com CNAME and follow the chain	CNAME pointing toward herokudns.com / herokuapp.com targets
Browser DevTools	Open the Network tab and inspect response headers	Via: 1.1 vegur, connection and routing headers
Wappalyzer	Run the extension on the live page	Flags "Heroku" under hosting/PaaS where signals are present
BuiltWith	Look up the domain	Current and historical Heroku hosting detection

A quick command-line check is curl -sI https://example.com | grep -i via, which surfaces the vegur reference when present. For a deeper walkthrough of header inspection, see our guide on how to read a website's HTTP headers, and for the DNS side, how to find out where a website is hosted is the relevant companion.

It is worth being honest about the limits of detection here. Many production teams place a CDN or reverse proxy such as Cloudflare or Fastly in front of their Heroku app. When they do, the edge provider terminates the connection and rewrites headers, so the vegur signal and Heroku's DNS targets are masked behind the CDN. In that situation the outermost layer you detect is the CDN, not Heroku, and confirming Heroku may require finding an unproxied subdomain, observing a Heroku error page, or noticing herokuapp.com references in the markup. This is a general truth of stack detection: managed platforms and CDNs hide the origin, so the most reliable conclusions come from combining several signals rather than trusting any single one. Server-side analysis helps because it fetches the unmodified response directly, but no external tool can see through a properly configured proxy to a hidden origin with certainty.

Key Features

• Git-based deployment. Push code with git push heroku main and the platform builds and releases it automatically, no server configuration required.
• Dynos and elastic scaling. Lightweight containers that scale horizontally (more dynos) and vertically (larger dynos) on demand.
• Buildpacks for many languages. Official support for Ruby, Node.js, Python, Java, PHP, Go, Scala, and Clojure, plus custom and Docker-based builds.
• Add-on marketplace. One-command provisioning of managed databases, caching, logging, monitoring, and third-party services.
• Managed Postgres and Redis. First-party data services with backups, metrics, and credential injection via config vars.
• Review apps and pipelines. Automatic disposable environments for pull requests and a promotion flow from staging to production.
• Config vars and the Heroku CLI. Environment-based configuration and a powerful command-line interface for managing every aspect of an app.

Pros and Cons

Pros

• Exceptional developer experience that removes almost all server administration.
• Fast from zero to a live URL, ideal for prototypes, MVPs, and small teams.
• A rich add-on ecosystem that makes adding databases and services trivial.
• Mature tooling for review apps, pipelines, and continuous delivery.

Cons

• Cost scales quickly compared with raw infrastructure as traffic and dyno counts grow.
• Ephemeral dynos and no persistent local disk require stateless, externally backed designs.
• Less low-level control than running your own servers or a raw cloud provider.
• Free-tier changes over the years have pushed hobby and prototype users toward paid plans.

Heroku vs Alternatives

Heroku sits in the platform-as-a-service tier, more managed than raw cloud infrastructure but less hands-off than a fully static host. The table compares it with common alternatives.

Platform	Model	Management level	Best for
Heroku	PaaS (dynos + buildpacks)	High (you ship code only)	Apps and APIs that want zero server admin
AWS	IaaS/PaaS (broad cloud)	Low to medium (you configure more)	Teams needing full control and scale
DigitalOcean	IaaS + managed apps	Medium	Developers wanting affordable VMs or simple PaaS
Vercel	Frontend/serverless platform	High	Next.js and static/JAMstack front ends
Netlify	Static + serverless functions	High	JAMstack sites and edge functions

If a site turns out to run on raw cloud infrastructure rather than a PaaS, the same techniques point you there; compare Heroku with AWS for the underlying-cloud end of the spectrum, or with a leaner application host like DigitalOcean. For a sibling PaaS-style profile in this set, see Hetzner for the more infrastructure-oriented contrast.

Use Cases

Heroku is most at home for application teams that want to focus entirely on their code. Startups use it to launch an MVP in days, deferring infrastructure decisions until product-market fit justifies the investment. Small engineering teams run production APIs and web apps on it because the operational overhead is close to zero and the tooling for staging, review apps, and promotion is excellent.

It also fits internal tools and dashboards, background-processing services built on worker dynos, and teaching or workshop environments where getting a working deployment quickly matters more than squeezing out the lowest possible cost. For agencies, Heroku is a convenient place to host client applications without standing up bespoke infrastructure for each engagement.

Consider a few concrete scenarios. A two-person startup might ship its entire SaaS backend, a Rails or Node API plus a managed Postgres add-on, on Heroku, scaling dynos up as the first customers arrive. A larger company might run a customer-facing marketing application on Heroku while keeping heavier data workloads on raw cloud infrastructure, using Heroku purely for the parts where developer velocity matters most. A bootcamp might standardize on Heroku so students can deploy their capstone projects with a single command. The common thread is a willingness to trade some cost and low-level control for dramatically simpler operations.

From a technology-research perspective, detecting Heroku on a site is a meaningful signal. It often indicates a developer-led organization, frequently a startup or a product team, that values shipping speed and is comfortable in a code-first workflow. For vendors selling developer tools, observability, or database services, that profile is a strong qualifying signal, and surfacing it automatically across many domains, rather than inspecting each by hand, is exactly where automated stack detection earns its keep. If you want to confirm the application language alongside the platform, our guide on how to find out what technology a website uses covers the complementary signals.

Frequently Asked Questions

Is Heroku the same as AWS?

No, though they are related. AWS is a broad infrastructure-as-a-service cloud where you provision and configure servers, networking, and storage yourself. Heroku is a platform-as-a-service that runs on top of underlying cloud infrastructure and abstracts almost all of that away, so you only ship code. Heroku is far simpler to operate but offers less low-level control and generally costs more per unit of compute at scale than running directly on AWS.

How can I tell if a site is hosted on Heroku for free?

Yes, several free checks work. Run curl -sI https://example.com | grep -i via and look for a Via header referencing vegur, Heroku's router proxy. Use dig example.com CNAME to see whether the domain points toward herokudns.com or herokuapp.com targets. A *.herokuapp.com URL is conclusive, and a branded Heroku error page (codes like H10 or H12) is unmistakable. Free tools like Wappalyzer and BuiltWith confirm it when the signals are exposed.

What is a dyno?

A dyno is Heroku's unit of compute: a lightweight, isolated container that runs one command from your application. Web dynos handle HTTP requests and worker dynos run background jobs. You scale by running more dynos (horizontal) or choosing larger dyno types (vertical). Dynos are ephemeral, restarted regularly with no persistent local disk, which is why Heroku apps store data in external services rather than on the dyno itself.

Why can't I always detect Heroku behind a domain?

Because many sites put a CDN or reverse proxy, such as Cloudflare or Fastly, in front of their Heroku app. The edge provider terminates the connection and rewrites the response headers, hiding Heroku's vegur signal and its DNS targets. In that case the layer you detect is the CDN, not the origin. Confirming Heroku then relies on secondary clues like a herokuapp.com reference, an unproxied subdomain, or a Heroku error page.

Does Heroku still have a free tier?

Heroku's free and hobby offerings have changed significantly over the years, and the platform has moved away from the always-free dynos that defined its early popularity. Pricing and plan availability shift over time, so the authoritative source is Heroku's own current pricing documentation. For prototypes and learning, many developers now compare Heroku's entry plans against other PaaS and managed-app options before committing.

Want to identify Heroku and the rest of a site's stack automatically? Run any URL through StackOptic at https://stackoptic.com.