Compare / Heroku

Watasu vs Heroku: the Heroku workflow, hosted in Europe

Last verified: 5 Nov 2026 Prices and limits as of November 2026 Found an error? info@watasu.io

Watasu and Heroku work the same way from a developer’s seat. You push code with Git, describe your processes in a Procfile, attach a database with one command and get a review app for every pull request. Neither asks you to run servers or Kubernetes.

Heroku is the platform that defined this workflow. It is owned by Salesforce, runs on AWS, and in February 2026 it moved to a sustaining-engineering model: the focus is now stability, security and support rather than new features. Watasu is a European platform as a service built on the same ideas. It runs your apps, workers, databases, real-time services and AI sandboxes as long-running processes in German data centers, billed from one prepaid balance in euros.

This page compares the two platforms on roadmap, data location, runtime limits, services, pricing and developer workflow, and then shows how to move a Heroku app to Watasu. If you are looking for a Heroku alternative that keeps the Procfile and git push workflow, start with the table.

Start buildingMigration guide

Who should choose which

What Watasu and Heroku have in common

• Git push deploys. git push to the platform remote, or connect a GitHub repository for automatic deploys from a branch.
• Procfile and release phase. Processes are declared in a Procfile, and a release process runs migrations before each new version goes live.
• Buildpacks or containers. Both platforms support buildpacks and container workflows. On Watasu, a root Dockerfile selects a Dockerfile build; otherwise Cloud Native Buildpacks detect the app. Heroku classic buildpacks and container deployments follow their own workflows.
• Add-ons and config vars. Attach a managed database with one command and its connection string appears as an environment variable.
• Review apps and pipelines. Each pull request gets its own app, and the same build moves from staging to production without a rebuild.
• CLIs for day-to-day operations. Both platforms provide terminal commands for apps, config, add-ons and logs; some integrations, including Watasu’s GitHub connection, are configured in the dashboard.

Watasu vs Heroku at a glance

The rows that usually decide. Heroku figures are for Cedar dynos on the Common Runtime; Watasu figures are for Standard and Dynamic pods. Shared features are listed above, not repeated here.

Pricing

Watasu app builds have limits of 16 vCPU and 30 GiB RAM and cost €0.50/hour by actual running seconds, including failed and canceled builds. Queue time and image-only pipeline promotions have no build charge. Before execution, a temporary hold of up to €0.50 funds at most one hour, or a shorter deadline from a smaller available balance; unused funds return after the build stops. Enough available balance for one second is required, with no saved-card requirement or free monthly build allowance. App runtime examples below exclude build charges unless a build row is shown.

Heroku bills each dyno and each add-on plan separately, in US dollars, prorated by the second up to a monthly maximum. Dyno prices step up with memory: Eco $5 (shared hours, sleeps when idle), Basic $7, Standard-1X $25 for 512 MB, Standard-2X $50 for 1 GB, Performance-M $250 for 2.5 GB and Performance-L $500 for 14 GB. Heroku Postgres starts at $5 for Essential-0, and production plans with high availability start at $200 for Premium-0. Heroku keeps only the last 1,500 log lines, so long-term logs come from third-party add-ons with their own prices. Bandwidth has a soft limit of 2 TB per app per month.

On Watasu, you top up a balance in euros (from €5) and usage draws it down. Each process picks one of two billing models:

• Standard: a fixed monthly price per replica for sustained load, for example €15 for 1 vCPU and 2 GiB.
• Dynamic: measured CPU and memory (€20 per vCPU-month, €10 per GiB-month) with a hard monthly ceiling per replica, for quieter APIs, staging and review apps.

Normal app bandwidth is included. App builds cost €0.50/hour by running seconds. If the balance runs out, apps pause; no bill arrives afterwards.

The gap is widest on memory. A Heroku app that needs 2 GB per web process has to jump from Standard-2X to Performance-M. Example monthly costs for a typical production app:

Heroku figures are list prices for the Common Runtime in the US and Europe, excluding Enterprise contracts. Watasu figures match the current pricing catalog. These are plan-bundle examples, not identical CPU allocations or currency-converted totals.

Key differences

Platform status and roadmap

On 6 February 2026, Heroku announced a move to a sustaining-engineering model focused on stability, security, reliability and support rather than new features. Existing apps and contracts are unaffected and Enterprise customers can renew, but Enterprise contracts are no longer offered to new customers. No shutdown date has been announced, so nothing forces a move today.

What changes is the direction of travel. Runtimes, databases and networking will keep moving on around the platform, so compare the features available today rather than assuming an unannounced capability will arrive. Watasu is under active development, and its roadmap is built around the workloads modern apps add: agents, voice, analytics and vector search.

Where your data lives

Heroku is part of U.S.-based Salesforce. Heroku’s credit card terms name Heroku, Inc., a Delaware corporation, for those transactions. For an enterprise contract, check which Salesforce entity provides the service. On the Common Runtime you choose between the United States and Europe. Wider region choice and network isolation come with Private Spaces on an Enterprise contract.

The U.S. CLOUD Act can apply even when data is hosted in the EU. Under 18 U.S.C. § 2713, valid U.S. legal process can require a covered provider to disclose data in its possession, custody or control, wherever that data is stored.

Watasu LTD is registered in England and Wales; its app and add-on workloads run on servers in Germany. You don’t pick a region and there is nothing to configure: app images, databases, backups, logs, metrics, traces and object storage all stay in the EU. For teams whose customers ask about data ownership and location, the answer is the same for every part of the stack.

Runtime limits

Heroku’s router ends any request that hasn’t started sending a response within 30 seconds (error H12), so long uploads, report generation or slow AI calls have to be moved into background jobs. Dynos are restarted about once every 24 hours, and local file changes are wiped on each restart.

On Watasu, your app is the same kind of Procfile, and each process is a long-running workload in its own container:

• web for public HTTP and WebSockets, with managed TLS
• worker for queues, consumers and schedulers, not reachable from the internet
• *-tcp for private TCP and gRPC services, reachable only by apps you allow
• *-rtc for WebRTC and voice, with a dedicated TURN gateway and public UDP
• release for migrations that run before each new version goes live

The public docs do not specify Watasu’s HTTP request timeout or maximum WebSocket duration, so confirm those limits for your workload before moving long-lived connections.

Each process gets its own size, from a small Hobby pod up to 16 vCPU and 30 GiB of RAM, and its own replica count. Once a process has two or more replicas, Watasu spreads them across separate zones at no extra charge.

Databases and backend services

Heroku runs Postgres and a Redis-compatible Key-Value Store itself, and offers Apache Kafka on higher plans. Everything else, including object storage, search, analytics and vector databases, comes from third-party add-ons, each with its own provider, region and price list.

Watasu runs its data services itself, next to your apps, under one bill:

Attach a service with watasu addons:create and Watasu injects the connection variables into your app. Scheduled backups and a restore-and-promote workflow are built in on production tiers.

Real-time, voice and AI workloads

Heroku supports WebSockets through its router, but it has no UDP, so WebRTC media for voice and video can’t run on the platform. It also has no isolated environment for running code generated by an AI agent or uploaded by a user.

On Watasu, *-rtc processes get a TURN gateway, a public UDP port and a stable hostname for each replica, and you bring your SFU, such as LiveKit Server, mediasoup or Pion. Sandboxes give agents isolated Linux environments with templates, SSH, file and command APIs, pause and resume, disk checkpoints and outbound network policies. Runtime is billed per second: a 2 vCPU, 1 GiB sandbox costs about €0.16 per hour, and the Basic plan is free.

Developer workflow

The day-to-day commands will feel familiar. Watasu keeps the ideas Heroku made popular: Procfile, release phase, config vars, add-ons, review apps and pipelines that promote the same image from staging to production.

On top of that, every app gets its own Grafana workspace, and dashboards can live in your repository and sync on each release. Access is set per app or pipeline with four roles: Viewer, Deployer, Operator and Maintainer. You can also connect Claude or another AI assistant over MCP to inspect apps, query logs and manage resources within the connection’s permissions.

When Heroku is the better fit

Heroku remains a reasonable place to stay in a few cases:

• You have a Heroku Enterprise contract and use Private Spaces, Heroku Shield or the compliance attestations that come with them.
• Your app is tightly connected to Salesforce, for example through Heroku Connect.
• You rely on an add-on from the Elements Marketplace with no equivalent outside Heroku.
• You need built-in autoscaling for web dynos on the Performance tier today.

If your app is a standard web app with a database, workers and a cache, and your users or customers are in Europe, Watasu runs the same workflow in one place, with a roadmap that is still moving.

Migrate from Heroku to Watasu

Because the two platforms share the same model, many Heroku apps can reuse their Procfile and deployment structure. Check runtime versions, build dependencies and attached services before switching traffic. Sign up at dash.watasu.io and top up your balance to get started; if you’d like a hand, we help with the migration and give starting credits.

1. Create the app and connect GitHub. Create an app in the dashboard or with the CLI, then connect your repository for automatic deploys, or add a remote and run git push watasu main.
2. Keep your Procfile. web, worker and release process types are supported. Check that their commands and dependencies are available in the new image. Make sure the web process listens on 0.0.0.0:$PORT. Jobs from Heroku Scheduler become a scheduler inside a worker process.
3. Check the build. Without a Dockerfile, Watasu builds your app with Cloud Native Buildpacks. The public docs do not publish an exact language/version matrix or promise compatibility with Heroku classic buildpacks. Test detection and dependencies; if your app needs custom buildpacks or system packages, use a Dockerfile for explicit control.
4. Copy your config vars. Export them with heroku config --shell > .env, remove the database URLs that Watasu will set for you, review the export as a dotenv-style file, then load the remaining settings with watasu config:set --file .env --app my-app. Use --secret for runtime secrets; secret vars are not exposed to builds.
5. Move your database. Attach PostgreSQL with watasu addons:create postgresql --app my-app. Put the Heroku app in maintenance mode, capture a backup with heroku pg:backups:capture, download it and restore it into Watasu with pg_restore. Add Valkey for anything that used Heroku Key-Value Store; caches usually don’t need to be copied.
6. Point your domain. Add your custom domain to the app, update the DNS record, and Watasu issues and renews the certificate. Turn maintenance mode off once traffic is on Watasu.
7. Recreate review apps and pipelines. Connect a staging branch, enable review apps for pull requests, and promote tested builds to production without rebuilding.

Moving a larger workload, or want to see your stack running on Watasu before you switch? Write to info@watasu.io and we’ll set it up with you.

Other comparisons

• Watasu vs Vercel Long-running processes vs serverless functions
• Watasu vs Railway Fixed monthly pod prices and included app bandwidth
• Watasu vs Fly.io Managed app processes and data services in Germany
• Watasu vs Render Always-on services, data residency and bandwidth pricing
• All comparisons Watasu against other hosting platforms

Frequently asked questions

Put your next app on Watasu

Keep the Heroku workflow, keep your data in Germany, pay one prepaid balance in euros. Starting credits and migration help for teams moving from Heroku.

Start buildingSee pricing