For my second interview on unikernels in 2026, I interviewed Felipe Huici of Unikraft about his history with unikernels and the Unikraft business now.

Justin: Nice to meet you, Felipe. It would be great to talk to you about unikernels today. Would you like to introduce yourself?

Felipe: Thanks so much for having me, Justin. I'm Felipe Huici. I'm CEO and co-founder at Unikraft, a startup building a next-generation virtualisation platform that tries to run everything in milliseconds and put hundreds of thousands of virtual machines on single servers. So, efficiency, etc. But I've also spent most of my life with a research hat on. I'm happy to be here and discuss that journey.

Justin: Where did your journey start? Unikraft was in 2018, is that right?

Felipe: The company was in 2022, but there was a prior Linux Foundation open-source project that's still going, which started many years before that.

Justin: But before that you were at NEC, right?

Felipe: The genesis of this was actually London. I was doing my master's and PhD at UCL, and there was a project on how to build virtual routers: how to do software packet processing inside virtual machines in a lean, fast way.

There was also a collaboration with Cambridge, because some Cambridge professors used to hang out at UCL pubs in London. Cambridge was the genesis of the Xen hypervisor. So UCL was networks and Cambridge—I'm simplifying—was hypervisors. That's how the worlds started to come together.

Justin: That makes a lot of sense. I know a lot of the Xen and Cambridge people from my background, but I also know a bunch of people who've worked in the network packet processing space over many years. It was a really big area, wasn't it? It was a huge research and innovation area, because everything went software-defined in telcos, and everything went into VMs. You had to work out how to do this stuff at scale as networks were growing. There was a lot of really interesting work.

What were the challenges you were working on there, and how do they relate to where you went from there?

Felipe: There was an EPSRC project, a UK-funded research project covering UCL and a few other universities, about virtual routers and how to make them go at speed. My professor, Mark Handley—I don't know how this came about—had a connection to Luigi Rizzo from Pisa. I think he's now at Google.

Luigi was digging into these new 10-gig cards and whether you could make them go at speed. He discovered that you could have 14 million packets per second in software, which back then was incredible. He built a framework around it called netmap. That was the precursor work to what became Intel DPDK. Add some zeros.

Justin: I remember that, because I was working with some people who were doing stuff in LuaJIT, and netmap was really early there. I remember reading the papers. It's funny to think about how 10 gig was actually hard at the time.

Now we've got 100 gig, 400 gig and 800 gig, but it was the beginning of that era: one gig was kind of easy, and now we had to do work to get to 10 gig and above. Everyone was suddenly concerned with ring buffers, hardware, what you could do in that many nanoseconds, and making sure everything was accurate, timed and reliable.

Felipe: All these passthrough and zero-copy mechanisms that today are totally default—back then, they weren't.

Justin: It was interesting because there was a previous set of those mechanisms that were either not very important or didn't work particularly well. But as line rates went up, things really had to work. It was the groundwork that made modern fast networking work.

So you were working on that. How did your interests move towards the application layer, rather than just the network processing layer? What challenges came out of that? How did that turn into what you worked on later?

Felipe: There's an intermediate step before going from networks to general applications, or any Linux binary, and that was the virtualisation step in the project. They had promised there should be a virtual router. The question was: how do we put this 10-gig, which led to 40-gig-per-second processing, inside a virtual machine? Can you still make it go at those speeds?

Justin: That was when the telcos were trying to move to commodity hardware. They wanted to virtualise all these services so they could redeploy and reconfigure them, rather than the old dedicated hardware model for telcos.

Felipe: Correct. That went from software-defined networks, and then network function virtualisation started to kick in. Some of the work we were doing was the precursor work to network function virtualisation.

Back then, KVM wasn't really a thing, so we were using the Xen hypervisor, which is all open source. There was something called the Click modular router, software by Eddie Kohler out of MIT, which could do packet processing. We had the ability to do packet processing via it, we knew how to do fast packet processing underneath, obtaining 40 gigabits per second, and then there was the Xen hypervisor. How do you stitch it all together?

We talked to some Xen hypervisor people, and they said, "We have a reference Mini-OS, a tiny OS. You could grab it and try to stitch it together with the Click modular router. Now you would have a virtual machine that would only do packet processing. If you tweak Xen a lot, maybe you can get 10 or 40 gigabits per second out of it."

That's what we did. We stuck all of that together. That virtual machine is very specialised. It can only do one thing: run the Click modular router software, so software packet processing. Now we're going to get into unikernels a little bit. That's a specialised virtual machine. It's a one-trick pony. You can only do packet processing, and a specialised virtual machine is the definition of a unikernel.

Justin: Mini-OS—I can't remember how it arose. Was it for testing or something originally?

Felipe: It was for reference. "If you want to build an OS on top of Xen, have a look at this. Don't use that. Who would be stupid enough to use that?" We did. You were supposed to just reference it. It was minimal.

Justin: I remember using it as well back in that period. It kind of worked. It wasn't designed to be used, but it was usable. So the first unikernel you built was using Click?

Felipe: That was the first one. I don't know if back then we were calling them unikernels. I think that term was coined by Anil and other Cambridge people a little bit later on.

You were asking how we made the jump from software packet processing to binaries. That was a natural transition. In fact, it didn't happen so generally. From there, we moved on to do other specialised virtual machines. We built a Python one, which we creatively called Minipython. We're better researchers than product marketers, right?

Now you could run Python programs very fast in a very lean, tiny virtual machine. It was the beginning of a virtual-machine-based function-as-a-service thing that could scale pretty well. Then you're like, "Okay, but that's only Python. We know how to do networks, we know how to do Python. How do we generalise it?"

As we were going to research conferences with these papers, there was a lot of industry there. They were saying, "This sounds really good, because the performance numbers are orders of magnitude better and they consume much less memory. Could you do it for this other workload, and this other one, and this other one?"

The answer was always, "Well, no. We're building these by hand, we're only researchers, and each one is taking months." That was the beginning of thinking: can we build a specialised virtual machine SDK? Whatever application you come in with, we'll magically turn it into a unikernel, a specialised virtual machine.

This is the genesis of the Unikraft open-source project, also encouraged by the Xen community. They said, "We have an incubator programme. Why don't you grab the beginnings of that Unikraft project and put it in there?" Because Xen is under the Linux Foundation umbrella, that's how it became a Linux Foundation project.

Justin: A lot of the work then was taking existing Linux or POSIX binaries, like Python, and working out how to turn system calls into things that could be understood by what sits on Mini-OS, the things on top of Mini-OS and the library operating system piece.

Back then, I was porting NetBSD drivers for things like that as well. That system call problem—how do we make these things work?—was a big difficulty in the early days. Maybe you could talk about how you worked through those problems and built up the Unikraft project around that, because that was a big part of generalising it to more programs.

Felipe: Maybe I can say a little bit about what a unikernel is. I said it's a specialised virtual machine. That's a true definition, but a fairly vague one. If you want to specialise a virtual machine, you want to throw out everything you don't need.

Take an application, let's say an nginx web server. What system calls does it need? Remove everything else from the kernel. The Linux kernel, however, is not a modular kernel; it's a monolithic one. It does have the concept of some modules, and you can remove some things, but the core of it is one whole thing. You couldn't easily remove the entire network stack and plug a different one in, or remove some protocol support. It's not so easy.

Justin: That's why, back in the day, a lot of telco people were working with the FreeBSD network stack, and why I worked with NetBSD. The FreeBSD one wasn't that easy, but the NetBSD one was easier because they'd already built tools for running it in userspace for testing purposes.

It was much easier than Linux to take kernel pieces and do that, but it was still messy, because you had to use a bunch of the kernel stack. It was easier to pull out things like memory allocation and have a few primitives you could run the thing from. But Linux is very entangled, isn't it?

Felipe: Correct. There are some modules, so there's nuance around it being fully monolithic. But Unikraft was taking it to the other extreme. In the world of unikernels, there's usually the terminology of a library OS. The idea is that every single piece of functionality, as tiny as it might be, is a module you can add and subtract, and there's a common API.

There's a common API that defines a memory allocator, and within that you can plug in 10 different allocators and choose which one is best for the application you're catering for. Then you can optimise not only memory, but performance. That's what Unikraft was trying to do.

What makes it difficult for a unikernel is how compatible you are with that Linux system API. In essence, you're telling the application, "I am Linux. Use me normally," when underneath, you really aren't.

The goal of Unikraft was not only to be as specialised and fast as possible, and get all these beautiful performance numbers, but also, in the Torvalds way, don't break the application. Don't break the API. Whatever the application needs, we're going to provide. If the application does a system call, one of these library modules will expose that system call. The implementation of how it executes that isn't going to be Linux. It's going to be different.

The challenge is how you build up that functionality, because Linux has a lot of functionality. That maturity process took a while. It was also a process of doing a lot of analysis of which system calls get us the most bang for our money: which ones are used by the most common applications? By adding these basic ones, we significantly increase the number of applications that can run on Unikraft.

Justin: What about things like the TCP stack, all those pieces inside the Linux kernel that aren't part of the system call interface, but sit underneath it? There's a lot of implementation work. How did you implement those pieces, and which ones did you implement?

Felipe: I think we started with lwIP. We stole a lot of stuff from the embedded world. Those people are pretty good, and they care a lot about performance and each byte, because the devices this stuff runs on aren't particularly powerful.

We have a lot of admiration for the people who work in embedded systems. As CPUs got powerful, people just threw money at the problem: "Let me allocate four gigs, then let me figure out if I need it or not." In embedded systems, that never really happened. These people always cared about every single line of code.

When we were trying to build these very specialised components that needed to be as performant as possible, we stole a lot of things from embedded. lwIP, for instance, was a network stack that was never meant to go at 40.

Justin: That's been around for a very long time as well, hasn't it?

Felipe: A very long time. Some of the work we did was to tweak the crap out of it so it would go at 40 gigabits per second, which it was never meant to do. But we also abstracted a common API so you could slot in other stacks. We'd also taken the FreeBSD network stack, so you could have a fuller, chunkier stack as well. If you wanted to do more experimental stacks, you could.

Justin: What about other pieces? Mirage never really implemented a storage layer, filesystems. Have you implemented filesystems?

Felipe: We did. I'm trying to remember which one we started with. We basically grabbed many components from different places. I'm trying to remember where we grabbed the first filesystem from.

We also stole from FreeBSD. The reason for these choices was licensing. We were trying to grab the most permissive licences, commercially and non-commercially, because we wanted people to use it commercially if they wanted to, or not. We were trying to avoid GNU licences as much as possible. FreeBSD was a project we stole extensively from.

Justin: In networking, FreeBSD has always been the gold standard of TCP stacks from a lot of networking points of view. They've spent a long time optimising it. Netflix were big consumers of high-speed networking on FreeBSD. It was always a high-quality stack as well as being permissively licensed.

Felipe: To close the loop, Luigi Rizzo was a big fan of FreeBSD, and all the netmap work he did was on FreeBSD initially.

Justin: That's right, I remember. How did the commercial company evolve from the open-source project? That was a few years later. Were you still a researcher at that point, and what happened?

Felipe: I was at UCL, and at some point I transferred to the NEC research lab in Heidelberg, Germany, of all places. We continued a lot of the work I've been describing there for many years.

As an industrial research lab, we were trying to sell our goods back to the business units in Japan. They have data centres, they have a lot of infrastructure. NEC is about 100,000 people. It's like Siemens or General Electric, a big company that does a little bit of everything and has data centres. In Japan, it's absolutely enormous. In the rest of the world, not so much.

We were like, "You have massive data centres. If you optimise the way your virtual machines run, this will give you really big gains." They were telling us, "Our product teams are mostly systems integrators. This is next-generation tech. Who's going to adopt this over there? We see the value, but perhaps take it open source, or maybe spin it out and bring it back in, in some roundabout way."

So we did. We decided to start looking for outside investment, VCs and so forth, to kick this off. At that point, the story started forming that it shouldn't just be VMs, but an entire virtualisation platform.

We started doing tests and saying, "How do we make this more useful? Can we turn it into an AMI, for instance, so people can run it on Amazon?" So we did. We were used to this stuff starting in 10 milliseconds, consuming just a few megabytes and performing I/O at a certain speed. But when we turned it into an AMI and hit go, it took 30 seconds to get started and consumed a lot more memory than we expected.

Justin: You can't get an Amazon machine with only half a gig of RAM. There's a floor on what they actually offer.

Felipe: Correct. That was pretty naive of us in retrospect. We started digging into why a lot of that was. Transparent to you, there's a controller, proxies, the virtualisation layer, host-to-guest communication. There's a lot going on.

That got us thinking: if we really want a next-generation platform where everything happens in milliseconds and you have huge VM density per box, we need to get hold of the hardware at a much lower level.

We started thinking our base should be bare metal. I can relax that a bit later, because we can also run on non-metal instances, VMs on top of VMs. But because we have access to the metal, we can control the host. We can do our own controller, and we should probably do our own proxy and virtual machine monitor. If we want milliseconds end to end, and we have a chunky component in the middle, that's going to kill us. That was the genesis.

Justin: Let's go back to the millisecond startup time and the density. That was a feature of this work all along, and something people talked about. When you started, did you have customers who wanted that, or did you find them later? Was this still an "if you build it, they will come" feeling?

Serverless was growing through that period, but the implementation models have been very varied. Lambda, as an early serverless platform, was never really a fast-start platform. Events are sent to the same VM after startup to hide the latency a bit. It's a hybrid model because it didn't have extremely fast startup. Did you have customers in mind when you started, or actual customers waiting for it? How did that work?

Felipe: No. Back when we started in 2022, we didn't have customers. We had a bit of a thesis. We were a little irked by people touting containers as being super secure. We'd even written a paper many years ago saying, "My VM is faster and more secure than your container," which was a hot take back then. Today, in 2026, people are like, "This is obvious."

We were saying you don't need to compromise. The world should run on virtual machines, and that world of virtual machines can be very fast.

We were also looking at things like Lambda. That's great, that's a step forward, but we didn't understand why serverless meant, "I can scale to zero, I shouldn't run idle, but I need to sacrifice functionality. I can't run absolutely everything. There are restrictions on how long I can run."

If I'm a cloud engineer, why do I have to pick a poison? Either I go to EC2 for full functionality, or I go to Lambda and sacrifice functionality. I can run faster, but then I have cold starts.

The idea was that you can have all of this. I can have strong isolation, start things very quickly, and run anything you can specify in a Dockerfile. That was the thesis.

Justin: What were the hard bits when you started building out the rest of the infrastructure around this? There must have been some interesting challenges.

Felipe: We raised the pre-seed round in 2022, and the idea was, "We'll just do specialised VMs. We can do multiple providers, making sure we can do AMIs, but also go to GCP and Azure, and start selling our goods there."

The first hard thing was realising that we needed to build the entire platform if we wanted those VMs to run fast. The next realisation was: what does an entire platform mean?

First, you need a controller, at least a per-server controller, and then multi-node cluster stuff. But at least the local controller needs to be fast. There wasn't anything out there. There's Kubernetes, but that's fairly slow, definitely not millisecond scales. There were a few other controllers. The decision came very quickly that we needed to do our own controller, and that's another major undertaking. You need a controller that does VM management, lifecycle management, at speed, but also snapshotting and a ton of other things.

Then came the realisation that if we want scale-to-zero, we need a proxy. It needs to be scalable, sniffing potentially a ton of traffic to figure out when it needs to wake things up and talk to the controller. That was another major component.

Now we need to figure out a very fast communication path between the controller and that proxy. That's another layer. Then we need a virtual machine monitor. Great, there's Firecracker and—not so much at the time—Cloud Hypervisor. We can get into how we benchmarked the two and chose one over the other, but we chose Firecracker. It was the fastest, but functionally incomplete. These days, we've even optimised how fast it performs. There was a lot of work in optimising Firecracker.

Then there's host-to-guest communication. How does that work? Even when you get all those things right, you're left with the application. You've optimised everything, everything is wonderful in milliseconds, and now the application takes two seconds to start. You're like, "You've destroyed all of my work."

What you can't do is go application by application and optimise them. So we started getting into snapshotting: taking snapshots in memory of the actual virtual machine to mask that startup time.

Justin: That was a common technique. Java startup was a classic example, but even Emacs used to do that. It used to snapshot its whole heap after it had initialised. The reason I remember this is that it messed with the ASLR setup in Linux. I broke it in containers at one point, and lots of angry people complained about me. I didn't realise Emacs was doing that kind of snapshotted startup.

It was a niche technique, but you're saying you implemented it much more generally. Almost all applications have startup time that's much worse than their active performance time.

Felipe: That's right. To be honest and fair, the mechanism for snapshotting is a very common, old virtual machine technique. Firecracker and many virtual machine monitors have it built in. It wasn't like we invented dynamite or anything. This was already there, but it was never used for cutting down application startup time. These days it is, obviously.

The idea is to start a VM for the first time, wait for it to fully initialise, take a snapshot, and then launch further VMs from that pre-initialised state. Now you can start them really quickly because they've already done all their work. Only make it publicly available to your users after that.

That sounds simple enough. The trick is: how do you make it scalable? How do you make the snapshots efficient? This will work pretty well when you have one or two VMs on the box. But when you have 100,000 scaled-to-zero VMs, and they all need to wake up, sometimes in bursts according to client requests you can't predict, now you have a fun engineering problem. How do you restore 100 snapshots in a few milliseconds at the same time as you're suspending others?

A big component of the platform, and a lot of the engineering, was how to have a very efficient snapshotting layer. Not to mention the storage part: it goes to local NVMe drives, and how do you fit as many as possible without overrunning local storage?

Justin: You said you had a seed round and realised there was a huge amount of work to do, more than you anticipated. What happened? How long did that work take, and did you do it within the seed round?

Felipe: That was pre-seed, and we spent the bulk of it building all this. There was an MVP-type product at the very end. Just a few first customers got us to a seed round, which we're still at the end of now, going into Series A soon.

Definitely 100% of the pre-seed was building this, and chunks of the seed as well. We were a little too ambitious. If somebody asked me how to do a startup, maybe there are easier paths than this one, because you don't want to take on building several major components at once. But it's now coming together. It took the better part of the pre-seed round to build all these things.

Justin: You mentioned host-to-guest communication. Historically, that standardised on virtio and that stack. Have you had to do a lot of work there as well to get low latency and high performance?

That was part of the telco networking stack issues, getting packets to the right host fast, back in the day. Was there overlap with that work and how you thought about it?

Felipe: Yes, there was some work in that direction. As you're saying, a lot of those mechanisms are now very well established, because the beginnings were 10 or 15 years ago. We use a lot of that. We use virtio and other drivers throughout the platform. We did some work, but a lot more went into the bits and pieces I've been describing.

Justin: You recently wrote some pieces with Netlify about them being a customer, and how this had been a year-long project. They wrote a piece and you wrote a piece, and they were really interesting. Can you tell me more about how that relationship happened, what you had to do for them, and how they fit into the story?

Felipe: I think I met Matt, the CEO, at a Heavybit Christmas party. Heavybit are our investors and were longtime investors in Netlify, although that's not how the commercial relationship started. They knew about us, they tried the free tier hosted platform, and that started going.

It took the better part of a year, because it was a large, critical, running service that needed to migrate over. Edge Functions are particularly risky and critical in terms of performance. Every millisecond is super important and counts for money.

It wasn't just switching it over. It also needed to be super reliable, almost five nines, and perform at millisecond timescales. Put all that together and it's a bit of a challenge. The scale is very large. I think they do 1 billion invocations per day.

The challenge was how to map an existing product to our platform. The platform was nowhere near as mature when we started with them a year ago, so there was a process of maturing and adding features.

Then there were things where every single millisecond counts. When we talk to most people and tell them we can start in five to 10 milliseconds, they're like, "That's fine." They don't care if it's five, six, seven, eight, nine, 10 or even 20. That wasn't the case here. We'd say, "We can do 10," and they'd be like, "No, you can do 10 or you can do nine. You can do nine or you can do seven. This is important."

The previous provider was at 50 milliseconds. Since they had an opportunity to shave it down, we shaved it down, and now I think startup time is down to P95s of one to two milliseconds.

Part of that process was optimising the platform. Part was adding features the platform now has, such as just-in-time requests. They were saying, "Just talking to your controller's API takes too long. It takes another millisecond or two. How about we put all the information needed to request a new function inside the actual traffic, where the function code is, and send it all at once? Your proxy will sniff it and tell the controller to start directly via in-memory communication."

There are no additional API calls, and that shaved off more milliseconds. It was a fun engineering process of optimising, remeasuring, optimising, remeasuring, until we got to that really small number.

Justin: But they're not running unikernels on top of this, is that right? They're still running Linux userspace. Did you talk to them about using unikernels? Was their software stack too complex, was it too much of a risk, or were there not enough benefits? Did you have that conversation?

Felipe: We did. That's a very good question. The way we usually do this is that unikernels are seen as an optimisation step. We should start with Linux because it works, and then you can slot in unikernels.

However, we applied a lot of unikernel principles to the Linux distribution we use, which we call Tinyx. In the Linux kernel itself, we've removed a lot of unneeded bits and pieces. Then whatever you specify as a user in the Dockerfile is pretty much your distribution. You can almost map the init process to that. There's nothing else in there, just whatever it needs to run.

If you're doing FROM scratch, you're guaranteed that whatever you're running on our platform is just that and nothing else. There's a tiny layer we add that allows controller-to-Tinyx communication, but that's about it.

For unikernels, the idea is that we can slot them in later. For the longest time, Edge Functions was Deno, because that was the only environment Netlify could support. Now, since they're running on us, they can do whatever environment they want. They can do Python or Go functions.

When you start doing things like Go functions, you could think about slotting in unikernels, because it's a well-defined binary. Maybe it doesn't make sense to run a Linux kernel each time.

Justin: In the last year or so, it's been interesting. I think this is why people are starting to think about unikernels again. First, the thing you were saying about containers not being secure and everything needing to be VMs: that's really shifted in the last year. AI has been very good at escaping from Linux kernels, I think, and even Docker is shipping VMs now. It feels like that's become very widely accepted in a way it wasn't before.

The cloud providers have been shipping VMs rather than containers for a long time, but other people ignored that. It's become normal. Large-scale sandboxing of multiple processes has become something a lot of people are much more interested in because of AI, and agents running code that needs to be sandboxed, at scale, and scaled to zero over very short timescales.

You're waiting for another conversation loop or a tool call to happen, so it's idle for periods of time, and people want high density. Those things you predicted seem to be what everyone suddenly wants this year. Was that surprising or exciting to you? How are you reacting to the world coming in your direction?

Felipe: Exciting, for sure. Surprising? I have to admit, yes, to some extent. It would be arrogant of me to claim I knew the AI wave was coming, with agents and harnesses everywhere. That's all new.

I also love that the term microVM has become so common. It used to be a super-geeky niche thing for virtualisation experts. Now everybody says microVMs.

Justin: Amazon did a very good job of publicising Firecracker and getting people excited when they launched it, even though it wasn't really clear why they did that, and it didn't seem to benefit them much. I remember for months after the launch, everyone was asking me about Firecracker nonstop. It was incredibly successful, probably Amazon's most successful open-source product launch.

Felipe: For sure. Before, it was in the mouths of systems engineers, infrastructure people, operating systems and performance geeks. These days, anybody who's a developer, especially in the AI space, knows what a microVM is. That's shifted.

The idea that everything must run on a VM has shifted. One of the best-kept secrets is that things like ECS run VMs underneath. It's not really a secret, but most people wouldn't know because they don't think about it. AWS definitely knows that you don't run containers without a VM underneath them. Now that's becoming commonplace as well.

As to the dynamics, absolutely. Now you have workloads that are at a super-large scale. We used to say a million services or a million VMs was large. Now, with agents, it's a billion, and some new startups can reach that scale very quickly.

That's number one: the scale is crazy. Number two: you need strong hardware-level isolation, so VMs. Number three: at that scale, efficiency matters. It's really expensive to run many servers, so if something is idle, you must scale it to zero. All those properties coming together—that's what our thesis and platform cater for.

Justin: I think it's also the fact that agents are running existing software, existing Linux software and tools, so compatibility is important at the moment. It's interesting because we could be getting our agents to write unikernels and do more work to optimise for the hardware we run.

Right now, they're running very traditional workloads and a lot of development tooling. That's basically running existing Linux workloads.

Felipe: For sure. Right now, a lot of what we run is these specialised, tiny Linux VMs, because with harnesses and agents, you don't know what they're going to run. It's a very generic workload. That's a little bit anathema to unikernels, where you know at build time what you want to run, and that's how you specialise it. This stuff at runtime can run anything, so it requires the Linux kernel.

Having said that, as security becomes more and more of an issue, maybe we need to start building restrictive harnesses. Or maybe the agents generate functions, and those functions are well defined and can run in unikernels. Especially because these days, as you were suggesting, you can even have agents build the unikernels automatically, which wasn't possible before.

I'm keeping a keen eye on how that can be slotted in, because we have the technology. Our platform can plug and play, whether it's Tinyx or a unikernel, with no problem. It's just a word change in how you configure it.

Justin: There's a lot of opportunity going forward. It seems a really interesting time in this space. It's been really great to talk to you, and it would be interesting to catch up in a short period of time, because things change so fast right now.

Felipe: Absolutely. We should talk again in three months. We'll probably be singing a different song.

Justin: Thanks so much. It's been really fun talking to you.

Felipe: You too, Justin. Thanks for the opportunity.