Kuberns vs Heroku

Both Kuberns and Heroku turn application source into a managed runtime, but each makes a different bet about what the platform itself should own. Kuberns is a compelling alternative to Heroku for teams who want the same workflow with managed data services, automatic container recovery, and billing tied to runtime rather than to a subscription per attached service.

Summary

When to choose Kuberns

• Deployment from a repository alone: connect the repo and an AI agent works out the framework, runtime, web port, build commands, and the resources the application needs. There is no Dockerfile, build configuration, or deployment YAML to write first.
• Nothing provisioned before you approve it: what the agent detected arrives as an editable screen, so a wrong port is a field you correct rather than a failed build you debug.
• Managed data alongside the app: PostgreSQL, MySQL, and MongoDB as datastores, with Redis, Kafka, and NATS as resources, all provisioned by the platform rather than bought from a marketplace.
• Automatic recovery: three layers of container self-healing that classify a failure and act on it, with every attempt recorded.
• Runtime billing: one credit is one dollar, charged while resources run, with no per-service subscriptions.
• Procfile compatibility: your existing process types are read as they are.

When to choose Heroku

• The add-on marketplace: a single procurement and billing channel for email, search, monitoring, and dozens of other services.
• Per-pull-request review apps: pipelines create an environment for every open PR, which Kuberns does not do.
• Mature tooling: a long-stable CLI and API that a lot of team automation is already written against.
• Managed database restores: Heroku restores a backup for you; on Kuberns a backup is a dump you load yourself.

Using both

These are not complementary platforms in the way a frontend and a backend host are. They are the same kind of product, so most teams end up on one.

The exception is the migration itself, where running both is the right answer. Deploy to Kuberns alongside the live Heroku app, keep the Heroku add-ons attached, validate against production-shaped data, and move DNS only when you are satisfied. Heroku stays as the rollback until the new environment has taken writes. The migration guide walks that sequence.

How the same application is described

The fastest way to see the relationship is to look at one application on both platforms.

Process types

On Heroku, process types live in a Procfile at the repository root:

web: gunicorn myapp.wsgi
worker: celery -A myapp worker -l info

Kuberns reads the same file. The AI agent detects Procfile commands during analysis, and each process type becomes a resource on the environment: web becomes the server resource, worker becomes a background worker. Nothing in the repository changes.

Configuration and connection values

This is where the platforms genuinely diverge. On Heroku you set your own config vars, and an attached add-on injects its own:

heroku config:set SECRET_KEY=... --app myapp
heroku addons:create heroku-postgresql
# DATABASE_URL now exists, supplied by the add-on

On Kuberns there is no injection step. You create the database as a resource and set the variable yourself, from the values on its datastore overview page:

SECRET_KEY        = ...
DATABASE_URL      = postgres://<user>:<password>@<kuberns-hostname>/<database>
CELERY_BROKER_URL = redis://<kuberns-hostname>:6379/0

More explicit, and occasionally more typing. The trade is that the value your application reads is the value you can see.

Projects, services, and environments

Heroku models multiple environments as a pipeline with review apps. Kuberns models them as a hierarchy:

Project          your product
└── Service      one deployable application
    └── Environment   one branch, with its own variables and resources

An environment is tied to a repository branch and owns its variables, resources, domains, build history, logs, and usage. Adding a branch adds an environment. This is coarser than per-pull-request: a long-lived staging branch maps well, a preview per open PR does not.

Where Kuberns shines

A reviewable first deploy

Heroku detects your stack through buildpacks, which match on files in the repository and then own the build. Kuberns runs a temporary AI agent before the first deploy, which reports the framework, root directory, dependency file, runtime, base image, web port, pre-build and post-build commands, Procfile commands, the environment-variable names it found, and the resource categories the application appears to need.

The practical difference is reviewability. A buildpack's decisions surface as build output after the fact. The agent's decisions surface as an editable screen you approve before anything is provisioned, so a wrong port is a field you correct rather than a failed deploy you debug.

The agent is a provisioning step, not a runtime. Its infrastructure is cleaned up when it finishes.

Data services the platform provisions

Heroku's marketplace is a procurement mechanism: you attach a third-party service and it appears as a config var. Kuberns provisions data services directly.

PostgreSQL, MySQL, and MongoDB are managed datastores with their own credentials, metrics, and backup pages. Redis, Kafka, and NATS are queue and cache resources. They sit in the same Resources list as your server and workers, each with its own plan, memory, storage, and health, so the whole application is one view rather than a compute line plus a set of vendor relationships.

On filesystem behaviour the two platforms agree: neither is a place to keep files you care about. Use object storage.

Recovery when a container fails

This is the largest difference, and the one least visible from a feature list. Both platforms give you logs and metrics. Kuberns also tries to fix things.

Three recovery layers run in the backend: orchestrator restart, an intelligent healing layer that classifies the failure and selects a recovery action, and a real-time listener fed by health-agent events. Classifications include out-of-memory, memory pressure, database unreachable, port conflict, disk full, CPU throttling, missing variables, startup loop, and expiring SSL. Recovery can force-update a Swarm service, recreate a single-node application, or recalculate memory limits after an out-of-memory kill. Every attempt is recorded as a healing event with a readable state.

Defaults cap this at five restart attempts an hour, triggered by three failed probes. It is best-effort recovery, not a guarantee.

Separately, Kuberns Fixes analyzes build and runtime diagnostics and splits them by ownership. Platform-side items — a missing installer step, a port mismatch, a supported Dockerfile change — can be applied from the dashboard, which then triggers a new deployment. User-side items — a missing package, a wrong root directory, an application error — are reported as yours to fix. The honest framing is that this narrows the gap between "the deploy failed" and "here is why".

Topology and scaling

Kuberns exposes one concept Heroku does not. Every resource runs under one of two topologies: single node, a Docker Compose deployment, or master node, a Docker Swarm service that supports replicas. Horizontal scaling is most relevant to the master-node path, and conversion between the two is a supported infrastructure operation.

Vertical scaling changes the plan, or the CPU and memory, assigned to a resource. Storage scaling is available on plans that expose it. Scaling consumes runtime credits and is restricted during the free trial, which is worth knowing when you plan an evaluation.

Billing shaped around runtime

The models differ in shape, not only in price, and the shape is the part worth comparing.

Heroku bills dyno time by type and size, and each add-on carries its own plan. Your bill is a compute line plus a set of service subscriptions. Kuberns bills runtime credits: one credit is one dollar, charged while resources run. An attached database is a resource with runtime, not a separate subscription.

Two mechanics have no Heroku equivalent:

• Bundles are priced from your own burn rate. A one-, three-, or twelve-month bundle is your current burn rate multiplied by that duration, so no two accounts see the same figure and yours moves when you add or scale a resource. Longer bundles carry a better rate. Use the number your dashboard shows.
• Data transfer is metered per environment. Each backend service environment includes 5 GB a month, with more available manually or through auto-recharge. See Data transfer and storage.

The trial runs seven days with ten credits and no card, and limits GitHub push events to two a day.

Security and access

Kuberns runs on AWS-backed infrastructure and integrates IAM, EC2, ECR, SSM, Secrets Manager, CodeBuild, CodeDeploy, CodePipeline, CloudWatch, and SES. Controls verified in source include OAuth authentication, role-based service permissions, GitHub webhook HMAC signature verification, IAM-based AWS orchestration, encrypted storage for payment autopay tokens, and cleanup of temporary agent infrastructure.

None of that is a certification. Security and policy sets out the shared-responsibility split, which is the part that matters when you are deciding: application code, the secrets you supply, access decisions, data retention, and backups remain yours.

Where Heroku still fits better

A comparison that only runs one way is not much use, and these are the points a Heroku team will hit first.

The add-on marketplace

There is no Kuberns equivalent. Anything that is not a database, cache, or queue — transactional email, error tracking, search, log drains, schedulers — stays with its own provider and reaches your application through environment variables. You keep the account, the invoice, and the relationship.

For a team using two add-ons this is barely a change. For a team using ten, it is a procurement exercise before it is a technical one, and it is the single best predictor of how much work the move will be.

Preview environments per pull request

Kuberns environments are per branch. A long-lived staging or qa branch works well; an automatically created and destroyed environment for every open pull request has no direct equivalent.

Restoring a database

Kuberns takes backups, on demand or on a schedule, and lists them for download. It does not restore one into a running datastore for you. Recovery means downloading the dump and loading it with psql, mysql, or mongorestore. Test that path before you depend on it.

Two things that are simply not documented

Worth confirming rather than assuming:

• Persistent disks. There is no documented persistent-disk or volume resource. Files that must survive a deploy belong in object storage.
• Private networking. There is no documented internal addressing scheme between services. Confirm how your services will reach each other before you rely on it.

Get started

If your Heroku application is a web process, some workers, a Postgres database, and a Redis instance, it maps cleanly, and the Heroku migration guide is the next thing to read.

If your application is really a Heroku account plus eight add-ons, count how many of those you would keep as direct provider relationships. That number, rather than any feature table, decides whether the move is worth making.