From Heroku to Kubernetes: training for application engineers

We offer private, instructor-led training for application engineers who use Heroku and need to deploy and support suitable workloads on Kubernetes.

Your team knows process types, config vars, routing, and add-ons. A runnable container does not recreate the platform around it, including release tasks, credentials, and operational support.

LearnKube connects those responsibilities through a web process, worker, and external service dependency. Your engineers will practice releases, traffic diagnosis, and credential delivery.

Discuss your team's training

Hands-on learning and the skills engineers take back to work.

Preview: course-wide figures are not yet available.

  • Hands-on learning
    60%
    Of instruction time spent on labs and challenges.
  • Troubleshooting confidence
    86%
    Of respondents report greater confidence diagnosing Kubernetes problems.
  • Relevant to your work
    92%
    Of respondents say the course addressed their engineering responsibilities.
  • Skills put into practice
    95%
    Of respondents applied their new skills at work within 90 days.

Make the platform's hidden work explicit

  • Deploy each process type by defining images, commands, and appropriate workload resources, so web and worker processes can run and change independently.
  • Preserve dependency access by configuring endpoints, secrets, and readiness, so application instances can reach the services they need after replacement.
  • Diagnose a failed release by inspecting Pod events, logs, and Service endpoints, so engineers can distinguish startup failures from missing routes or credentials.
  • Define platform ownership by documenting build, release, add-on, and support responsibilities, so the team knows which capabilities the destination supplies.

A process command is one part of the platform contract

A Heroku Procfile declares process commands, and its web process receives traffic through the platform router. Kubernetes separates workload controllers from Services and ingress. Packaging the same command into an image does not recreate config vars, add-on access, or release tasks. Each behavior needs an explicit owner on the destination.

I ask which part of the application contract Heroku currently supplies. A database can remain managed elsewhere. The Kubernetes work is to preserve access, credentials, and recovery behavior without assuming that an add-on becomes a Pod.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Start a process typeImages and workload controllersDeploy web and worker
Reach the web processServices and ingressTrace a public request
Provide config varsConfigMaps and SecretsChange runtime configuration
Access an add-onExternal endpoints and credentialsRestore dependency access

How we approach this transition

We propose a workshop around a web process, background worker, and one service dependency. Your team identifies which Heroku behaviors must remain and who will provide them on Kubernetes.

An existing managed database or other service can remain external when the destination can access it appropriately. The exercises focus on the application contract rather than assume that every add-on must move into the cluster.

A recommended four-day workshop for Heroku application teams

This proposed agenda connects familiar process definitions to Kubernetes resources. It makes release and support responsibilities visible without assuming prior cluster-administration experience.

Day 1

We explain container images and startup commands, then separate web and worker lifecycles with workload controllers. You will compare health probes, rolling updates, and rollback with the application's release requirements.

Hands-on exercises

  • Deploy a web process and worker with separate commands and configuration.
  • Diagnose an unready application release and restore the previous version.

Day 2

You will use Helm and compare Kustomize for application resources. We explain reconciliation and cluster components, and discuss where a release task belongs relative to workload deployment.

Hands-on exercises

  • Package the application for two environments without embedding service credentials.
  • Run a bounded preparation task and inspect its completion before releasing the application.

Day 3

We compare managed web routing with Kubernetes Services, ingress, DNS, and TLS configuration. You will examine network policies, service mesh use cases, and the placement of web and worker replicas.

Hands-on exercises

  • Trace a public request from ingress to the web process.
  • Diagnose a failed connection to an external backing service.

Day 4

You will distinguish local files from durable state and examine credential delivery. We cover autoscaling metrics, authentication, RBAC, and separate scaling decisions for web and worker workloads.

Hands-on exercises

  • Change dependency credentials and verify that the application can reconnect.
  • Apply load to a workload and inspect its metrics and replica changes.

Your process types, add-on dependencies, and platform-support responsibilities can shape the agenda. Get in touch to tailor the workshop to your Heroku-to-Kubernetes transition.

Identify the missing platform behavior

When an engineer deploys the web image and expects a public URL to appear, the instructor can trace the missing Service and ingress configuration. Your team can distinguish an application process from the platform services that expose it.

The online training material, documentation and presentations are very well done!

— Andreas, Director of Engineering at Autodesk.

Start with your processes and add-ons

Tell us how you deploy on Heroku, which services will remain external, and who will operate the Kubernetes platform. We will recommend exercises for the responsibilities that change.

Discuss your team's training