Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.

Deploy Multilanguage Apps to Kubernetes with Open Source Korifi

Use Korifi to deploy applications to Kubernetes written in Ruby, Node.js, ASP.NET, and PHP.
Sep 15th, 2023 1:06am by
Featued image for: Deploy Multilanguage Apps to Kubernetes with Open Source Korifi
Feature image by Rudy and Peter Skitterians from Pixabay.

Kubernetes can be intricate to manage, and companies want to leverage its power while avoiding its complexity. A recent survey found that 84% of companies don’t see value in owning Kubernetes themselves. To address this complexity, Cloud Foundry introduced open source Korifi, which preserves the classic Cloud Foundry experience of being able to deploy apps written in any language or framework with a single cf push command. But the big difference is that this time, apps are pushed to Kubernetes.

In this tutorial, we’ll explore how to use Korifi to deploy web applications written in different languages: Ruby, Node.js, ASP.NET, and PHP. Today, it is quite common to see web applications made of many languages. I will also provide insights into Korifi’s functioning and basic configuration knowledge, helping you kick-start your multicloud, multitenant, and polyglot journey.


For all the examples in this tutorial, I will use sample web applications that you can download from this GitHub repository, but feel free to use your own. You can also find instructions on installing Korifi in this article, which guides you through the easiest way to achieve that by running two Bash scripts that will set everything up for you.

Once you have Korifi installed and have cloned a Ruby sample application, go into the root folder and type the following command:

That’s it! That is all you need to deploy a Ruby application to Kubernetes. Keep in mind that while the first iteration of cf push will take some time as Korifi needs to download a number of elements (I will explain this in the next paragraph), all subsequent runs will be much faster.

At any point, if you want to check the status of a Korifi app, you can use the cf app command, which, in the case of our Ruby app, would be:


Before deploying a Node.js application to Kubernetes using Korifi, let me explain how it works under the hood.

One of the key components at play here is Cloud Native Buildpacks. The concept was initially introduced in 2011 and adopted by PaaS providers like Google App Engine, GitLab, Deis, and Dokku. This project became a part of the CNCF in 2018.

Buildpacks are primarily designed to convert your application’s source code into an OCI image, such as a Docker image. This process unfolds in two steps: first, it scans your application to identify its dependencies and configures them for seamless operation across diverse clouds. Then, it assembles an image using a Builder, a structured amalgamation of Buildpacks, a foundational build image, a lifecycle, and a reference to a runtime image.

Although you have the option to construct your own build images and Buildpacks, you can also leverage those provided by established entities such as Google, Heroku, and Paketo Buildpacks. In this tutorial, I will exclusively use ones provided by Paketo — an open source project that delivers production-ready Buildpacks for popular programming languages.

Let’s briefly demonstrate what Korifi does by manually creating a Buildpack from a Node.js application. You can follow the installation instructions here to install the pack CLI. Then, get into the root folder of your application and run the following command:

Your Node.js OCI image is available; you can check this by running the command:

Once the Docker image is ready, Korifi utilizes Kubernetes RBAC and CRDs to mimic the robust Cloud Foundry paradigm of orgs and spaces. But the beauty of Korifi is that you don’t have to manage any of that. You only need one command to push a Node.js application to Kubernetes:

That’s it!


Now, let’s push an ASP.NET application. If you run cf push my-aspnet-app, the build will fail, and you will get the following error message:

These logs tell us that Korifi may not know a valid Buildpack to package an ASP.NET application. We can verify that by running the following command:

You should get the following output, and we can see that there are no .NET-related buildpacks.

To fix that, first, we need to tell Korifi which Buildpack to use for an ASP.NET application by editing the ClusterStore:

Make sure to replace tutorial-space by the value you used during your Korifi cluster configuration. Add the line – image:; your file should look like this

Then we need to tell Korifi in which order to use Buildbacks by editing our ClusterBuilder:

Add the line – id: paketo-buildpacks/dotnet-core at the top of the spec order list. your file should look like this:

If everything was done right, you should see the .NET Core Paketo Buildpack in the list output by the cf buildpacks command. Finally, you can simply run cf push my-aspnet-app to push your ASP.NET application to Kubernetes.


We need to follow the same process for PHP with the Buildpack paketo-buildpacks/php that needs to be added to the ClusterStore and ClusterBuilder.

But if we run cf push my-php-app, Korifi will fail to start the app and return the following error message:

The OCI image is missing the libxml library, which is required by PHP, this is probably due to the builder not supporting PHP. To check that, let’s look what builder Korifi is using by running this command:

Which will output the following:

As you can see, Korifi currently uses Paketo Jammy Base, which, according to its Github repo description, does not support PHP. You also can check that by looking at the builder’s builder.toml file or by running the command pack builder suggest, which will return the output:

While Jammy Base does not support PHP, the Jammy Full builder does. There are multiple ways to get Korifi to use another builder, I will just cover one way in this tutorial. This way assumes that we used the easy way to install Korifi with the script.

You need to go to Korifi source code and edit the file scripts/assets/values.yaml so that the fields clusterStackBuildImage and clusterStackRunImage are set to paketobuildpacks/build-jammy-full by running this command:

Then, run the scripts/ script.

That’s it! Korifi will use the Jammy full builder, and Korifi will be able to deploy your PHP application with a cf push my-php-app command.


Hopefully, now you’ve experienced just how easy it is to use Korifi to deploy applications to Kubernetes written in Ruby, Node.js, ASP.NET, and PHP. You can stay tuned with the Korifi project by following Cloud Foundry X account and joining the Slack workspace.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma, Docker.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.