The Unikernel Internal Developer Platform

Plenty of organizations have started to turn to internal developer platforms (IDP) ran by platform engineers. What does this mean if your organization is using unikernels or would like to use unikernels? Unikernel based IDPs are different than legacy based container IDPs in every core component. They also typically come with many more benefits such as improved security, reduced cost, and improved developer experience and velocity.

There are traditionally 5 core components in an IDP:

• Application Configuration Management
• Infrastructure Orchestration
• Environment Variable Management
• Deploy Management
• Role Based Access Control

Application Configuration Management

For application configuration management lots of yaml might be used if you are on older container based solutions. In unikernel land one might choose to store config in json that is versioned in github for simpler smaller apps like go and rust unikernels.

For more complex runtimes that require a combination of configuration and filesystem additions a unikernel package privately hosted on repo.ops.city might be more applicable. Unikernel packages come with a host of benefits that might not be apparent right away. First off you can freely include binaries which are generally shunned to be included in source control. Second off the packages can be versioned easily. Thirdly, you can fork and create many derivatives of base packages easily using the ops tooling.

Infrastructure Orchestration

There are obviously very large differences when it comes to infrastructure orchestration in a unikernel based IDP. Most organizations will still choose to be on the public cloud but may also choose to run on their own servers for other various reasons including compliance issues.

On the public cloud there are generally two methods and which one you choose depends on what your organization needs. For most companies simply allowing the cloud to do the orchestration themselves is a core reason why they chose to provision their software as unikernels to begin with. Not having to manage networks, storage, routing, etc. but be able to take advantage of high levels of customization is a major benefit of using unikernels. If this doesn't make sense we'd highly encourage you to try and deploy a unikernel to aws.

Conversely sometimes platform engineering teams require full control of orchestration. It might be advantangeous to binpack many smaller tenants into a larger instance type or the team might need precise control on instance instatition. For instance while many clouds have pause/resume like functionality, the ability to pause/resume workloads within milliseconds is something that unikernels can do running in NanoVMs Inception. Another benefit of using Inception is that most people assume you need a bare metal host to run virtualized workloads and bare metal instance types can be very expensive. Inception has a special hypervisor that allows you to run your unikernels on plain old normal instances without severe performance loss. You can even run non-unikernel payloads on it such as ci/cd workflows that typically require a lot of insecure shell/command activity. This option makes a lot of sense if you need access to hybrid workloads.

Environment Variable Management

Environment variable management can look a lot like existing container infrastructure, however env vars can be injected and consumed differently. Env vars might pre-populate in unikernel packages if they are not sensitive - for instance with path variable names or HOME variables. You'll find this quite a lot in JVM based packages. A lot of JVM applications typically have a shell script that sets paths, changes directories and sets a half dozen different env vars. People who convert those into unikernels have to translate that into config.

Another way that one might consume env vars is that they might also be injected at runtime using klibs such as cloud init.

Unikernels offer a wide variety of mechanisms to utilize and provision environment variables with.

Deploy Management

At first blush many existing unikernel users might wonder if there are that many differences when it comes to deploy management. While many of the constructs might remain the same different deploy targets can be utilized such as application load balancers. Some of these options might not have been accessible in legacy container based architectures.

Role Based Access Control

Role Based Access Control is a huge difference in unikernel platforms as they typically only touch on exterior functions of applications being deployed vs internally. For external resources such as who has the right to deploy an application or who can look at logs and telemetry, existing RBAC systems can be used but internal functions simply do not exist at all as there are no shells or ssh or a means to enter into an existing unikernel application. That is a core security feature of unikernels to begin with.

Observability, Monitoring and Logging

In 2025 there are hundreds of observability vendors and probably thousands of tools that one could use. A unikernel IDP does not mandate a single one that you must use and instead gives you the freedom to choose what your team is already using. If you're using elasticsearch/opensearch - keep it using. Datadog or VictoriaMetrics? Keep using it. Hosted or self-hosted? For those that wish to keep these solutions under their teams management plenty of options exist as unikernels.

Other benefits of Building Your IDP on Unikernels

As mentioned not only do core components change when upgrading from your old container based IDP to a unikernel based IDP but you get many new improvements.

Improved Security

Right off the bat a unikernel based IDP delivers vastly improved security. As we already mentioned unikernels do not have the notion of ssh, users, passwords, shells or other interactive userland. This also means there is no capability of running other commands or programs on the same instance as the one that an application is already running on. This immediately stops many types of common software weaknesses cold and neutralizes a great deal of exploit payloads. This also prevents a lot of lateral movement as attackers can not work from a privileged environment.

Reduced Cost

Since unikernels tend to run much faster than normal linux systems or applications provisioned as containers at scale one can expect much lower cost to be expended. The very fact that you are considering an internal developer platform probably already says that your organization provisions many applications by many developers so cost will be another easy win.

Improved Developer Experience and Velocity

Most developers just want to have their applications be deployed and ran in the smoothest possible way. Provisioning applications as unikernels remove the pressure from having to deal with a general purpose operating system and all the clunky knobs they come with.

Considering building a new IDP or refactoring the one you have onto unikernels? Reach out and we'll be happy to guide you on your path.