Last updated: March 2026

TL;DR: convenience versus control

Heroku is an opinionated platform that tries to make "run the whole app" boring: a managed runtime model (dynos and process types), deploy workflow primitives (Git deploys, releases, release phase), and an add-on ecosystem you can bolt on without assembling a bunch of separate systems.

AWS, GCP, and Azure are toolboxes. You assemble compute, networking, identity, observability, databases, and deployment workflows. You get more flexibility and a deeper ecosystem, but you also take on more platform ownership.

What you gain, what you take on, and what teams underestimate

What you gain

Full infrastructure control

You choose the compute substrate (VMs, containers, functions) and how each service runs. For example, GCP Cloud Run explicitly supports different "runtime shapes" (service, job, worker pool), which maps nicely to "web versus workers" thinking.

Deep networking customization

Subnets, routing, ingress and egress patterns, private connectivity, and isolation boundaries become first-class architecture decisions.

Broader service ecosystem

You aren't limited to a single add-on marketplace model. You can use native cloud services and third-party vendors, then standardize the ones you actually like.

Fine-grained scaling options

You get more knobs than "dyno size and dyno count."

Enterprise procurement alignment

In some organizations, "we run on AWS/Azure/GCP" clears procurement and security reviews faster than "we run on Heroku," purely because the cloud provider is already on the allowlist.

What you take on

Platform engineering responsibility (even if you don't call it that)

Heroku gives you an integrated release model (deploy creates a release; release phase runs tasks before deploy; rollback is a first-class concept). In cloud, you choose and wire the equivalents, and then enforce consistency across teams.

CI/CD pipeline design and governance

Heroku Git deploy is straightforward. In cloud, the wiring is easy. The hard part is agreeing on "how changes become production," especially once you have multiple services.

Observability configuration

Logging, metrics, tracing, alerting, retention, and access controls across multiple services and environments becomes your problem.

Security and IAM sharp edges

Cloud identity and permissions are powerful, but they are also where teams burn time. The blast radius can be bigger because you are closer to core infrastructure.

On-call burden and unknowns

More moving parts means more failure modes: networking, deployment orchestration, service discovery, and misconfigurations you did not know you could create.

Cost modeling and forecasting

Cloud billing is granular. "Cheaper compute" is not the same thing as "predictable total bill." Predictability usually shows up after you invest in standards and governance, not before.

What teams often underestimate

• CI/CD governance redesign is cultural, not technical

• Observability plumbing differences are real (agent strategy, instrumentation, alert ownership)

• Database cutovers look clean on paper and feel awful in the window

• Secrets drift causes outages when you have many systems that can each be "almost updated"

• Internal selling is required (security, finance, procurement, and engineering leadership all care for different reasons)

A lot of teams move to AWS for cost or scale then miss Heroku's workflow simplicity. It's not a failure, it's just a trade you have to make.

Heroku vs. AWS

TL;DR: when AWS is a strong Heroku alternative

AWS tends to be the right move when:

• You have (or will hire) platform and infrastructure ownership: someone accountable for runtime standards, CI/CD, observability, and on-call

• You need deeper control over networking and isolation boundaries than a typical PaaS posture

• You want the broadest service ecosystem and optionality

• Your architecture is trending multi-service and you want a long-term substrate to standardize on

• You expect sustained scale or customization needs where owning the platform becomes a strategic advantage

• Compliance posture requires explicit scoping and documentation, and you want direct access to reports and agreements via AWS Artifact

Red flag that AWS may not be a strong Heroku alternative yet: you don't have bandwidth to own IAM, networking, CI/CD governance, and observability as first-class work.

Developer experience

AWS is not one developer experience. It's a toolbox: your developer workflow depends on which compute model you standardize on.

Heroku DX (the baseline)

• Git-based deploy is first-class ("push to deploy")

• Buildpacks turn source into a runnable artifact with minimal configuration

• Runtime model is process-based: web dynos receive HTTP traffic; other dynos run other process types

• Scaling is formation-oriented (change dyno size and dyno count per process type)

• Release phase runs tasks before a release is deployed; a failure prevents the new release from being deployed

Heroku gives you a cohesive "deploy/run/operate" loop with default primitives. Teams spend less time deciding how to ship, and more time shipping.

AWS compute operating models:

1. Containers on ECS (often with Fargate) (Source)

   • ECS/Fargate can be a pragmatic "post-PaaS" runtime: you keep containerized delivery and offload server management, while gaining more control than Heroku's dyno abstraction.

   • Tradeoff: you own more of the platform envelope: VPC patterns, IAM, deployment standards, observability, and incident response.

2. Kubernetes on EKS (Source)

   • EKS is where teams go when Kubernetes standardization and portability matters.

   • Tradeoff: EKS expands the operational surface area. Even with a managed control plane, you still own cluster-level conventions, add-ons, policy, ingress strategy, and day-2 operations.

3. Serverless functions on AWS Lambda (Source)

   • Lambda can remove server management for event-driven workloads and spiky traffic patterns.

   • Tradeoff: you trade "servers" for platform constraints and distributed-systems complexity (timeouts, concurrency patterns, cold starts, and observability across many small functions).

4. Elastic Beanstalk (PaaS-like within AWS) (Source)

   • Beanstalk is often the least disruptive AWS landing zone for teams that want "Heroku-ish" deployment but need AWS alignment.

   • Tradeoff: you still inherit AWS-shaped decisions about networking, IAM, and surrounding services as your system grows.

What this means in practice:

• Heroku's DX is a single coherent operating model: buildpacks → dynos/process types → routing → release phase

• AWS's DX is a choose-your-operating-model decision (ECS/Fargate vs EKS vs Lambda vs Beanstalk), and then you design the conventions Heroku gives you implicitly

• If your org is ready to own platform conventions (and benefit from deep customization), AWS can be a long-term foundation. If not, AWS can feel like "rebuilding Heroku one decision at a time."

Pricing and scaling

AWS pricing typically combines: compute charges (EC2 instances, container tasks, or function execution), storage charges, data transfer and egress, and managed service charges (databases, queues, load balancers, observability, etc.).

AWS is a toolbox. Your bill is the sum of the services you assemble, not a single "platform meter."

At low scale, costs can be straightforward if you keep the architecture simple. As scale increases, cost becomes more tightly coupled to service sprawl, network egress, and how well you govern capacity vs. usage-based services.

Compared to Heroku: AWS breaks runtime and "add-ons" into a wider set of separately metered services, often more explicit and optimizable, but requiring more cost governance to stay predictable.

Operational complexity

AWS increases operational responsibility compared to Heroku. At minimum, teams typically take on responsibility for:

• Networking configuration (VPC design, ingress/egress patterns, private connectivity)

• IAM roles and permissions (often the sharpest day-to-day edges)

• Secrets management and rotation

• Observability stack assembly (logs, metrics, tracing, alert routing, retention)

• Incident response ownership (runbooks, escalation, postmortems)

• Deployment governance (promotion strategy, rollback semantics, environment parity)

On Heroku, many of these decisions are implicit and standardized by the platform. On AWS, every "it depends" becomes a decision you have to make, and then enforce across services and teams.

AWS can feel "simpler" only after you've invested in internal standards (IaC templates, service patterns, baseline policies, and a consistent delivery model).

Enterprise and compliance considerations

AWS can support enterprise procurement and regulated workloads, but the compliance posture of an AWS-based system depends on the services you use and how you configure them (shared responsibility).

Compliance documentation and contracts

• AWS Artifact provides on-demand downloads of security and compliance documents, including SOC reports, ISO certifications, and PCI reports.

HIPAA/BAA posture

• AWS maintains a list of HIPAA Eligible Services subject to the shared responsibility model. Customers must still configure services consistent with HIPAA requirements.

What this means in practice

If you're selling into regulated buyers, AWS can be a procurement-friendly foundation, but the work shifts to your organization: selecting only in-scope services for regulated data, enforcing identity boundaries and least privilege, generating and retaining audit evidence, and documenting architecture and control ownership for customer security reviews.

Heroku vs. GCP

TL;DR: when GCP is a strong Heroku alternative

GCP tends to be the right move when:

• You want a "managed containers" posture without running Kubernetes, using a platform like Cloud Run

• You can adopt containers as your packaging standard but still want a platform feel for deployment and execution

• Your org is already aligned to Google Cloud (procurement, identity patterns, existing expertise)

• You're building data-heavy systems that naturally fit Google's ecosystem

• HIPAA is in scope and you want a clear BAA path with explicit shared-responsibility framing

Red flag that GCP may not be a strong Heroku alternative yet: you're expecting Heroku-like workflow primitives "for free" without investing in governance around CI/CD, IAM, and observability.

Developer experience

GCP is also a toolbox, but many teams migrating from Heroku land on Cloud Run because it provides a managed container execution layer with a "platform feel."

Cloud Run: managed container execution (Source)

Cloud Run is a fully managed platform for running containers and supports multiple runtime shapes: services (request-driven), jobs/tasks (batch-style), and worker pools (non-request, background workloads).

Cloud Run often feels like the cleanest "step up" from Heroku when you want container-based delivery without running Kubernetes.

Tradeoffs: you still own more of the surrounding platform decisions than on Heroku: identity and permissions, networking shape, observability integration, rollout/rollback conventions.

CI/CD posture (Cloud Build as a common pairing) (Source)

Cloud Build executes builds on Google Cloud and supports build triggers for CI/CD workflows.

In Heroku, "build + release + deploy" is tightly coupled. In GCP, you assemble that coupling, and then you must define governance and promotion semantics explicitly.

What this means in practice:

• Heroku's DX is workflow coherence: process types, routing, formation scaling, release-phase gating.

• GCP's Cloud Run DX is managed container execution across request, job, and worker shapes, while leaving more "platform glue" (CI/CD, IAM, networking, observability) to you.

• Cloud Run can preserve a "PaaS feel" while moving you toward cloud-native primitives; the main DX risk is not compute. It's governance and consistency across services and environments.

Pricing and scaling

GCP pricing typically combines: compute charges, storage, data transfer and egress, and managed service charges.

A common Heroku migration landing zone on GCP is Cloud Run, which supports running containers as services, jobs, and worker pools.

At low scale, costs can be straightforward. As scale increases, cost becomes more tightly coupled to usage patterns, region and egress sensitivity, and the mix of managed services around your core compute.

Compared to Heroku: GCP's Cloud Run path tends to be more "usage-shaped" than Heroku's dyno formation model, which becomes important to understand as you think about which workloads are request-driven vs. always-on.

Operational complexity

GCP increases operational responsibility vs. Heroku, but many teams choose GCP specifically to use a more managed compute layer while still accessing cloud-native primitives.

Even with a managed runtime layer, you typically still own: identity and access design, networking and service connectivity, observability configuration, deployment governance, and incident response processes.

Cloud Run can reduce the "cluster/host management" tax, but it doesn't remove the "platform governance" tax. Teams still need consistent patterns for environments, permissions, and production operations, especially as the number of services grows.

Enterprise and compliance considerations

GCP can support enterprise procurement and regulated workloads, but the compliance posture depends on how you assemble and operate your environment (shared responsibility).

Compliance documentation access

Google Cloud provides Compliance Reports Manager for on-demand access to compliance resources. Google Cloud Audit Manager lets you download compliance documents including audit reports, certifications, and vendor risk assessments.

HIPAA/BAA posture

• Google Cloud's BAA covers Google Cloud's entire infrastructure and lists covered products.

Compliance tooling

Google's Compliance Manager within Security Command Center (Premium/Enterprise) supports defining compliant configurations, viewing compliance dashboards, auditing environments, and collecting evidence.

What this means in practice

If you need regulated posture on GCP, the "paper" side (reports/BAA) is available, but your success still depends on: selecting covered services, controlling access and admin operations, standardizing logging and evidence collection, and documenting shared responsibility clearly for auditors and customers.

Heroku vs. Azure

TL;DR: when Azure is a strong Heroku alternative

Azure tends to be the right move when:

• You're already in a Microsoft-first environment where identity, procurement, and security governance are tied to Microsoft

• You want a PaaS-like landing zone (App Service) for web apps and APIs, or a Kubernetes standardization target (AKS) when platform engineering maturity supports it

• Enterprise procurement expectations favor Azure

• HIPAA is in scope and you want a documented BAA posture with explicit shared-responsibility framing

Red flag that Azure may not be a strong Heroku alternative yet: you want Heroku's simplicity, but you're planning to adopt AKS without a clear internal platform model.

Developer experience

Azure DX usually forks based on whether you choose App Service or AKS.

Azure App Service (PaaS-like) (Source)

Azure App Service is a platform to run web apps, mobile backends, and REST APIs without managing underlying infrastructure. It supports multiple languages and custom containers.

App Service can preserve a "managed hosting" posture similar to what teams like about Heroku, especially in Microsoft-centric organizations.

Tradeoffs: you'll still make Azure-shaped decisions around networking integration, identity, deployment workflows, and how you manage multiple environments.

AKS (managed Kubernetes) (Source)

AKS is often the enterprise standardization target when Kubernetes governance and org-wide patterns matter.

Tradeoffs: AKS expands the operational surface area relative to App Service and often relative to Heroku, unless you build strong platform standards.

What this means in practice:

• Heroku gives you a single operating model that stays consistent across most teams.

• Azure gives you a fork: App Service for managed app hosting, or AKS for Kubernetes standardization.

• In practice, Azure decisions are often as much about organizational alignment (identity, procurement, governance) as about raw developer ergonomics.

Pricing and scaling

Azure pricing typically combines: compute charges (App Service plans, container hosting, VMs, or functions), storage charges, data transfer and egress, and managed service charges.

Two common Azure landing zones: App Service (PaaS for web apps/APIs, where you choose an App Service plan and run apps within it) and AKS (managed Kubernetes, where cluster cost structure varies by configuration).

At low scale, Azure can be straightforward if you pick one primary compute model and don't over-diversify across services before you need to.

As scale increases, cost becomes more tightly coupled to plan choices and how you allocate workloads, network egress and cross-region architecture, and the breadth of managed services you adopt.

Compared to Heroku: Azure has more explicit separation between "runtime capacity" and surrounding services, which can improve cost attribution but increases the number of meters you're responsible for governing.

Operational complexity

Azure operational complexity tends to be driven less by "is Azure capable?" and more by which layer you choose and how much you need to align to enterprise identity and governance.

If you choose App Service, you get a more managed posture. If you choose AKS, you take on more platform engineering surface area.

In either case, you typically still own: identity and role management, networking and segmentation, CI/CD and release governance, observability configuration, and incident response ownership.

Azure frequently shows up in organizations where identity, procurement, and IT governance are first-class constraints. That can be a feature (clear controls and standards), but it can also introduce more process and coordination overhead than a typical startup PaaS workflow.

Enterprise and compliance considerations

Azure can support enterprise procurement and regulated workloads. Microsoft provides an extensive compliance offerings catalog. Your solution still requires shared-responsibility design and control implementation.

Audit documentation access

Microsoft documents that you can access audit documentation via the Microsoft Service Trust Portal (STP). You must sign in to download audit documents.

HIPAA/BAA posture

Microsoft documents that Azure offers a HIPAA BAA as part of the Microsoft Product Terms for in-scope Azure services.

What this means in practice

Azure can be a strong fit for regulated environments, especially in Microsoft-centric organizations, but your compliance story is still architecture-wide: confirm which Azure services are in scope for HIPAA BAA coverage, establish identity, logging, retention, and change controls that satisfy auditors and customers, and build the evidence trail across your whole stack (compute + data + networking + access).

Side-by-side platform comparison

Pricing philosophy comparison

Final perspective

Common limitations with DIY cloud platforms:

• You are the platform team, even if you don't call it that

• Governance work is continuous, not one-time

• The number of failure modes increases

• Cost is easier to optimize but harder to predict without discipline

• You must rebuild Heroku conveniences intentionally

• Compliance is architecture-wide and evidence-heavy

When a DIY cloud platform is the right move:

• You have real platform engineering bandwidth (people, time, and ownership)

• You need deep customization (networking, isolation boundaries, specialized compute patterns)

• You're aligning with enterprise procurement expectations and want direct hyperscaler posture

• You're building multi-service systems where a standardized cloud substrate becomes a long-term advantage

• You want maximum control over observability, security boundaries, and cost optimization

• You expect the infrastructure to be a core part of your competitive advantage

When you may not need a DIY cloud platform:

• You're a small team optimizing for product velocity over infrastructure leverage

• Your architecture is still simple (single service plus managed database), and the main pain is cost optics rather than real infrastructure constraints

• You don't have the appetite to own IAM, networking, and observability as first-class work

• Your compliance needs are modest and can be satisfied by a more opinionated platform with fewer moving pieces

• You need a cohesive "deploy/run/operate" experience more than you need flexibility

• You'd rather spend engineering time differentiating product than rebuilding platform workflows

Next steps

• Overview

• PaaS Alternatives

• Partial Platforms

• Heroku vs. Aptible

• Compare Platforms

• Should You Migrate?